Best posts made by 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

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