gzahar

I was referring to this (in README.md). Timeout that switches key between Pressed and Held can be changed via "Idle Threshold". Will put in debug mode. Thanks.

same here

Yes, pressing the keys again reset them back to idle. I had a button stay in pressed state this morning. Here are the lines from the log: 2023-01-31 10:35:57,756 Thread-4 udi_interface.interface INFO interface:addNode: Adding node IR Button A(irbutton_104) [None] 2023-01-31 10:35:58,527 MQTT udi_interface.interface INFO interface:_message: Successfully set irbutton_104 :: ST to 0 UOM 25 2023-01-31 10:35:58,622 MQTT udi_interface.interface INFO interface:_message: Successfully set irbutton_104 :: ST to 1 UOM 25 You can see the last line left it in state '1' (pressed). This was not a new button/node, so not sure why it had 'Adding node IR Button'. Also noticed there are new installation instructions. I am still setup using the reset_flirc.sh process. I don't think that has anything to do with it, but I will update my ssh installation (ns was already at 0.1.8) Lastly, in your config instructions, I think you meant to say 'Press Threshold' in the last line (not Idle again).

I'm not sure how or when it happened, but I noticed a number of keys showing up in pressed state. This persisted through a reboot of the Node Server. You might consider initializing all keys to idle on startup, unless there is some negative impact to that.

If you have devices using the rest interface (or other node servers), then you would have to update the port setting on all those devices/servers. I have half a dozen Shelly devices that I had to change the port settings on to talk to Polisy vs ISY (but since I chose to make the IP address of my Polisy different than the ISY, it was not a step I could have avoided anyway). With 2 to 4 setting updates per device, I had close to 20 changes easily. But in the whole process of migrating, it was definitely one of the quickest/easiest things I had to do.

I do not know how to change it, but I am pretty sure they wanted it locked (probably not in a binary) to reduce support issues. PG2 uses/used the 80/443 ports (http redirects to https) and setting IoX (the ISY running on your eisy) to those ports, would conflict with that. I know they deprecated PG2, but I think it is still there and running. You could try opening the IP address of your eisy in a browser to see if Polyglot responds to the 80/443 ports.

Here is a Flirc config file that has the 40 ISY994 IR codes mapped to keyboard keys. Sorry for the scattered key map, but I had a few keys mapped based on their usage in my system. ISY my_flirc_config.fcfgISY IR Flirc key map.txt

When I first open the program tab I see the same thing (wrong/old title or entry #). But after opening the customization tab and then going back to programs tab it shows correctly (until I close the AC and reopen). As far as I can tell, when the programs run, they use the correct notification. Also, I did open a help ticket on this. Haven't noticed this regarding variables, but really haven't looked (or changed/added many variables since migration). After you opened the variable tabs, have you gone back to the program to see if they display correctly?

For some reason the node server doesn't like anything mapped to keys 0-9. Easy to work around by mapping to other keys (e.g. F1-F10). So possibly doesn't need to be fixed, just documented not to use them. Other than that, it works great for me. Thanks for developing! I've been working with the 40 default ISY IR codes. Once I get the last 5 added to flirc and tested, I'll provide the flirc config file and keyboard mappings so others won't have to go through the trouble of that step (if you're converting from using ISY IR).

S0 was leftover from Zwave migration. S2 was after I excluded and re-added one. (I will eventually remove & add back the 2 still at S0 when I have the time)

Yes. Tried on both a lock included with S0 and another with S2. Lock firmware is 0.11.0 Polisy is 5.5.4. Zmatter - Beta

That may be problematic for dimmers. Wouldn't going from 50% to 70% trigger the program?

Yes, around 16. Some being more active than others. Not saying it is slower than 994, just expected it to be noticeably faster.

One might argue that a minute is rather long for that amount of data. My backup was almost 7 minutes (with same Java parameters) on Polisy and almost 400KB in size. (Local AC with no wifi in in the picture) Maybe there is (Zip?) compression going on that takes time or just a low priority in retrieving files from Polisy so that it is not bogged down by the more important tasks it needs to do. Having said that, I don't normally need to make backups often, so it is bearable. But I agree it seems slower than I would like!

5.3.4 is latest firmware for ISY994. You can not update to 5.5.x. Those are only available for Polisy/Eisy.

I'm seeing the same thing. Most functions seem to work except motion stays on and temp is in C.

Modules are not devices. They are extended features like Z-wave, IR (I think), X10, etc.

In the device properties section, select Show advanced drive properties. A disk symbol will appear right of the device selection box.

I had an issue with Polisy where the SSD went bad and any changes made would revert after any reboot. Sounds similar.

IR receive is not built in to Polisy or eisy. IR transmit was not included in ISY994, so as @lilyoyo1mentions, whatever solution you used for transmit before should work the same with the newer boxes. This can be done with network resources or node servers and itach devices, etc. Regarding IR receive, I have looked for external solutions and have found a number of add on devices that could work. But in the end of my analysis; the cheapest (if you already have an ISY994IR) and easiest solution is to continue using the 994 for IR receive and relay IR activity to eisy (or Polisy) using the rest interface. This will most likely add additional delay to IR processing, so this may affect your use case. Ideally, someone can/will make a node server that utilizes an IR receiver plugged into the USB port on eisy (flirc, USBUIRT, etc.). This assumes node servers have access to the USB ports and that may be a big assumption.

If you have a VPN connection to your local network, you can control (restart) PG3 and individual node servers through the normal web page UI (<ipaddress>:3000). I'm sure you could also do this using port forwarding, but that is generally not recommended.

In stock now.

@bpwwer After clicking the authenticate message, Google responds with the following message: Access blocked: Holidays Google Node Server’s request is invalid You can’t sign in because Holidays Google Node Server sent an invalid request. You can try again later, or contact the developer about this issue. Learn more about this error If you are a developer of Holidays Google Node Server, see error details. Error 400: invalid_request ----------------------------------------------- More about this error: Access blocked: Third-party app is using an unsupported OAuth method Google has safe ways for users to sign in and share their Google Account data with third-party applications. To help protect your account, Google sign-in requests are blocked from apps with less secure authorization methods because they’re more vulnerable to phishing and app impersonation attacks. Learn more about how your data is shared with third-party apps App sent an invalid request If the app is blocked because it uses an unsupported authorization method, you may be directed to an “Error 400” page that says “Access blocked: App sent an invalid request.”

The parameters can be updated using the Notify Sensor node that was created when the device was added (I have a 700 series ZSE40, so it is possible that node may not be created on 500 series). Or right click a node and select Z-wave -> Set Configuration Parameter.

If you’re asking about settings for wireless backhaul/mesh, I don’t know. All my APs are hard wired. Sent from my iPad using Tapatalk