Hello,

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.

Best regards,
pragtich

Hello,

I noticed that you did not yet get an answer. While I have not worked with this specific combination, I do have a NEO2 with armbian, and have played with GPIO on these a bit. Maybe I can help?

No experience with RS485 on mysensors, though...

My first thought is, that it is very easy to get confused with pin numbers on these boards, with chip pin numbers/board pin numbers/linux GPIO numbers potentially all being different. You can look at Friendlyarm's gpio tool (specifically 'readall') to help test and clarify. Are you sure that your driver enable pin is correct? Do you have a multimeter or a scope to check weither it is being activated? I would try and use the sysfs interface to test your chosen driver enable pin.
I found a simple explanation here, if you are not familiar with the gpio sysfs system.

Also, you can temporarily connect the TX and RX for your serial port and do a loopback test with screen /dev/ttyS1 9600 or another terminal program. You should see any characters that you send coming back to you if the serial port is working right.

Is that perhaps helpful?

Best regards,
pragtich

Have you seen the Cave Pearl project?

Loads of detailed discussion of the challenges of underwater sensors, I love it:
Thecavepearlproject

Hi @mariuszjozala ,

Thank you for reporting back. Glad that it works now!

In my eyes, the good documentation (and availability of LTS options) is one of the really big plus points of the NanoPi/FriendlyARM products. I did save a local copy of their wiki, just in case it ever disappeared, because these references are really helpful.

Best regards
pragtich

Hello,

I noticed that you did not yet get an answer. While I have not worked with this specific combination, I do have a NEO2 with armbian, and have played with GPIO on these a bit. Maybe I can help?

No experience with RS485 on mysensors, though...

My first thought is, that it is very easy to get confused with pin numbers on these boards, with chip pin numbers/board pin numbers/linux GPIO numbers potentially all being different. You can look at Friendlyarm's gpio tool (specifically 'readall') to help test and clarify. Are you sure that your driver enable pin is correct? Do you have a multimeter or a scope to check weither it is being activated? I would try and use the sysfs interface to test your chosen driver enable pin.
I found a simple explanation here, if you are not familiar with the gpio sysfs system.

Also, you can temporarily connect the TX and RX for your serial port and do a loopback test with screen /dev/ttyS1 9600 or another terminal program. You should see any characters that you send coming back to you if the serial port is working right.

Is that perhaps helpful?

Best regards,
pragtich

Have you seen the Cave Pearl project?

Loads of detailed discussion of the challenges of underwater sensors, I love it:
Thecavepearlproject

@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!

pragtich

@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).

Example:
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:

1. Add a onLoop and 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.
2. Base everything on SensorDigitalInput, but add an interrupt routine to wake up and send a message.

Would love to hear your thoughts,
best regards,

pragtich

Hello,

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.

Best regards,
pragtich