bpwwer

First test version with RIO support in the non-production (beta) store. Version 2.0.5 This is only available as a trial since I expect it to have problems/issues as my testing is only with a simple RIO simulator. Please test and document the issues you find.

https://www.universal-devices.com/my-tickets

Ahh, I think I now understand better. I was not understanding where the delay was happening before and I think I do now. For the simple case of: if trigger then scene command it should be similar for all systems. There could be differences in the time between the actual trigger and the system detecting the trigger, but once the system (HS, HA, or IoX) detects the trigger there should not be any delay between sending the scene command. Maybe we've just looked at too many different things here and I'm now confused Going back to your initial post, it looks like that does not involve any Insteon scenes, just two devices. This is what I see there: device 32 86 20 sends a DON 1. When HA detects that it calls IoX to send a DON to device 50 D1 7F. From the pyISY timestamps, there's a delay between when the command is sent and the response is received. Question: This delay is also visible in 50 D1 7F's behavior? I.E. you see the send logged and 1.5 seconds later you see the light change state when the response is received? If this is an accurate description of the issue, then I'm not sure we can debug farther as the IoX doesn't seem to log with enough precision. We don't know when in the 1.5 second window, the IoX is sending the command to the PLM. It could be sending the command immediately and is then waiting 1.5 seconds for a response from the device. Or it could be waiting for incoming messages from the PLM to be processed before sending the command to device. I don't remember if you said you can reproduce this with an IoX program in place of the HA automation or not. If you can, document the devices and open a ticket. That should be enough for someone to reproduce this in a IoX debug environment.

re: Previous Message Ignored The Insteon protocol can route messages between devices. Device A sends a message to Device F but there might not be direct communication between A and F. So when device B sees the message it repeats it. Then device D sees the message and repeats it again and finally device F sees the message. The PLM attached to the Polisy, is just another device so it may see that same message repeated multiple times. It keeps track of the messages it sees and will ignore duplicate messages. This is also why you may be seeing delays. If device A is your PLM connected to the Polisy and it takes multiple repeats for the message to get to the final device. The Polisy doesn't respond back to the REST call until the device has responded back. So the message has to propagate from the PLM to the device and back. You'd have to ask the author of the HomeSeer Insteon plug-in to be sure. But it's very possible that what you had configured there was an Insteon scene or the plug-in doesn't wait for a response from the device before allowing the next command. With the thread getting as long as it it, I'm not sure if you provided the details or not, but it sounds like you have something like the following: switchlinc light switch in room with multiple lights (switchinc's or lamplinc, etc.) You're trying to set things up in HA so that: You use the double tap (fast off) of the switchlinc as a trigger condition such that: if switchlinc fast off then send off to lamp 1 send off to lamp 2 send off to lamp 3 When you double tap, the lights go off in a sequence vs. all just going off at once. If so, there are two ways this can be accomplished with Insteon: 1) Using external logic, when the trigger condition is seen, send direct commands to each device to turn them off (like what you're doing with HA). This is likely always going to have delays. Some Insteon controllers may have more delays than others, depends on if the controller waits for the status update from each device before allowing the next command to be sent or not. 2) Use an Insteon scene (or group). This gets programmed into either the controller device or the PLM such that when the trigger event occurs the PLM sends a single broadcast command to all the grouped devices. All the devices see the command that roughly the same time and all respond to the command at roughly the same time. It's very possible that on HomeSeer you were using option 2 and now you're using option 1. It's possible to configure option 2 in the IoX. (Or in HA if HA is controlling the PLM (or an Insteon Hub) directly).

PG3 and the node server log a lot of information and reviewing that is the first and best way to track down problems. What you're going to need to do is document which node servers are going off-line, switch the log level of one or more of those node server to debug level. The next time you notice one off-line, note the time and download the log package. You can attach that log package to a post if you want help here, or PM it to the node server author, or attach it to a ticket. Similarly for z-wave triggers failing, noting the time/date and getting the IoX log/error log and attach that to a ticket. Based on your description, what you are seeing is not normal.

If you have a reproducible test case that shows the issue, submit a ticket. My opinion is that what you are seeing is normal. Likely because the IoX is prioritizing reliability over performance on the Insteon network. The HomeSeer plugin may be doing the opposite. It's also possible that something has changed in your Insteon communications that has made device communication less reliable. The Insteon protocol has redundancy built into it so that it can work through many issues, but that can also cause reduced performance. Another possibility is that the HomeSeer plugin was optimizing things by automatically creating a "scene" for cases where you were setting up a sensor to trigger another device. The IoX/ISY won't do that, you have to create the scene and add the devices yourself. Have you tried configuring things as I suggested above? Those two tests would help determine if what you're seeing is normal Insteon communication delays or not and also help to eliminate HA as contributing to the issue (which I don't think it is).

I wrote a python script to quickly send a number of requests to the IoX and log the response times. import requests cmd = 'DON/100' for i in range(0,25): r = requests.get('http://192.168.92.11:8080/rest/nodes/17%20D%2096%201/cmd/{}'.format(cmd), auth=('admin', 'admin')) print('{}: {}: {}'.format(i, cmd, r.elapsed.total_seconds())) if cmd == 'DON/100': cmd = 'DOF' else: cmd = 'DON/100' When I send a command to a node server node, all the response times are short, ~30ms. However, when I alternate DON/DOF to an Insteon device (above was a micro dimmer I believe) the results tend to be much more varied. In one run it ranged from ~1ms to 1.5 seconds. So this seems to correspond to what you're seeing. My theory is this: With the node server command, there's no waiting for anything. IoX receives the request, sends it to the node server and sends back a response. The only delay is the time it takes to send the command to the node server via PG3. With the Insteon device, the IoX has to wait for status response from the device before it sends the response back, hence the time to get a response depends largely on the Insteon device communication. I.E. Iox receives the request, it sends the cmd to the Insteon device, it waits for the Insteon device to respond and finally sends the response back. I think what you might be seeing is a slowdown in the Insteon communication when requests are sent quickly. To test this, I added a delay in my loop of 15 seconds between sending commands and then all the responses are about 2ms. Again, this seems to correspond to what you're seeing with the automation. Insteon traffic triggers the automation which then sends an Insteon command immediately, but you see the delay, triggering manually (meaning there's no initial Insteon traffic) has no delay. I believe what you're seeing is normal. Another test you could do is to use an ISY program to trigger the light based on the motion sensor (or whatever triggering device you're using). I think you'll see the same delayed response. Another test would be to set the triggering device and the switch in a Insteon scene so it triggers directly. Here you should see much less delay as the trigger device immediately sends the command to the switch.

If you can put together a test case that shows this and allows someone else to easily reproduce it, submit a ticket as something seems wrong. With PG3, we sometimes send many requests a second to the IoX with response times in the 10-20ms range or less). If there were 1 second delays, some operations could end up taking a very long time.

PG3 only lists nodes servers that it sees when it queries the configured ISY/IoX devices for what is installed on the device(s). Unmanaged means that the query returned a node server but PG3 doesn't have a reference to that node server in it's own database. Showing them as unmanaged, is PG3's way of telling you that you can't install a node server in that slot, because the ISY/IoX already has something installed in that slot. So the only way to do anything with node servers that show up as 'unmanaged' in PG3 is to use the AC's node server menus/commands. Including deleting them. There are no other methods or tricks. The original concept for node servers was that they could be independent programs, running on other machines. Thus you could have many different computers running many different node servers, each with no knowledge of the other and each with it's own user interface. Polyglot (PG2 and PG3) were developed to make it easier to develop node servers and consolidate the control of them into a single interface. Today, there are almost no independent node servers available and we're moving forward to better integrating PG3 with IoX to make it a more seamless system, but the ability to install node servers outside of PG3 still exists.

The query at start is happening while all the node servers are starting. When PG3 starts all the node servers at once, it generates a lot of traffic and load on the IoX. So the query is likely taking more time. In your case, all the variables align so that the query and node server start for Vue intersect. A nightly query doesn't have to deal with node servers starting so you won't encounter the issue. Why a later query (or even later value updates from the node server) don't update the fields later is a very good question and I don't yet have an answer. Possibly the query marks a value when it clears it and is then waiting for the query to the node server to return a value. If the node server doesn't respond to that specific query, the value is locked waiting for something that never happens. After reporting these latest results, I haven't heard anything from the IoX developer yet.

That's something you'd have to submit a ticket for and see if someone at UDI is willing to do that for you. Node server authors don't have any control over the licensing beside specifying which types and costs.

It's not the node server, but rather that the node server didn't get fully installed. Not that the difference means much to you, since the result is that it's not working. We've had other similar reports where a node server doesn't install properly using PG3. Typically what happens is that one or two of the files needed by the node server simply don't get installed and repeated attempts to installed them continue to fail. There has been a lot of investigation but it isn't possible to reproduce this on-demand and no root cause has been found. The only current solution is to migrate to PG3x as we have never had this issue with PG3x. PG3 development is currently on hold and it's has not been determined if any further development will take place on PG3.

In general, a system reboot and a system power cycle are the same. However, the Admin Console 'Reboot" button doesn't always cause a system reboot. I believe the button tells IoX to call UDX which then initiates the system reboot. So if UDX isn't working, the reboot button won't work. In this case, you either have to log into the box and issue the command directly or power cycle. That's why power cycle always works but reboot doesn't.

No, not at this time. the Polisy/eisy is set up to use self-signed certificates for most of the communication between components. This includes communication between node servers and PG3x so those certificates need to be created every time a node server is installed. We can't easily use something like let's encrypt to generate these because you need an public IP address/DNS resolvable system name to use let's encrypt and that's something user's would have to have set up for their network before it would work. For some, setting up things to work with let's encrypt isn't difficult but for others it can be a real challenge and making it a requirement to use the Polisy/eisy would be bad for business

Yes, there is the process on the Portal to migrate node server license to different hardware. I'm not real familiar with that process In general, the PG3x backup/restore operations are designed to be used on the same hardware. It simply restores the PG3x database which does contain hardware specific configuration info. Restoring on different hardware is not something we're testing or guaranteeing will work. It may be possible to restore a backup, and use the System->Re-install all node servers menu selection in PG3x to get all node server re-installed and working, but again, this process is not tested. Re-installing and re-configuring after migrating the license should always work. So it's not that it's impossible to migrate to different hardware, just that it's not an automated process. At some point we'll get the backup/restore process to handle the hardware changes automatically and thus, simplify the process.

When the query all runs at startup, one of things it does is clear the status values and then queries the node server to re-populate them. So the theory was that something like this might be happening: node server starts and starts adding/checking nodes. - gets the node values from IoX - It then starts comparing and updating as necessary. While this is happening, the query is called for this node and IoX clears all the status values, including the ones that were just updated. At startup, a lot is going on so the queries are slow/delayed so they align with the node servers starting time wise. Now that we have an idea about why this is happening, we should be able to come up with a way to fix it.

We've been discussing this and the latest thoughts are that IoX may be clear out fields while PG3 is trying to set them and if the timing is just right what you're seeing could happen. If/When you get a chance, can you turn off the query at restart in IoX (uncheck the checkbox on the AC configuration page) and reboot. And again, after everything is started, check http://eisy.local:8080/rest/nodes/n013_187658. We're looking to see if properties are still missing and/or if there are blank fields for that node.

Yes. The reasoning is that there shouldn't be too many people that need to replace a functioning Polisy with an eisy. A number of folks did that with the eisy was first release (and had no choice but to run PG3 on a Polisy) so the Polisy/PG3 to eisy/PG3x made sense to support. But now, chances are that if you're updating the Polisy to PG3x, you're probably going be using the Polisy for a while. And yes, there are exceptions.

Because it's not a high enough priority to expend resources on developing it at this time. Eventually there will be a way to migrate. Currently the PG3x backup can only be restored to the same machine that made the backup so the same problem exists if you have a hardware failure and get new hardware. In both cases, it's possible, just not automated. The main issue is the node server license. Once that is transferred to new hardware, restoring the backup from another machine and then re-installing all the node servers should be recovered.

That's not yet generically possible. The IoX is capable of having a value -> text lookup table, but it's a pre-defined table. The node server has to supply that table at startup to the IoX. So it's what's probably happening now is that the node server has a pre-defined table that maps lock state codes to text: 0 = locked by key 1 = locked by user 1 2 = locked by user 2 10 = unlocked by key and so forth. If the node server provided a way for you to define the user's, it could build that table with your user's names instead of just 1, 2, ... Right now, there is on-going work to provide a more dynamic way to associate the numeric values to a string. But again, this will require the node server author to update the node server so that you can configure it with your own strings. This may be something the notification node server takes advantage of in the future so that you can do pretty much what you describe.

There are only 2 currently available migration paths available: PG3 on Polisy -> PG3x on eisy PG3 on Polisy -> PG3x on Polisy the first does require a transfer of licenses but that is supposed to be part of the migration instructions. the second doesn't because the hardware stays the same so the node server licenses remain valid. ** It's should still be possible to migrate from PG2 on Polisy to PG3 on Polisy, but only if your system still has old versions of the software since current system updates will remove PG2 from the system.

When you got the results with just the 2 properties showing, was the AC showing those same values in the two fields? Or were all the fields still blank?

Hi @TJF1960 If you get a chance to do test, I'd like to try the following. 1. reboot the eisy 2. after everything starts and the AC is showing blank fields for the Vue nodes try the following from a browser window http://<eisy ip>:8080/rest/nodes/n013_187658 You may be able to use "eisy.local' instead of the <eisy.ip> It should prompt you for your Iox username and password. Copy the results to post here. Then restart the node server and do the same thing. Thanks.

Using the AC, select Node Servers from the menu then select Configure, then goto the slot range and select the slot that has the node server you want to remove. You'll get a box with the node server configuration and at the bottom is a "Delete" button. Click the Delete button and a few minutes later it will disappear from the PG3x dashboard.

That's not really possible. Node servers and the associated installation are tied to the hardware. With PG3x, PG3x and the IoX are essentially tied together as one entity. If you try to move the configuration from the Polisy to the eisy, it will get very confused because it will still attempt communicate with the IoX on the Polisy, for some things and will be communicating with the IoX on the eisy for others. In addition, none of the node server will work because the license for the Polisy is invalid for the eisy. The only way to "migrate" would be to first get all the node server licenses transferred (by contacting UDI and telling them you want to transfer licenses from the Polisy UUID to the eisy UUID). Then start the eisy (and make sure it's updated), and install and configure each of the node servers. Any node server's with a free license don't need to be transferred as you can just get a new free license that works with the eisy for those.