gzahar

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.

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.

Download the FLIRC application software (depending on the OS you will use) from FLIRC (under downloads at end of page): https://flirc.tv/products/flirc-usb-receiver?variant=43513067569384 Plug FLIRC into computer (PC/Mac/Linux) and RESTORE the device using the downloaded application s/w above and the 'ISY my_flirc_config.fcfg' file from the forum. Then move FLIRC device to eISYIR node server platform (eisy/Polisy).

In the UD Mobile node, there is a selection box for content. It shows my first 16 defined custom notifications. Did you intentionally limit it to 16 (coincidentally) or it is stopping at the fist gap in ID numbering (after 16 my next ID is 21).

Not sure about the error, but make sure PG2 node server is stopped. The EVL interface can only have one (TPI) client interface logged in at a time.

Here is the code. Not sure what steps are involved in adding it to Polisy once you make changes. https://github.com/exking/udi-mqtt-pg3

I am running the IR node server on PG3. PG3x isn’t required. There are slightly different install instructions for PG3 vs PG3x.