I have had great joy building my mushroom fruiting chamber with mycodo. Currently I have all inputs and outputs working. However, I’m having my atlas scientific humidity sensor drop out from time to time.
I suspect it’s a noise induced issue but that is a guess. Anyhow, I was planning to schedule some kind of maintenance scheduled restart of the backend (which restarts the i2c and fixes my issue, temporarily).
How would I best go about doing that timed restart of the backend? I’ve seen there i a restart system in one of the trigger timers but a rather not completely reboot.
Any advice would be welcome.
Enjoy earth day,
Does deactivating and activating the input fix the issue? If so, then the input should have a fix applied to it to reinitialize the sensor to fix the issue, rather than having to restart the entire daemon.
Thanks for responding Kyle,
No it doesn’t fix it. I should note I have the sensor behind a I2C multiplexer. I’m going to go trough the manual and also check my cable with which I lengthened the AS ezo-hum cable.
Could you elaborate on “the input should have a fix applied to it”. How can I do this? A script?
I asked this question because if the issue could be resolved by deactivating/activating the input, then a simple fix could be applied to the Input code. However, you said restarting the backend resolves the issue, which is nothing more than deactivating all Inputs, Outputs, Functions, etc., then reactivating them. I’m not sure how you’ve interfaced your multiplexer, but I’m not currently seeing how a restart of the daemon resolves the issue but a reactivation of the input doesn’t.
I’ve checked several things.
First off all, I checked when the sensor drops out the multiplexer still works. There are more channels used and they still respond.
(For instance there is a DAC connected to one of the channels that drives my 0-10V controlled fan)
I double checked my cable. It’s about 1.5m long and shielded. I’ve noticed that the cable’s used for lengthening from Atlas Scientific are about 2m and simply connected with headers. I’m not ruling out a hardware issue but I’m unsure how to go about debugging further.
Is there anything I can look for in the logs?
I double checked everything and the readings have been coming in without the sensor dropping out now.
The issue was a badly connected wire of the power supply.
Note to self, always double check connections on all parts.
In addition to the power supply there was also something “Funky” going on with the multiplexer as it was detecting the EZO-HUM on two I2C channels. I physically changed it to another channel and It detected the humidifier once instead of twice. All has been well for over 4 hours now without the sensor dropping out.
I also want to note dat apart of carefully grounding my circuit from one star point, I had forgotten to ground all my power supplies. I found out this was also causing transients all over when a freezer compressor on the same mains circuit was kicking in.
Basically my entire ground was floating and ready to jump around at the freezers motocompressors merci
1. Take care of properly grounding your DC circuitry
2. Take care of properly checking earthing of your AC/DC power supplies.
Glad to hear you solved the issue. Also, that is some good advice about grounding. A lot of problems often come down to power supply issues, but grounding and isolation issues can also be tricky to diagnose since they might not be immediately apparent and can almost spontaneously start occurring due to other electrical devices causing electrical interference.
One more small addition to this issue. A freezer on the same mains power strip was kicking spikes onto my setup when the compressor motor turned on and off. To suppress this I added a MOV (varistor).
It has been smooth sailing for 24h now.
Back in the day, when I was naively using the infamous DHT sensors, I found I had to physically disconnect and connect power to get it to work some times. Today, this can be easily done in Mycodo by connecting a relay to the power wires running to your sensors you want to reset, then creating a function monitor whether measurements are being acquired or not, and to respond by deactivating the inputs, turning the power off then on, then activating the inputs.