Complete shutdown of MySensors in code possible ?
-
Is there a way to completely shutdown all MySensors code via code (not via compile defines, but a decision made in code) ?
-
@gertsanders No, but you could modify the MyMain<Arch>.cpp files, e.g. for AVR:
https://github.com/mysensors/MySensors/blob/development/hal/architecture/AVR/MyMainAVR.cpp#L30
with a conditional execution of _process()
-
I'm building a MySensors aware clock. However, I need to provide for the situation that the netwerk is down (gateway without power, or not installed). Or there could be a problem with the radio. In all cases I want the clock to still start up and run without apparent slowdown.
What I found was, that when I do not install a radio, the MySensors library is aware of this (a FALSE result from isTransportReady() ), but the MySensors code seems to take it's time and hog the processor by trying to reconnect.
This is visible on my clock, because the time on the display seems to "freeze" for some seconds. As I use a real RTC, this not really a big problem, but it is visible none the less. And being a perfectionist, I do not want a clock which seems to jump a few seconds now and then.
So the question is how to skip these processor intensive parts if the user accepts that the clock should work without MySensors integration.
Any suggestion is fine :-) -
I'm building a MySensors aware clock. However, I need to provide for the situation that the netwerk is down (gateway without power, or not installed). Or there could be a problem with the radio. In all cases I want the clock to still start up and run without apparent slowdown.
What I found was, that when I do not install a radio, the MySensors library is aware of this (a FALSE result from isTransportReady() ), but the MySensors code seems to take it's time and hog the processor by trying to reconnect.
This is visible on my clock, because the time on the display seems to "freeze" for some seconds. As I use a real RTC, this not really a big problem, but it is visible none the less. And being a perfectionist, I do not want a clock which seems to jump a few seconds now and then.
So the question is how to skip these processor intensive parts if the user accepts that the clock should work without MySensors integration.
Any suggestion is fine :-)@gertsanders could setting MY_TRANSPORT_WAIT_READY_MS to something quick enough to not be noticeable work?
An alternative could be to use a timer interrupt to drive the update of the screen and make sure that interrupt has higher priority than the radio interrupt.
-
@mfalkvidd I set it to 1000ms, but the jumps are sometimes 3 - 4 seconds. I was hoping that shutdownTransport() would do the trick. But that does not seem to help. It looks like I need to define a hardware_shutdown button or something.
-
@GertSanders I can't know where you stand pricepoint wise, but this sounds like a 2 MCU project. One to handle the clock functions, and one to communicate with MySensors. Messages between the 2 MCU's over I2C.
If the link is down, that will only clog the comms MCU.
