bpwwer

The isyAccess flag is still not working for me. The 'Backup' node server will require this, but when I set the checkbox in to indicate that the node server will need the user to grant permission, the request for user permission never shows up in the configuration tab of the node server once it's installed. Another issue is that I can no longer re-install node servers by going to the Purchases page. Instead, I have to search through the full node server store listing to find the node server I want to re-install. Why was this feature removed? The new developerMode lets me set it for any node server I have a license for, not just the node server's I created.

I had some time so I did some work to make a version with the fix applied. Version 1.0.10 is in the store now and has the proposed fix for the recalculateGroupVolume() crash. I have no way to test this, but the node server does install and run for me.

Sorry, apparently with Python you can indent comments wrong. Try 2.0.10

I just pushed version 2.0.9. I added polling support. So now at the poll interval it will attempt to query the zone power status for all zones. The default interval is 60 seconds (short poll) but you can change that to whatever you think is best. I also updated the query support so that now if you query a zone, it should actually query the controller for the zone info and update that. I removed the source status from the main controller node. Now that chained controllers are supported, the number of sources is variable (and even with the RIO controllers, it varies) so having a fixed number of source states there doesn't make sense. I could attempt to make that dynamic, but that's not easy with the way IoX nodes are defined and I'm not sure it's all that valuable. I could also create a node for each source, which might make more sense as with RIO there's more source info available. Let me know if you have any thoughts.

Ok, I'll add something to do that. Just the C3 and C5? How many different models do you have to test with?

Sorry, that was my fault. I last tested with RNET and missed updating one of the functions for RIO. Should be good with version 2.0.8 which I just submitted.

I just submitted version 2.0.7. This has support for chained controllers. It should detect you're second controller and add the sources and zones for it. To make this work, the zone addresses changed, so you might want to delete version 2.0.6 and install 2.0.7 instead of re-installing. It was a pretty massive change to support multiple controllers this way so hopefully I didn't break it too bad. I think I fixed the source selection bug too.

So the MCA-C5 is a 8 zone, 8 source controller. The RIO docs don't mention it so I wasn't sure. Version 2.0.6 will assume it's 6 zone, 6 source controller so expect that. I'll fix it so it's 8 zone, 8 source in the next release. The main goal with this release is to make sure it does create the 6 zone nodes and does show the sources you have configured (at least up to 6). Zone commands should work now too as it should no longer get stuck trying to access the source names. If you use the 'Refresh Store' button, it should show the new version. Otherwise you could have to wait up to 8 hours for it to show up automatically.

Version 2.0.1 does the unit conversion to metric for the day, month, and year nodes.

Thanks @garybixler! I'll have to look into the issue with the second controller. This node server was designed to support multiple-controllers but it doesn't recognize that they are linked so you have to add each one individually in the config. At least that's how it works for RNET based controllers. I'm looking through the log now and it looks like you clicked the "Add Controller" button for a second controller, but didn't configure a second controller. The log shows Processing controller {'port': 5000, 'nwprotocol': 'TCP', 'protocol': 'RNET'} Which fails. I don't think this is causing any other issues, but you probably should fix the configuration. The next thing I see is that your controller is reporting it's type as MCA-C5. I don't see that listed in the Russound RIO documentation, it only mentions MCA-66, MCA-88, and MCA-C6. The node server assumes that since it's not a MCA-88 that it's a 6 zone, 6 source controller. Is that correct? The problem was that the node server is waiting for the response to the get source name command but I had formatted the command wrong so it never got the source name, just an error response. It was sitting there waiting for the first source name. This should be fixed in 2.0.6 which is in the beta store now.

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.