GalaxyGuy

Just to confirm this: It should be a single quick flash at power up, then the LED should go off for about 20 to 30 seconds while the firmware boots. After booting, the LED will then light constant, then after scanning the bus it will pulse quickly.

Flashes straight away at power up ? If so, then sounds like a faulty board.

What does the LED on the panel board do? When initially powering it should give a quick flash. It should then light up constant after about 30 seconds, then after that it should give a quick flash every 1.5 seconds. If this was a sold as seen panel and it does not do as above, then it's faulty.

If exiting engineering mode isn't finding Keypad 0, then I agree with al. Put the keypad on a flying lead and hook in to the panel. If you powered the keypad up after the panel, then the panel will not see the keypad. The keypad needs to be present when the panel scans the bus for devices at power on or engineer 'esc' sequence.

Ah, yes. That was it.

Trying to remember who the OEM is for these modules. I think these guys re-brand it too. http://www.mini01-4g.com/

No, that's one away from the latest 6.94. No issues for generic IP reporting on 6.93.

If the RIO (Remote Input/Output) module had dissapeared from the bus, then the panel will tamper and inform that the module is missing. Only an engineer would be given to delete the RIO (using the * key). If you completely power cycled the system, then this may also have removed the non-present RIO. Since there are 12 zones on-board, the other 8 zones (upstairs) will be connected to a single RIO, giving the full 20 zones that the panel is capable of. Only someone with the engineer code will be able to re-enumerate the external RIO back onto the bus.

I tried changing the address, but the menu just shows the address allowing it to be disabled or enabled, not changed. If you disable, it still consumes the address and the hard wired Rio cannot enumerate on the bus. At least if you add in the order I mentioned, then it will work. I'm not sure why alpha isn't working for you. Did you power cycle the portal after changing the jumpers? I can add devices in alpha and V2. The serial number of the IR8 is different under each protocol. I was using a V1.08 portal, so will try a V3 when I get a minute.

Okay, since the documentation isn't clear on this, here's my test result from an FX20 panel when adding a RIO and C079 RF Portal. First, you need to set the RIO address selector to 2, then connect and configure onto the Flex bus with menu 72. The zones are 1021 to 1028. Then, add the C079 to the bus and address it using menu 72. The address dial doesn't matter much here unless you have more than one portal to attach. My test was set to address 0. The C079 will try to configure its virtual RIO to addess 102, but cannot, as it's already used. It cannot shift up one as the FX20 only allows 20 zones and the onboard cannot be disabled. So, the virtual RIO sits dormant. The bit that surprised me now is that the RF zones can now be mapped over the existing 20 zones anywhere, so you now have 20 flexible hard wired (8 outside the panel if you so wish) zones which can be converted into wireless. If you add the RF Portal first, then it will snatch the RIO address 102 (even when you disable in menu 51.60) and the hard wired RIO will not configure onto the bus. I hope that this clears up the operation - it's helped me to understand why I had to wrestle with this previously. This panel was version 3.37 for the record. GG.

I was using the range comparison chart, so the documents seem to conflict. http://www.security.honeywell.com/uk/documents/HSC-Flex-01-EN(0711)PC-C.pdf The older G2 series used to allow for mapping wireless across all zones, but my understanding was that the Dimension and Flex implementations were different. I last checked that with older firmware, but haven't tried again on the most recent.

Leave the portal at alpha and V2. Jumper 1 closed. Ensure that you power cycle the portal. What is menu 51.60 showing as the portal address ? Are you saying that when you press the * learn on the zone and set the IR8M to V2 and then add the battery, that the serial number doesn't populate ? Remember that the newer detectors have two tamper switches, so if pressing the front tamper with the lid off, then you need to have the sensor in its back wall plate to close the other tamper as they're fitted in series. No, that's not correct. The FX20 only supports one virtual RIO, so 8 wireless zones. If you add the portal on its own, the virtual RIO will be added at the next available address: 102. So that's 100 and 101 for the on-board and 102 for the wireless. Giving zones: 1001:1004 (Onboard terminals) 1011:1018 (Onboard terminals) 1021:1028 (Wireless) What I needed to check is that when you add the external RIO at address 2, then add the RF portal and disable the virtual RIO at menu 51.60, do the remote controls still work.

It's the correct board and it will not transmit until you've registered. Which detector type are you registering ? Does it register with V2 ?

No, as per my previous post, I think you will run into problems. If you add the Rio, then the portal, you may be able to use the portal functionality minus the virtual RIO zones on it. I'd need to check the validity of that on V3.37 though. Easier to just swap out the FX20 PCB for an FX50 one.

Used the newer Texe X-B dual piezo sounders at the weekend. Think I'll be using/recommending them from now on. Not sure about the test results above - the AG6 must have been tested without the cover on...

From the tests I've performed, SelfMon is more reliable.

The releases for 6.93 and 6.94 don't change any of the reporting mechanisms, only triggers. I wouldn't expect that firmware is your issue. More likely a setting in one of the menus. If you can dump your config, I will take a look to see if there's anything that looks incorrect.

I tried with 6.93 last night, but event reporting hasn't changed for a long time, so don't think that is the issue. I can flash a panel back to 6.92 if you want me to check. Did 6.94 have a release bulletin? I haven't looked at it yet.

The only suggestion I can make is that you run wireshark on a computer on your home network in order to detect communication to Honeywell's server. It's difficult to get anywhere with Honeywell support these days.

One thing to note for Apple based device push notifications is that when your device is not connected to an IP network and multiple events are sent to the device, then only the last event sent will be picked up by the phone. There doesn't seem to be any reliable way to determine if an event has been received by the phone, as iOS determines if there is enough power to signal push notification delivery to the installed app in order for the app to make a callback to any service platform. This is probably the reason that many push notifications are missed with iPhones. The iOS service is only intended to signal the app that some status has changed and the app should connect and retrieve events.

I went through the app process, but didn't set up a panel for it. They've made some basic security mistakes when setting up the web service back end, but at least it's free.

If any receiver type is missing or fails to respond to the panel transmission, then a fault will be flagged. The panel doesn't need a restart, but it does need a subsequent successful transmission with the receiver to allow the fault to be cleared.

Yes, the Honeywell sounders are too quiet. Even the single piezo Texecom unit is much louder on the wall.

Any of the +12V connections, but probably neater to select the one on the vertical block to the left of the bell connections. They are all connected to the same copper and poly fuse on the board.

Lol - Nope, the comms modules are just serial pass through devices to communicate with the control panel CPU.