Topics created by mihai.aldea

@mihai.aldea That is because it was written before I knew you were using LoRa. Look at the sentence just before that question. It says "If I understand correctly, you are using the fsk mode of the rfm96?"

They're an interesting option in special use cases. Eg. I mounted a sensor on my flat building janitor's storage room. I wanted to know if she comes daily as agreed and if so, how long does it take for her to clean the staircase. The RFM69 modules didn't worked so I switched to RFM96 which struggles to get the signal through 2 floors and on the other side of the building where I placed my gateway. And this while using RFM95_BW31_25CR48SF512. It works, but if I were at the 3rd floor, I'm sure it wouldn't have worked. Next thing I want to monitor the status of the water pumps that are in a special room beneath ground and also on the opposite side of the building. And I'm pretty sure that the RFM95 will not make it there unless directional antennas or repeaters are involved.

I tried both. 3.3/5V over FTDI and 5V externally.

Thank you, but right now everything's working as expected. My only concern is that the tweak you told me about should not be so obscure but way more visible and easy to toggle. I'd like to have the input of a senior developer of MySensors because I may be mistaking but if not I don't know why no one considered this yet.

@gohan Fair comment, it was the best tool to resolve the problem. I spent 3 days reviewing what I had programmed, inspected wiring, and testing all DS18B20s, two of which are in the loft, only to discover that a faulty telephone socket had partially dislodged it's pins, my tool to resolve? A magnifying glass.... Isn't technology wonderful...

@Fritzin On download page you have users manual too. Kindly refer it.

It seems that adding: #define MY_PARENT_NODE_IS_STATIC is of some help, however I did noticed a large increase in TX time even though i set boolean requestACK = false; So the whole protocol appears to resemble more with TCP rather than UDP. All things considered I believe the remote battery powered nodes should be able to successfully recover from a temporarily gateway failure without increasing their TX time substantially. The TNR state is excellent when it comes to TX time during gateway failure but it misses a mechanism to automatically recover from this state once the gateway is back. ** MY_PARENT_NODE_IS_STATIC** allows for recovery but at the expense if doubling the TX time. So in production you either manually reset all sensor nodes after a gateway failure, or you take immediate action to minimize the impact on the sensors batteries.

@Chester I've seen that page, thanks. If you read the post I'm referring to, @executivul used some specific procedure to tune the antenna further than just using the theoretical length.

No, I haven't seen any api call to remove variables from a device. You can always remove/re-include device.