GalaxyGuy

No, RIO's are not compulsory. There are 12 wired onboard zones on a Flex and 16 on a Dimension. Only if you need the additional wired or wireless zones, then you will need a RIO or RF portal. I'm saying that you really don't want to limit the panel capacity, as when you add more home automation based sensors, then you can easily reach the panel 12 zone capacity. If you buy an FX100+, then you can start at 12 hard wired zones and expand at a later date if you need to. The + panels also support many 'links' which are needed for home automation. There is no tie-in with the Virtual RIO module. It sits inside the control panel connected to the bus and publishes zone status to any MQTT server you select (the example I show above is running on a Pi Zero). It does not need the SelfMon platform to operate. The SIA over MQTT to SelfMon is only a convenient option for people should they wish to use it. There's nothing stopping you using the A083/E080 Ethernet modules and GX app or even the Ethernet to SelfMon. Note that SelfMon does have some advantages over the free Honeywell push notifications - like regular path testing and multiple messaging types which can be configured based on the priority of the event. Ie. Push notifications/email for all events, SMS for higher priority and voice for burglary or confirmed. Even with the current SelfMon setup, there's no need to give access to SelfMon to your system. The SIA events are sent to the platform by the control panel and SelfMon takes care of the message distribution via the various customer configured message queues - Push/SMS/Voice/Email/CURL. In this configuration, the control panel is the client connecting to SelfMon which is the server. For convenience, SelfMon does offer an HTTPS web based keypad to connect back into the control panel using the same security mechanism that the GX app uses with port 10001.

The development is a SelfMon product and will eventually support an MQTT based receiver at the SelfMon side and transmit panel SIA events via MQTT. As you can see from the image above, the virtual RIO devices have 8 inputs and 4 outputs and I've enabled 4 virtual module addresses on the test panel. The outputs are driven by the panel and can be forwarded links of zone status or just standard outputs like bells, set, etc. The panel sees the module as if it were a hardware RIO. When the output is set by the panel, the module forwards the status change to the MQTT server (broker) and it can be picked up by any subscribing client. The virtual RIO also subscribes to its own 8 input channels, so if you have another device that publishes a status change to one of the input channels, then that input change is sent to the control panel. The intention is that an automation controller will act as a middle-man in this process. That is, unless the other sensors have the capability to publish to specific MQTT topics directly. The reason for requiring the bigger panels is to maximise the number of virtual RIO's that can be enabled alongside wired RIO's. The FX100+ can take 11 external RIO's, so you can have the on-board, a couple of hard wired RIO's and then use the remainder of the addresses to maximise the number of virtualised outputs and inputs available. This is a block diagram of the device: http://www.selfmon.uk/manuals/LCE-K3/LCE-K3-MANUAL.pdf

jelockwood, have you tried this and managed to get it to run? I tried with npm and docker on my mac, but although it seemed to build, the image would just exit with no messages. I have an FX100+ sitting testing on the bench to test the software out. I've not used typescript at all so I may be missing something. These new abstracted languages seem really convoluted sometimes. Just a bunch of yaml files with abstract commands. Great when they work, but not so great when there's an issue. I don't think the author ever responded to previous questions, but his repo build instruction is definitely missing some parts.

Go for a Flex FX100+ as it supports lots of links and zones for automation. Here's the latest SelfMon virtual device module in action with MQTT. The project has been slightly delayed, as I've been assigned to work on covid for a few weeks.

It will only give a virtual keypad on the old G2-XX series, no other functions, so not worth it. You can upgrade to the flex grade 2 series to support one touch keypad. The metal boxed flex is the same enclosure, so you can swap the board and psu over without having to take the case off the wall.

Yeah, even though the standards dictate that alarm reporting doesn't use DNS, there's nothing stopping the design collecting an updated static pool of addresses from a DNS based server. That's how some companies do it. Still doesn't stop someone performing a ddos attack on their whole pool though. Attackers just need to get into one device to collect all the addresses, then disrupt the whole network.

If you've got an old A083-00-01 module in that panel, it can cause the panel to reboot if there are network issues. Try syn-flooding the panel network port... Quite a bad bug, especially with a Dimension, as the older E080-4 has the same issue... The A083-00-02, A083-00-10, E080-8 and E080-10 don't suffer from the issue. Also, with more recent firmware on the Flex, you can suppress any comm's issues in menu 51. If you use SelfMon or another ARC, you can leave the path check to them, rather than have the panel beeping all night. I don't believe that Honeywell's server move is anything to do with security, it's more likely to do with Brexit and Honeywell having to move their infrastructure around. What a terrible time to implement a change like this, especially when support is limited due to the lockdown.

It's trying to send events to the free Honeywell push notifications server. You'll need to contact your installer to understand the issue. Honeywell don't deal with the public and their support is limited. I run Selfmon, and can help with that, but not the Honeywell push issues.

With luck, you may be able to stay within a selected range, but depending on the tolerances, it may just result in false tampers. With the cost of the third party solutions being so high, I personally wouldn't bother.

It means that the panel uses an analogue to digital device to measure the voltage at the zone. The zone wiring includes resistors that, in various combinations, set the voltage to a different threshold. If the voltage is in a certain range, then that means the zone is open another range and the zone is closed. It allows the panel to determine multiple states with a single zone wire. Of course, with respect to 0v. So active sensors can have as little as three cores and still provide tamper and fault status. These 'connected' devices would need to interface with opto isolation or field effect transistors in order to not impact the voltages at the zones. The American market panels are more crude in their zone implementations. Just a pulled up transistor, so less of an issue for external connection.

I'm currently working on a virtual RIO module as part of something that I want for my own home automation. I'll sell this for the bigger panels like the FX100+ and GD96 upwards, as they have lots of links available. The virtual RIO sits on the RS485 bus and will consume 4 addresses, giving 16 outputs and 32 inputs in virtualised form. On my own system, I currently have lots of outputs programmed to switch lights, heating and garage door Etc, but I either control them from the app, or guard codes. I've been looking at OpenHab, so would like a way for linked zones with virtualised outputs to provide the OpenHab 'things' with status update calls over IP. There shouldn't be any reason that the virtualised RIO cannot send the calls to any other controller, it's just a matter of the appropriate protocol. This is basically what some of these other hardware vendors do for Vista, but instead of the compatible device, they physically hook into the existing zones and outputs wiring. This would cause an issue for the Galaxy, as it uses balanced circuits, so any external influence on the circuits would cause problems. The virtual RIO will only need connected to the bus and an Ethernet connection, so a simple addition. Since the inputs and outputs are programmable, it's entirely up to the person who configures the system as to the level of control allowed. An input call to the virtual RIO could set a zone as active and in turn fire another physical panel output, or set the system. Basically anything that the panel is capable of. For me, I think the timers and sequence based logic is limited on the Galaxy, and that's where the home automation excels.

You can also use easy set single button push to set. Not great if you've got children who would play with the keypad. Can't say my grandchildren have ever went near the rkp's though!

More around £30 to £40 now. I've had a few come to me to buy the -08 / -10 after their -04 eBay purchase has failed after a few months. Too late for any comeback on eBay, so they just accept the lesson learned and part with the money to get their system working again.

Yes, some network misconfiguration can also crash the panel (I've had a couple of customers who have experienced that), but low risk compared to the CPU going pop. The board is scrap once this happens. If you have an older module and it works, then it may keep doing so. The longer they lie on the shelf without power makes it more likely to fail. I wouldn't sell the older boards now, as they're just a headache.

Yes, an E080, but buy an E080-08 or an E080-10. The older models have a bug that allows a syn-flood to crash the panel. The E080-4 and A083-00-01 modules use an obsolete Texas Instruments CPU that has a burnout problem. You'll get an old used E080-4 on Ebay for around £30, but it may not last for long before it dies. The E080-08 and E080-10 are based on a new CPU design that doesn't have any of those issues.