Anybody used LoRa devices?

vc1234 said:
There are two kinds of Honeywell/GE wireless sensors, and probably other brands. A motion sensor sends a signal when motion is detected and then sleeps for 3min.  A door sensor is triggered/cleared similarly to a wired sensor (a signal is sent when it's violated and another one is sent when it's cleared), so it does reflect the state change both times as opposed to a motion detector.
 
The problem is the door sensor never verifies its state between the open and close transmissions. If the controller misses a transmission here is nothing to correct it until the next time the door is moved. A wired connection is polled so the status is updated every 20ms or so and is therefore self correcting. I know it is not practical for a wireless device to send an update that often but once a minute or so would be reasonable and would ensure the controller doesn't get out of sync with reality.
 
upstatemike said:
The problem is the door sensor never verifies its state between the open and close transmissions. If the controller misses a transmission here is nothing to correct it until the next time the door is moved. A wired connection is polled so the status is updated every 20ms or so and is therefore self correcting. I know it is not practical for a wireless device to send an update that often but once a minute or so would be reasonable and would ensure the controller doesn't get out of sync with reality.
Right, H/GE wireless sensors are very rudimentary, there is no acknowledgement or re-transmission if the packet was lost.
 
upstatemike said:
The problem is the door sensor never verifies its state between the open and close transmissions. If the controller misses a transmission here is nothing to correct it until the next time the door is moved. A wired connection is polled so the status is updated every 20ms or so and is therefore self correcting. I know it is not practical for a wireless device to send an update that often but once a minute or so would be reasonable and would ensure the controller doesn't get out of sync with reality.
Most wireless sensors send a heartbeat transmission to the alarm panel once an hour.  Batteries typically last 5 years.  Sometimes less, sometimes more, depending on how often the transmitter is activated by the door or window actually opening or closing.
 
One transmission per hour for 5 years is 43,800 transmissions.   If you were to reduce that to once per minute,  the 43,800 transmission mark would be reached in about 30 days, and it would be time to replace the batteries.  Not very practical.
 
RAL said:
Most wireless sensors send a heartbeat transmission to the alarm panel once an hour.  Batteries typically last 5 years.  Sometimes less, sometimes more, depending on how often the transmitter is activated by the door or window actually opening or closing.
 
One transmission per hour for 5 years is 43,800 transmissions.   If you were to reduce that to once per minute,  the 43,800 transmission mark would be reached in about 30 days, and it would be time to replace the batteries.  Not very practical.
I could live with once per hour as long as the heartbeat contains sensor status and not just "I'm still here".I'm having trouble pulling that level of detail out of the published specs for the different hardware/protocol options.
 
upstatemike said:
I could live with once per hour as long as the heartbeat contains sensor status and not just "I'm still here".I'm having trouble pulling that level of detail out of the published specs for the different hardware/protocol options.
I'm pretty certain that the heartbeat transmissions do contain current status.  When you first power on the M1, it does not know the status of any of the wireless sensors, and it has no way to request the status from them.   It would have been nice if the Elk 2-way system included that capability, but it doesn't appear to.  My guess is that they felt that system reboots were rare enough that it wasn't necessary.
 
So it can take about an hour for it to collect the status of all the sensors, as each sensor does its next hourly transmission.  The only way to speed things up is to go around and open/close all the doors and windows to force an immediate transmission.  If the heartbeat didn't contain status, the M1 would never know the status without a forced transmission.
 
RAL said:
I'm pretty certain that the heartbeat transmissions do contain current status. 
You are right.  Here's a Honeywell door sensor sending status every 70 minutes:
 
2020-9-5 9:24:18 PM    RFX    0212973:0:1:1:1:0:0 heartbeat + violated (bit 1 -> heartbeat+ bit 2 violated)
2020-9-5 8:12:42 PM    RFX    0212973:0:0:1:1:0:0 violated
2020-9-5 8:09:32 PM    RFX    0212973:0:0:0:1:0:0 clear
2020-9-5 8:09:26 PM    RFX    0212973:0:0:1:1:0:0 violated
2020-9-5 6:58:45 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
2020-9-5 5:47:20 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
2020-9-5 4:35:59 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
2020-9-5 3:24:37 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
2020-9-5 2:13:13 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
2020-9-5 1:01:43 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
 
vc1234 said:
You are right.  Here's a Honeywell door sensor sending status every 70 minutes:
 
2020-9-5 9:24:18 PM    RFX    0212973:0:1:1:1:0:0 heartbeat + violated (bit 1 -> heartbeat+ bit 2 violated)
2020-9-5 8:12:42 PM    RFX    0212973:0:0:1:1:0:0 violated
2020-9-5 8:09:32 PM    RFX    0212973:0:0:0:1:0:0 clear
2020-9-5 8:09:26 PM    RFX    0212973:0:0:1:1:0:0 violated
2020-9-5 6:58:45 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
2020-9-5 5:47:20 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
2020-9-5 4:35:59 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
2020-9-5 3:24:37 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
2020-9-5 2:13:13 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
2020-9-5 1:01:43 PM    RFX    0212973:0:1:0:1:0:0 heartbeat+clear
I assume that the M1 will utilize that heartbeat data to update the status table and not just reset the timer for a missing sensor trouble? 70 minutes should be OK if it really does put things back in sync.
 
upstatemike said:
I assume that the M1 will utilize that heartbeat data to update the status table and not just reset the timer for a missing sensor trouble? 70 minutes should be OK if it really does put things back in sync.
It's a good question. Not sure how to test that. Perhaps, you can put the sensor in a metal enclosure, trigger it there, make sure that elk did not receive the status change packet, let the sensor out of the Faraday cage and wait 70 minutes to see if the heartbeat updates the status.  Something like this...
 
upstatemike said:
I assume that the M1 will utilize that heartbeat data to update the status table and not just reset the timer for a missing sensor trouble? 70 minutes should be OK if it really does put things back in sync.
Yes.  It needs to update the status since at initial power-on time, it has no status data for any of the wireless sensors.  Eventually, after they have all sent a heartbeat, it's all back in sync.
 
Final 2 questions:
 
Does the M1 sensor state update work the same way with all three of the  wireless technologies it supports? (Elk two-way, Honeywell, Elk 319MHz/Interlogix)
 
Can I expect something similiar from other wireless technologies such as Zigbee or Z-Wave or Insteon, (or LoRa) when used with Hubitat or a dedicated proprietary hub/receiver?
 
upstatemike said:
Final 2 questions:
 
Does the M1 sensor state update work the same way with all three of the  wireless technologies it supports? (Elk two-way, Honeywell, Elk 319MHz/Interlogix)
 
Can I expect something similiar from other wireless technologies such as Zigbee or Z-Wave or Insteon, (or LoRa) when used with Hubitat or a dedicated proprietary hub/receiver?
From everything I can tell, there is no difference in how the three types of wireless receivers operate with the M1 in terms of zone information. It seems like the interface to the M1 operates the same way across the different types, while the receiver handles the details  of the wireless protocol.
 
I can't specifically say whether the other technologies do anything different.  They all face the same problem of trying to maximize battery life by minimizing transmissions.  Even staying awake to listen for a query from the host or hub costs power,
 
upstatemike said:
Final 2 questions:
 
Does the M1 sensor state update work the same way with all three of the  wireless technologies it supports? (Elk two-way, Honeywell, Elk 319MHz/Interlogix)
 
Can I expect something similiar from other wireless technologies such as Zigbee or Z-Wave or Insteon, (or LoRa) when used with Hubitat or a dedicated proprietary hub/receiver?
I am not familiar with Elk two-way.  H/GE are the same in the sense of blindly firing a packet and hoping it will arrive. Usually, it does mainly due to being low frequency and thus penetrating obstacles better than 2.4GHz signals.
 
Zigbee and Z-wave have worse signal propagation characteristics (2.4GHz & 915MHz), but they have provisions for re-transmitting a packet if acknowledgment was not received. Both have  battery conserving features, e.g. a zwave battery sensor sleeps until it detects a change then initiates a dialog with a controller. Zwave has a heartbeat command class but it's not widely used, e.g. my zwave lock sends battery status once a day.
 
In my experience (CBS walls), Zigbee/Zwave sensors despite being technologically rather advanced and much more secure in comparison to  H/GE sensors  which are completely insecure are less reliable due to their unfortunate choice of the signal spectrum primarily. Their battery life is about one year on average in comparison to more than 5 years for H/GE sensors which is to be expected.
 
I have a Zigbee temperature sensor, Zigbee motion detector sitting outside, an outside Honeywell motion sensor and a zwave lock.  I've not touched the Honewell sensor in more than a year (since I installed it).  The lock is ok too, but it's indoors.  The outdoor zigbee sensors have been no end of trouble until I managed to modify their antennae in the way that made reception acceptable (it's no fun unless you like this sort of stuff).
 
In the end I decided to use Yolink LoRa devices with Homeseer virtual devices to accomplish what I want. When I first got some Yolink stuff to test I was amazed at the signal distance and penetration. I have 8 WiFi access points to deal with all the shadows and dead spots caused by the heavy stone and brick and plaster construction in my house. When I got the Yolink hub I didn't put it anyplace special, just set it on the kitchen counter because I had a spare ethernet jack there. I then set up a leak sensor to make an announcement through all of my Echos and started walking around with the sensor and a damp paper towel to get an idea of the range for the system. I could not find any location where the sensor did not trigger reliably. From the floor of the deepest corner of my basement behind the water softner to the longest distance I could get to on the third floor the sensor just worked every single time. Using Alexa routines to turn homeseer virtual devices on and off based on Yolink triggers has been nearly instantaneous. 
 
I know that the cloud dependency is a weak point for this technology but I don't use it for anything super critical and the advantages are incredible coverage, easy installation, 5 year battery life, standard AA batteries, and super fast reponse time triggering Alexa routines and Homeseer events through Alexa routines. No mesh to build out, no device drivers, no repeaters or extenders. It just works.
 
Back
Top