The RF RIO appears on the bus as a device, like any other, and the panel (I am testing with a G2 here) allows up to 8 inputs on the RIO to be set up. This very much mirrors the normal RIO with 8 inputs, and they can be set to intruder, or whatever...
Each input is set with a "serial number" of the attached device, which can be auto detected, to save time.
The device can report a signal strength 0-10 out of ten, or as the panel says, out of 00 (seriously is says 10/00).
So far so good. It seems to work.
But why only 8 devices. Well, the instructions actually suggest that to avoid RF congestion you do not have more than 24 devices, so I assume other panels allow more than 8.
But looking at the bus, it is simple. I am using the V2GY protocol, but there is a later ALPHA protocol which is somewhat different, but for both the RIO simply reports status updates from the devices with its serial number.
Importantly the RIO does not care if the device is configured on the panel or not. Any device in range at RF level will be reported, including, it seems, around four devices that my neighbours must have! So any suggestions of avoiding RF congestion fall down when it is not in your control as neighbours could be using these devices in the same RF "space".
Indeed, any idea of limiting traffic on the bus is irrelevant as all these extra devices get reported to the panel even if it knows nothing about them!
I am working on including in my alarm code, and I will not limit to 8 per RIO - there is no point - all devices in range of a RIO will use RF and bus bandwidth anyway, so why not allow them?
I am wary of RF connected alarm bits, to be honest. I think wiring in is better. But this is progress for the alarm system to support these.
The G2 supports two RF portals and 2-20 will map an additional 8 zones in a virtual RIO, or also overlay across existing 12 onboard zones. The 0 in 10/0 is not the denominator, it's the signal level from the second portal (if fitted).
ReplyDeleteH, thank you. That makes a lot more sense.
DeleteI always wondered about the reasoning for RF alarms that seem so common now. You can't have a tamper wire, as there's no wire, and unless the thing is powered by batteries (*really* bad idea for obvious reason) you're going to have to run cables anyway.
ReplyDeleteSurely to break into somewhere with such a system all you have to do is run RF interference on 433Mhz. Illegal, but so is breaking and entering..
They use batteries, with several years of life and probably reporting of low battery. They have physical tamper. Apparently some may even be frequency hopping. Even so, sounds a tad iffy - small transmitter could cause constant tamper or loss, and so you cannot set the alarm!
DeleteHi. Years later I know...but out of interest I'm another one who likes reinventing the wheel and have a similar project written in python. It will be public on github soon. Having spent a weekend playing with RF devices, timing seems quite important. As far as I can tell, the devices (V2GY) only send an FD message to the panel when something happens and different thresholds within that. I believe I have deduced that when in tamper they report (setting bit 6 of byte 7) when it happens and then repeat every 5 minutes. If normal they report in every 10 minutes. If activated they report in (setting bit 7 of byte 7) and then don't send a further activation message for 3 minutes.
ReplyDeleteI'm curious if you observed similar. At moment I'm logging last contact time with device and declaring it missing / dead battery if it hasn't reported in for 20 mins. I have a feeling the lsb's of byte 7 might be reporting battery state, but not cracked that yet. Happy tinkering!
Hey,
DeleteDid you get this up on github? I'm interested in decoding Honeywell RF signals and this sounds like it would be a very useful start. Even in unfinished/unpolished state I'd find this very interesting.
Thanks!