GalaxyGuy

I had included the bell, wiring Etc. in the £150 price. Plenty of distributors out there seem to be 'splitting kits' and the ancillaries are really cheap too.

Try the Honeywell Galaxy or Texecom panels. The system price will be much less than £500, but will not be as little as £50. The Galaxy G2-12 based system can cost as little as £150 and Ethernet can be added for £50 to £200 depending on the module. Some parts of these systems are priced reasonably.

Interestingly, the documentation is pretty vague on this for the detectors. The RF fobs are certainly two way, but looking at the V2GY and Alpha protocol details on some of the detectors, they state that supervision is 9/18 minutes respectively. No mention of two way control over the detectors to request status / preserve battery life Etc. Is it possible to get a 5yr battery life from a detector with a 9 minute supervison poll without some sort of sleep mode control from the panel ? I'm confused, as the documentation at the portal level is all 'two way protocol', but the detectors don't mention it. In saying that though, the detectors documentation comes from Honeywell France and it's really really poor for anything other than basic mounting of the device.

No, Galaxy Alpha peripherals are two way. The panels can accept older V2 peripherals, but Alpha is the recommended protocol.

Perhaps with the old RF RIO with the Galaxy, but not with the RF portal. It should be reporting '+RF BAT Low' before the fail.

Yes, from the description of the cable installation, it would probably make sense to perform some tests on the cores for water ingress Etc. The RIO's are very reliable. A cable swinging along the back of a fence - less so.

I meant the 12V power supply. The RS485 lines are differential pair data, so can change voltage depending on traffic, but the fact you were reading a voltage would suggest some traffic on the bus when the system is failing. When you read these signals, it's best to read each voltage with respect to ground. If there is traffic at the terminals at the RIO, and other devices on the bus (keypad) are not showing any issues, then you still could have a power supply issue at the RIO or a faulty RIO.

There's a point in there that the RIO drops out for a few hours - I would suspect power or a failing part. Check under diagnostics for the RIO - voltage and comm's. Press the hash key. Also check the voltage at the RIO with a meter. If there's some sort of power issue (sometimes caused by battery), then some devices will show issues before others. If everything looks okay, then start eliminating by swapping the RIO first. They are normally very reliable though!

Please privide info of firewall penetration without some form of punch through!

CG, I've not had time to digest the whole thread and links, but are you saying that these devices have some inbuilt malware that's opening outbound connections and allowing attackers to reverse tunnel back through ? If not, how are externals getting through the Firewall ?

Rob, your understanding is incorrect. All of these hacks are automated and it doesn't take an expert to implement them. Once you have root access to a device, then you have access to the sub network it sits on. Basically, don't set up port forwarding for customers - alway use a VPN for internal device access. If installers cannot set up a VPN, or don't really understand IP networking, then they need to get some training or subcontract that part.

You need to set these options too: Menu 51.13.1 - On + Key Fob Panic Menu 51.13.2 - Audible Panic

As per Al's advice, restart will flush the errors. The other (correct) way is to send two successful events to selfmon (eng tests) and then enter as engineer and view the faults to clear them.

The Flex is supported in both V1 and V3 variants. V3.18 seems fine with standard configurations. The only issue I have seen with 3.18 is where the customers have more than one ARC (seems common in the Netherlands) and both IP and GSM modules fitted. Every now and again the panel will transmit the other ARC account payload into the wrong receiver - like a broadcast to all receivers. Until a fix is provided by Honeywell, I have implemented a software based work around to stop the account being blacklisted for this. I would probably still choose a Dimension 48 over the Flex, but agree with the above that it's not as 'domestic friendly' with default settings. The internal speaker really needs to be switched from 'horn' mode to 'siren' to stop the loud exit tones and set confirmation (it would be so easy to add an option in firmware to change this, but I suppose it causes overlap in the target application for the panel). Although I also like the big solid wirewound TX, I've seen no issues with the efficient SMPS, and nobody seems to have issues in having these in the vast majority of appliances these days - apart from longer term when cheap leaky caps are used that is...

The E080-4 Ethernet module firmware is now at 3.05, so probably a few fixes applied since 3.02... Yes, I need to add some more features to the SelfMon app. I still use guard codes to switch outputs at home - means I can use the keypad as well as the phone - more convenient for opening the garage door on the way out than messing with the phone.

Have you tried entering eng mode and power cycling the Ethernet module? Ie. Remove/restore power to it.

The app auto updated recently. Not sure if that is at the root of the issue. Have you tried adding as a new site?

Yes, this has been discussed and is well known. I think we are all in agreement that VPN access using the likes of Open VPN with regular updates is the way to go. Trouble with it is that the router needs to support it and it's much easier to pop open an insecure port on most routers...

I think the Tuxedo display is much better than the current TouchCenter and there shouldn't be any real need to move too far from the GUI shown in the American model. The unit isn't as bulky either. It can include WiFi and Z-wave for the automation part. Basically a Linux computer bridging automation to security. I agree that Honeywell will probably screw it up somehow though!

I noticed menu support for the Honeywell Tuxedo Touch keypad appearing in some of the Honeywell firmwares. I've not seen/heard anything of this yet from Honeywell, but it could be a game changer if done properly. Home automation, voice control and a decent looking proper LCD touch screen. Here's hoping... http://homesecurity.honeywell.com/tuxedo_touch.html

The above is basically 'no ICMP response' from any device at that address - so the device isn't working as expected. If the device responded, it would give number of bytes and a response time. C:\k2>ping 10.226.111.2 Pinging 10.226.111.2 with 32 bytes of data: Reply from 10.226.111.2: bytes=32 time<1ms TTL=128 Reply from 10.226.111.2: bytes=32 time<1ms TTL=128 Reply from 10.226.111.2: bytes=32 time<1ms TTL=128 Reply from 10.226.111.2: bytes=32 time<1ms TTL=128 Ping statistics for 10.226.111.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

Okay, I'm forgetting that you don't get to see how many seconds in the panel log. I see this in the self monitoring which gives a more granular time stamp. But within the same minute in your log. I have the same setup here in the office, so will try to replicate your issue. Is the RIO you have fitted in the garage a new (blue PCB) or old variant ? f/w ? I've seen an issue in the protocol used by the panel/portal when a certain bus traffic condition occurs. I thought that this only caused a portal tamper and RF jam at the same time, but it's possible that the issue may manifest differently depending on the bus devices in play. If many customers are seeing this when adding a RIO to the Flex, then it's possible that it's the same root cause. I think the clue is that there's no max noise registered, but a jam is recorded.

Really needed exact times, but at less than a minute I'm assuming more than two seconds, so sounds like a different issue. Since Honeywell have updated that V3.00 firmware, you need to get the latest. The support isn't great these days, as when I asked them about issues, they said that domestic appliances like microwaves Etc. need to be switched off. Have you checked the max noise levels in the diags logs for the module and devices ?

In the log, how much time between the +JAM and the -JAM events ? I am trying to determine if this is the same type of protocol issue that I found with concurrent JAM+Tamper when the portal is fitted with the Ethernet module.

Does the portal report JAM + Tamper in the logs, or just JAM on its own ?