Have you seen the Cave Pearl project?
Loads of detailed discussion of the challenges of underwater sensors, I love it:
@user2684 FYI, I was successful in getting the periodic reporting to work. If you are interested, here's a branch of mine that has it running. I'm reasonably happy with how easy this was, the FEATURE_HOOKING turned out nice.
Thanks for your work!
@user2684 , glad to help.
I guess there's several situations imagineable. I made a fork and will play around with some options. I understand your point of view also, so anything I do should eventually be configureable.
Actually, I am working with HomeAssistant, and it actively discards updates where the value did not change, so in that case it is no issue to receive multiple updates of the same value (actually, there has been much discussion on this in HomeAssistant, as this behaviour also makes it difficult to see weither or not a sensor node is still online, or that the value simply did not change).
I can explain my use case: I have a reed switch mounted to a lock, which is supposed to report the locked/unlocked state of the lock. For this application, the state switches are quite infrequent (max a few times per day), but can also be in very quick succession if someone changes their mind while opening the lock.
I want to be reasonably sure that I have the correct state in the controller. Now, we are working with battery-powered radio nodes, so there is always the chance that a message does not get transmitted or received for whatever reason. This will lead to the state in the controller being incorrect, and this incorrect state will continue until the next correct state change gets received.
I want to be sure, that after a max of n minutes, I can conclude that either the state is surely correct, or the node is apparently offline. Otherwise, the state might be incorrect (perhaps for days at a time).
In the current implementation of NodeManager, when the
SensorInterrupt (I am using
SensorDoor) fires twice in quick succession (open the switch, then close it before the state change message gets sent over the radio), we end up with an incorrect state. The second interrupt fires before we send the first message and therefore we do not send the second message.
This situation is totally not implausible, it happens to me sometimes.
It also ends up leading to an incorrect reading at the controller.
As I said, I'll spend a few weeks of play time trying to come up with a way to trigger regular timed updates. Of course this must be configureable, in order to be ok with your use case. I am thinking this could be achieved in several ways:
onLoopand let it gather the data. Probably remove data gathering from the onInterrupt routine, but somehow signal to the loop that we were woken up and need a message sent.
SensorDigitalInput, but add an interrupt routine to wake up and send a message.
Would love to hear your thoughts,
I took some time yesterday to try out the development branch, and I must say that it seems to be a great step forward. I love how all configuration now is in one file, and that you now get direct access to the Sensors' objects. Also, the FEATURE_ constants really simplify configuration.
One thing that surprised me, which probably was the same in the previous versions, is that the interrupt driven sensors (
SensorInterrupt and its derivatives), define an empty
onLoop. This way, it is not possible to get them to report it's status after a given interval, despite not having received an interrupt. Something like the Force Update Timer in Conditional Report mode.
That's a feature I would like to have: a sensor that responds to interrupts (so has an immediate response to change, but sleeps a lot), but also sends a confirmation of its status every now and then.
I imagine you have thought about this yourself: how would you feel if I tried to formuate a pull request for this feature?
I suspect that this may also explain some strange behaviour that I see on
SensorInterrupt sensors when
FEATURE_CONDITIONAL_REPORT == 1. In that case, it seems that the
SensorInterrupt never manages to send an update message. See my logfile here. This works fine with conditional reporting switched off.
Or am I just interpreting things wrong? I have to admit that I'm quite new to MySensors.