Does Sonoff have a way to detect water leaks in home? I am using Sonoff TH16 to monitor the temp in my freezers and all of the installations work great.
Test was a success. My Dryer sensor is now a repeater as well. I was able to move my motion sensor farther from my dryer and have it work the same.
1 Thing to note is I did have to restart the gateway in order to get the motion sensor to flow through the repeater. Something that could be improved on maybe?
@mfalkvidd - Sorry I didn't make it clear but I was thinking of doors, windows, blinds and curtains. Curtains don't usually have UP or DOWN, they are OPEN and CLOSED.
Likewise with doors and windows which are normally OPEN or CLOSED. Only if V_ARMED is set true should it send a value of V_TRIPPED. But in normal circumstances they are OPEN or CLOSED (or maybe smoewhere inbetween, but V_PERCENTAGE handles that situation).
Hi,
Increasing the MY_SMART_SLEEP_WAIT_DURATION_MS would probably work, but I assume this waiting happens while the sensor sketch is running (at least the RF needs to be powered on), thus decreasing battery life.
But I think I will give it a try soon and see what happens.
Thanks for the precious info!
BR,
Costa
In all honesty, I'm not quite convinced you'd need two separate networks. Just provide the security sensors, the repeaters, the gateway and your controller - that form the security system - with some sort of ups and they will keep running until the UPS has no more power left.
The none security devices will stop working when the power goes out and, unless I don't really understand your problem well. That does what I think you want to achieve? Unless you have combined a lot of sensors within a repeater it would really be my way to go. It wouldn't mean any modifications to your security hardware, because they need to be battery powered or have some sort of UPS anyway, to keep working when the power goes down.
But again it's hard to judge when you don't really understand the problem some one is trying to solve.
Yes, I read it. I started using your approach, gateway sensor ids representing nodes ids, but from the controller point of view this is not straight forward, I think. The 2 problems remain somehow the same. How to get the controllers to understand that gateway sensors are not actually sensors but RSSI value, and repeaters breaks my current algorithm.
Thinking more about this, if it is something the library would benefit, lead me to read about the RF24 and NRF5 radios. I only have RFM69 devices (20 nodes) and it offers RSSI out of the box, same as RFM LoRa version and NRF5. But RF24 lacks this feature. So it somewhat depends on how many are using radios with rssi. Library developers included RSSI functionality, so it has to be of interest.
The repeater problem is partially solved because RF24 networks need repeaters, but don't have RSSI. RFM networks should do without repeaters for most applications. For NRF5, I lack this info. But as I passed the rssi from transport to gateway transport, same can be done with actual sender from the header.
Maybe in version 3.0.0 something like this can be implemented? My understanding is that controllers get link quality data the same way they get all other data from devices, on other platforms. Mabey a I_LINK_QUALITY type can be added especially for this information?
for example my zigbee network:
zigbee2mqtt/device {"linkquality":5,"state":"ON"}
