Also looked at your coding and formatting stile in the module...
Long names / identifiers that do not get and cannot get (easily) minified (or for constants to get folded in), are a burden: they use memory / variables in Espruino (because interpretation from source code), therefore the shorter the better. Therefore, I would refactor/rename them.
Spacing related to (reserved) key words and parenthesis and curly braces feels odd to me as a compiler / parser guy... I know it works, but it is like reading text and making the breaks and taking breaths off-interpunctions...
Last but not least, I'd take a look at the try counts and defer times: timeout times rcTimeoutTime and ccTimeoutTime (I'd like to see them anyway to be part of the C-onstants and not hard coded... ;/...). Make them match to hour intended measuring interval / prevent time overlapping. Worst case - or if you really want to get tight - you make an open interval constructed with comparing actual time and a defer with a timeout if needed to not measure more frequently that your intend maximum, but give time to complete a measurement in case it takes longer. Such a construct (self calling - by timeout -method/function as in the rc and cc defers in the module) you can use then also for firing right again a measurement after a failing one.
All depends though on your context where you want to use the sensor. I assume you did this work not just for the sensors' sake.
NB: Don't forget to remove the convenient setTimeout(onInit,... before you upload for saving (the code)
Thank you for the hints. I will keep to work on it in the next weeks, since it is part of my research project at university. I will try to follow your advice. HW initializing twice is an error, I just copied it twice. Thank you again for your efforts!
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Wondering why you initialize the HW twice...
Also looked at your coding and formatting stile in the module...
Last but not least, I'd take a look at the try counts and defer times: timeout times rcTimeoutTime and ccTimeoutTime (I'd like to see them anyway to be part of the C-onstants and not hard coded... ;/...). Make them match to hour intended measuring interval / prevent time overlapping. Worst case - or if you really want to get tight - you make an open interval constructed with comparing actual time and a defer with a timeout if needed to not measure more frequently that your intend maximum, but give time to complete a measurement in case it takes longer. Such a construct (self calling - by timeout -method/function as in the rc and cc defers in the module) you can use then also for firing right again a measurement after a failing one.
All depends though on your context where you want to use the sensor. I assume you did this work not just for the sensors' sake.
NB: Don't forget to remove the convenient
setTimeout(onInit,...
before you upload for saving (the code)