No I have not. My kid brought a bug from kindergarden so i'm on sick leave with 39.5 degree fever 
. I think thursday I'll be going to work and I will see if the pi is still online and I hope the uptime will be 6 days. Kind of an ultimate test
Ah yes the joy of kids. Sorry to hear that and hope you get well soon. No rush, I will keep a look out for your message.
1 Like
So my doc extended my sickleave, despite me feeling better but I'm not complaining but i didn't want to leave you hanging so I rang my cooworker and had a lonnng conversation on instructions on how to ssh to the device and open up "btop".
First of all the watchdog led is blinking at a constant pace (so that is a really good sign) and btop shows 231Mb of memory consumtion (also super great) and CPU usage is in the green (jumping up and down to about 5%) and the uptime is 6days 8 hours and 17 minutes
It is safe to say that my flow is working great, your nodes work perfectlycand the problem was the system resource polling.
The only thing is that he didn't update your node to the newest version so there is some logging but it does not pose a problem. The logging thing will have to wait until monday.
1 Like
I appreciate the update and good to hear the system is working well. Be well and enjoy the extra leave. Look forward to hearing from you Monday.
1 Like
Sitting pretty at 10days and 21 hours, I updated your node and I will restart and test again..
EDIT: Upgraded and working. I can confirm that the lopgging works as expected. I will let it run for a few days
Thank you
1 Like
My pleasure. It should work (just to be sure I have a led blinking here on my test system and it has been running for about a week now). No logging going on, but then I don't poll.
1 Like
One more question. So this works great, but I would like to make it a bit bulletproof. I'm testing different situations if the communication fails or if it picks up noise.
I'm runny the flow and I tried reseting the chips while running and the ting is it does not recover from the failed communication. The only way is to restart NodeRed. Is there a way for your node to re-initialize if the communication drops, without restarting NodeRed?
Not quite sure what you are getting at when you say
Not quite sure what you mean by resetting the chips. Do you mean, on start-up, e.g. after restarting NodeRed, get last known port status for each chip and continue from there, as opposed to a default restart. Also, what communication are you referring to. Can you give me an example?
I like to test my projects for various scenarios. The MCPs have a Reset pin. Just for fun I toggled the pin while the flow is running and i expected the node to re-initialize after it got a communication error.
Its not a tipical scenario but it shows that if the i2c communication drops for some reason there is a chance that the node will not recover from the error unless you restart it.
For testing i'm now watching if the communication is alive and if it fails I restart node-red automatically
I do not use the reset pin in my node, so expecting it to re-initialize after resetting is expecting maybe a bit too much. That being said, i2c is pretty sensitive to noise. I can look into adding a reset button on the node, that would capture the last read status from the log (and could maybe be used for the PCF chips as well). The reset would be a software reset on a chip by chip basis. Would that help?
As far as the hardware goes, usually hardware resets are all tied together, thus resetting all chips at once. If this occurs outside of the realm of NodeRed, NodeRed would not be aware of any state changes and probably need to be restarted. You would need to reset the hardware using an inject button and one of the GPIO ports is my guess.
I made this bosrd with 5 chip that have all resets tied together. The reset line is pulled up and there is a jumper that connects to an STM32C011 microcontroller. That STM32 serves as a watchdog. One of the MCPs has two I/Os tied together (one is configured as input and the other as output) and they connect to the STM32. So my flow toggles the output every 0.5s and it also reads the input ( with a small delay) so this way NodeRed knows if the system is working or not. If it does not i currently have an EXEC node that injects a systemctl restart node-re.service. Also if the STM32's input stops toggling it sends a reset to all MCPs. I did this brcause the board controlls 13 window blinds (13 up and 13down outputs) plus it controls 8 lamps that are embedded in the stairs. If the thing hangs the STM32 will reset the chips and turn off any outputs that maybe still on if the freeze occurs.
Currently this works great and I simulated a few worse case scenarios.
But I asked if there is an option only to restart your node (or if the node it self could be restarted if an error occurs) so I wont't need to restart the whole service.
Got it (I think...) and the short answer is no, there is no option currently to only restart this set of nodes. I'd have to think about how to go about doing that and I would have to be careful. There could be a multitude of nodes in the flow and what's to say it's not some other node that is causing the error. Also, I'd have to think about what exactly constitutes an error, e.g. an i2c communication error is easy enough to detect, but determining whether an output is indeed correct is a whole different issue.
I think the way you have it set up works best for your situation.
Aaa ok got it. Look I think you shoul leave the node as is because it works great. You are right error handling is easyer for the user brcause they know what is goin on and what they need. Lets close this and leave the thing alone.
You have to leave the party when it it at its best sou you are not dissapointed
Thank you again for you great and hard work 
2 Likes
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
