bpwwer

The node server log viewer is different on PG3x than on PG3. PG3 shows both real-time entries and historical entries. The PG3x log only shows real-time entries. This means that when you navigate to the node server log page in PG3x, it will only show log entries that are written after you navigate there. So if you're navigating to the log page and away and back, it will always be empty when bring up the page. The log files are in each of node server's directories at /var/polyglot/pg3/ns/<nodeserver>/logs You can also use the "Download Log" button to download the entire log file.

Where does it list "Install"? The node server details page should show "Install" for the purchase option that you have a license for. Selecting install then gives you the option to either re-install it to an existing slot or do another install to a free slot. The Purchases page should have a button to "Re-install" if it currently installed. If you're seeing "Install" here, that would be a bug.

The query to the OpenWeather server is failing. If you turn on debug level logging, it should show what URL it is using to do the query and you can paste that into a browser address bar and see what the server is returning. My guess is that it's an invalid API key. OpenWeather seems to have a couple of different types of API keys and they aren't interchangeable.

Have you registered your Polisy/eisy with the UDI portal? It must be registered for the store functions to work.

@stevehoyt I can look at public stations with the website, but I can't access them via the API. I believe that if a station is "shared" then I can access that station's data via the API. When I look at a station there's a link at the top to share and uploads When I click on that it has a search for username to share the station with. I think that if you share your station with me, it will show up in my list of stations (which is currently empty). Otherwise, I think you'd have provide me both your API secret and API token which you're not really supposed to share.

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).