bpwwer

I agree that having the update button when there's not an update is confusing. At one point I had changed it to show install -> node server not currently installed re-install -> node server currently installed update -> an update to the node server is available It was just a conditional check in the UI to make sure the right text was displayed, in all cases, I believe the button does the same thing, i.e. takes you to the store entry details page which gives the options of re-install to same slot or install to new slot.

@stevehoyt Would you be willing to share your station's data with me? I'm attempting to use the WeatherLink V2 API, but I don't have any way to test anything. Possibly sharing a station with me will allow my WeatherLink account to access the data via the new API and I'll be able to test. My WeatherLink account username is "bpaauwe".

Previously, I could go to the Purchases page and I had the option to install or re-install a node server I had a license for. If the node server was currently installed, I could re-install it. If the node node server wasn't currently installed, I could install it. Now I can only install it if it's not currently installed. The only way to re-install a currently installed node server is to do so through the node server store page. It's much easier to find the node server to re-install on the purchases page than the node server store page. It shows without an install button so no way to do anything with it from the purchases page. The node server is already installed and no, it's not one that I developed.

I could, but that would hide the problem. The problem is that you're searching for a store record only by nsid and picking the first one that matches. So when there's both a production store entry and either a beta or local store entry with the same nsid, you only use the isyAccess flag from the production entry. You should be looking up the store entry by both nsid and store so that you get the proper store entry. I really want to test changes to the node server using my local store entry before I make any changes to the production node server, including the store entry for the production node server.

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.