gzahar

The Harmony Elite is typically RF between the remote and hub; and then IR between hub and devices (using the IR emitters attached to the hub). It can also be IP between the hub and devices depending how you set it up. Not sure if you can get IR directly out of the hand held remote or not, but that shouldn't matter. Assuming you have it setup the same as you did with the ISY, you should have some sort of IR emitter/blaster pointed at the FLIRC (instead of the ISY). If possible, I would plug in the FLIRC to a PC and try to learn the codes from your Harmony remote into FLIRC using the FLIRC s/w vs the file I created; just to make sure your Harmony setup is sending IR codes as you expect. Alternately, you could try to learn a few codes from any generic TV remote (with the FLIRC plugged into the PC) and then try to add those buttons to the eisy/admin console just as a debugging process.

https://wiki.universal-devices.com/index.php?title=ISY-994i_Series:EMail_and_Networking_Substitution_Variables

See the Dual momentary configuration. Purple is sense #2. https://cache.insteon.com/documentation/2443-x22-en.pdf

Yes, I found it will stop loading messages at the first non-used number. It will not skip over unused numbers. I just created messages titled spare for any missing numbers.

I see Zigbee in your menu, so I would open a ticket with UDI support.

You either don't have a Zmatter dongle or old firmware.

Most Philips devices should use standard RC5 codes. I would start there.

This is what my Advanced Z-wave menu looks like. Nothing about Z-Wave information / S2 support. I also have Polisy 5.7.1 and USB Z-matter dongle. Send a picture of what you are seeing.

EDIT: Just re-saved the heartbeat program and it now appears to be seeing them. Must have been some disconnect in the re-install or migration to PG3x. I don't seem to be getting them. I have IoX 5.7.0, PG3x 3.2.10 and Notification 3.6.11. Also recently deleted and re-installed. This is what shows up in the log 2023-10-24 09:32:09,575 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-10-24 09:31:09,574 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-10-24 09:32:09,575 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-10-24 09:32:09,576 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-10-24 09:33:09,603 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-10-24 09:32:09,576 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-10-24 09:33:09,603 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-10-24 09:33:09,605 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-10-24 09:33:09,605 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-10-24 09:34:09,605 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-10-24 09:34:09,605 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-10-24 09:34:09,607 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-10-24 09:34:09,607 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-10-24 09:35:09,605 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-10-24 09:35:09,605 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-10-24 09:35:09,607 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll

Are heartbeats sent out by this node server?

Same here.

You may need to reboot the eisy after plugging the Flirc into the device. If you have done that then you need to send each IR signal to get the node server to add the nodes. Once they show up you can use a program to run when the IR node is pressed or held.

Using the Harmony NS, you can only trigger on an activity status (not a key press/hold). You should be able to do this with the Flirc and the eISYIR NS. You can also use your old ISY994 IR and network resources (assuming you have a license for that) to change a variable status (or possibly execute a program directly, not sure) on the eISY via the REST interface. This is what I did until the eISYIR NS was available.

For the future, if you go to the programs tab and right click the main folder then select copy folder to clip board, you can then paste a text version of all your programs into a document. This file will have a note by each program that indicates if it is disabled. Also, I generally name all disabled programs with parentheses around the name for quick detection. This messes with the normal sort order (putting them first), so may not be for you if you want them sorted ‘properly’.

I don't believe that is how it works. The jnlp file is akin to an executable file and it not modified when run. It does store information that should be deleted by the clearing cache/deleting files exercise; but the start.jnlp file itself appears to be the same as it was when last downloaded. Edit: If you're saying UDI made a recent change to the start.jnlp file then I follow you.

Why?

Go to the Java Control Panel (located in the Windows Control Panel) and compare the Security and Advanced tab settings between your laptop and desktop.

What colors do you offer? (for the buttons, not text)

The Plus 1 will operate with 12V also. There is a node server, but it doesn't work with the Plus series (at least not that I have been able to figure out). Power supply: 110 - 240 VAC / 24 - 48 VDC / 12 VDC ±10%

I am experiencing the same issue with one way operation (Schlage). I had 3 locks included with S0 from my ISY. After migrating to Polisy / Zmatter they still operated correctly. I tried to re-include several of them using S2 and that's when the reporting status issues started. If I recall, trying to go back and include on Zmatter with S0 caused no relevant nodes to be added (it's been a few updates ago, so may no longer be the case). As a work around for now, I query the lock(s) shortly after detecting the door being closed (using alarm system status). This keeps my lock status in sync over 95% of the time (obviously depends on your typical usage).

The two I have, have not reported a battery level. I initially thought it wouldn't report the level until it detected a change; but it's been a while since they were put in service and probably should have updated by now. So it doesn't look like that is working for me.

I have two ZSE40s included and they appear to be working and reporting status / values ok. It's been a while, but think the only way I could get them to include fully (node wise) was using S2 (it may have been some Schlage locks that I am remembering, not sure). I have never gotten any Zwave battery devices (including the ZSE40s) to complete an interview. I played with it for quite some time to try and get the interview to complete, but no luck. During that time, they would get in weird states where nodes were missing or wouldn't include/exclude. I either had to remove the battery or do a factory reset on them to get them working again.

Are you using an RF base station with your URC remote? If so, you might try adjusting the IR output level of the emitters.

I believe you only need to load the configuration file, no additional write to device command is needed/available. Not sure about installation requirements on eisy, I'm still on Polisy. I know IR can be fickle sometimes. I have also had to learn commands from a specific remotes in the past to get them to work. (although not the case here). You could try that with one IR code to see if that is the issue. You might also try rebooting the eisy and/or restarting the node server and admin console.

Correct. Only one press needed (if it is sensed correctly). Also assuming you have installed the node server.