bpwwer

Having all the background helps with understanding what you're trying to do. Typically, when someone has an ISY, that ISY is the what will be managing all the Insteon devices, that is what it was designed to do. So manually trying to maintain link tables when you have an ISY seems counter-intuitive without all the background. I too, messed around with writing my own software to manage Insteon links when it first came out and stopped once I had an ISY to manage them. My software is still available here: www.bobsplace.com/ilinks/ but good luck getting anything working on a modern system. Sounds like you now have enough information to move forward. Keep us updated on your progress, I'd like to know how it all works out.

If you're going to do that, why not just have your program use a REST command to set the device (switch and/or scene) directly. No need to involve the 2412n at all.

when you add a new device in the ISY you can either clear the device's link table or import the links from the device. I think the Insteon protocol is capable of doing what you want, the problem isn't the protocol, it's the ISY. The ISY's software tends to assume that it is the owner of all device link tables so if something else starts modifying those link tables, then you could run into trouble. Ideally, you'd add the 2412n to the ISY and then let it manage that link table as well, but (you'll have to verify) I don't think you can add it. At least last time I checked, you weren't able to add PLM's as devices to the ISY.

Insteon linking can be tricky to understand. From your descriptions, I believe things are working the way they are supposed to, just not the way you'd like. There are two ways to "link" what Insteon calls responders (devices that respond to commands) and controllers (devices that sends commands). The first type of link is a direct link. That's where a controller is directly linked to a responder. This is the type of link you've made between both the ISY's PLM and the 2412n. With a direct link, the controller sends a command to the responder and the responder acknowledges back to just that controller. So if the ISY sends a command to the switch, the switch executes the command and responds back to the ISY. If the 2412n sends a command to the switch, the switch executes the command and responds back to the 2412n. Neither controller is aware of what the other controller sent. The second type of link is a group (or scene) link. With this type of link, the responder has a link table entry that tells it to listen and respond to commands sent to a specific group/scene ID. Multiple responders can listen for the same group broadcast. There can be multiple controllers and multiple responders configured for a single group/scene ID. The ISY will do some magic behind the scenes when creating scenes to make sure everything it knows about is properly linked as it can get pretty complicated. So if you want the two switches and the ISY to all work together as a group, you'd create a scene with the ISY and add both switches as both responders and controllers. Then the ISY would update the link tables so that everything works as you'd expect. Sending a scene command from one switch will go to both the other switch and to the ISY. Scene commands from the ISY will got to both switches. In all cases, the ISY should be able to track the status of both switches. Now the ISY expects to be the only thing that controls those switches. As you've noticed, adding links to the switches that the ISY doesn't know about, means the ISY doesn't see everything that's happening on the Insteon network and then isn't able to track all the device status. There's no easy/good way to deal with this. You can manually add entries to the various link tables and probably get things working the way you want, but the ISY may get confused and may overwrite those entries since they won't match what it thinks the tables should look like. You're probably better off changing you're application to interact with the ISY via it's API to control devices instead of trying to use a separate PLM.

PG3 doesn't allow short poll to be longer than long poll.

If you end up needing to replace this setup, I did find what might be a viable option. What's needed is a way to communicate (I'm guessing wirelessly) between the eisy and a relay board. With a quick search, I found this article, https://randomnerdtutorials.com/esp8266-relay-module-ac-web-server/ on using a relay board with a ESP8266. This provides a set of relays you can control over Wi-FI. It's not a plug-in-play solution as it looks like there's some programming of the ESP8266 required and you'd need a plug-in written for the eisy to control it. We already have eisy plug-in's to control various USB based relay boards so creating one to control a wi-fi relay board should be pretty simple. Another, option might be the controller/IO devices that work with the BASPI6U6R plug-in available in the eisy plug-in store. I don't know anything about these but suspect that they'd be a lot more expensive than the simple wi-fi relay board.

I've thought about getting some, just haven't been able to justify it since we have an existing whole house audio solution. Each speaker node in the plug-in is running as a somewhat independent entity. So when something changes on the Sonos network (I.E. a speaker is turned off/on, or a join/unjoin happens) a device will send out a message to all the other devices to notify them that a change happened. The plug-in device nodes also see this notification and respond by re-querying to get the most updated information. So when the buttkicker device node in the plug-in sees that notification, it rebuilds it's internal "zone" list. It's that internal "zone" list that is used to provide the options to the IoX programming interface. When you create the program and specify that for the device node buttkicker to join, the plug-in sends it's zone list which is then used to create the drop down list of devices/zones that buttkicker can join. You then select 'basement' from that list and IoX stores the index number for basement. Later the buttkicker plug-in node gets another notification that something has changed so it rebuilds it's internal "zone" list again, but this time basement is at a different index. The IoX program didn't save "basement" just the index and now that index references a different device/zone in the new zone list. When the program executes, it sends what was saved to the plug-in device node. So in this case, it sends a command (JOIN) to the buttkicker node with the index of what it wants to join with. The node code looks up that index in it's zone list to map that index back to the proper (or improper) device and sends the command to the various sonos devices. If that internal zone list never changed, this would all work how you want/expect. Or if IoX was able to save the device name instead of just the index, it would work as expected. I think it may be possible to create an internal zone list that maps to fixed indexes and then try to maintain that, but I'm concerned that it would get fragmented and that might cause issues over time. It would also be a pretty big overhaul to the plug-in code base. I'm reasonably comfortable debugging issues with the existing code base, but re-writing it for something like this is a lot more effort and time (and probably does require having some devices to test with).

If I had some sonos devices, I'd experiment with this and would be able to provide better answers, but I'm mostly just making some assumptions based on what I see in the code. In the code, it looks like it creates a zone list of what I assume are groups of speakers/devices. The order of speakers/devices and membership can change in these zones. A speaker node holds a copy of this zone list and that's what's used when you create the program. If I'm guessing right, your program is requesting that the speaker named Buttkicker is added (then) or removed (else) from the group/zone called Basement. When you created this this program, the zone Basement might have been at index 2 in the zone list and that "2" is what IoX saves in the program. If over time that zone list changes and Basement ends up at index 3, then the next time the program is viewed or executed, it will show/use whatever zone is now at index 2 instead of the Basement zone. I'm not sure the original author of the plug-in would have even realized that this could happen.

That's not a debug log, just a normal log. You need to set the log level to debug. The plug-in will make the query once when it's started and then at every short poll interval.

I don't have any Sonos devices nor do I fully understand how the plug-in works. I just took over support from the original author. But I believe that the issue isn't with the nodes, but internally with the way Sonos enumerates the zones (or speakers) for use in the join command. If I'm understanding the code correctly, it does something like a network query to discover the zones (speakers) and each device then responds back. So the order is not fixed and just based on the order that the devices respond. My understanding of the Sonos devices is that there isn't any central controller that keeps track of everything and instead, the devices just communicate between themselves. The IoX programming requires that the list be a fixed list. So a list is created using the order the devices responded above and that list is then used when editing the program. The next time you go to edit (or even display) the program, the order of devices in that list may have changed. So initially the basement devices may have been the third device on the list, now it's the second and some other device is third so that's what shows up in the program. I don't think there's any way to work around this, but I can't experiment since I don't have any Sonos devices. I believe the join is something that happens at the sonos device level, and not something that's happening in the plug-in so it's not really related to the nodes created by the plug-in.

You can get the URL that the plug-in is using to query OpenWeatherMap from the log when it's at debug level. You can then cut-n-paste that into a browser address bar and see the raw data that OpenWeatherMap is returning. When I did this with mine, I saw a change of rain (20%) for today and 0% for the remaining daily forecasts which matched what the plug-in reported to IoX.

You're saying the "ST-Sonos / Buttkicker" changes to "ST-Sonos / random speaker" ? IoX programs are using a fixed index that get's mapped to the name for display. The Sonos zone list is re-generated every time a Sonos device sends out a "topology-change" message. My best guess is that something is causing a topology-change which changes the zone list so the index into that zone list is no longer pointing to the same speaker that it was when you created the program. The issue is a combination of how IoX programs work and how Sonos works. I don't think there's any way to fix this without IoX rewriting how programs work or breaking the dynamic behavior of Sonos.

My system was down so I wasn't able to test, but now that I have it working again. Version 4.0.0 works correctly for me, the change I made in 4.0.1 was wrong and not needed. I've pushed 4.0.2 which is exactly like 4.0.0 If you're seeing POP values of zero, that's what OpenWeatherMap is sending.

Try updating to version 4.0.1. I just pushed this update to the store. It looks like OWM 3.0 API reports POP differently than the previous version of the API.

Most likely, it's an error in the results sent by Ambient. You can check that by taking the URL where you redacted the key and cut and pasting that into a browser tab/window. If you just generated the key, it may take some time before Ambient actually activates the key and it works.

You need to generate a new key, key's for previous plans/subscriptions won't work with the OneCall 3.0 subscription plan.

From the log, the queries the plug-in is making to ambient.net appear to have an invalid API key. That's the message the Ambient servers are returning when that query is made. The plug-in can't force Ambient to accept an invalid api key. Double check that your key is correct and valid.

The device data for your Roku doesn't have the field 'user-device-location' in it, which it should. I pushed a new version, 2.0.6, that adds a debug message which displays the device data so we can look at what your device is returning.

Ahh, I think I understand what's going on now. PG3 only supports one connection status per plug-in. So it can't really handle the case where there are multiple nodes configured for connection status. The Vue plug-in is set up to handle the common case where there is really just one vue controller node. While it allows you to have more, PG3 won't allow each one to have a separate (or even the same) status. It can only use the status driver for one of those nodes, probably which ever one is last configured. What's probably happening is: node 293227 sends a message to PG3 saying use my ST driver for connection status then node 35060 sends a message to PG3 saying use my ST driver for connection status, overwriting the previously assigned node ST driver.

PG3 is multi-threaded so the log entries aren't always linear. The errors you highlighted seem to all be for the plug-in in slot 12. Here's the log entries where PG3 sets the status for the plug-in in slot 3: 2024-07-03 15:15:01.246 [pg3] info: IoX Request: [Try: 1] [00:21:b9:02:60:44] :: - http://127.0.0.1:8080/rest/ns/3/nodes/n003_293227/report/status/ST/1/25 2024-07-03 15:15:01.248 [pg3] info: IoX Response: [Try: 1] [00:21:b9:02:60:44] :: [200] :: 1.71284ms - http://127.0.0.1:8080/rest/ns/3/nodes/n003_293227/report/status/ST/1/25 The first line is PG3 sending the request to IoX to set the status to 1 (on-line) and the second line is IoX reporting success. So if the admin console isn't displaying it as on-line, that's either and admin console problem or an IoX problem.

The plug-in doesn't have any control over the online connection value. It's PG3 that sets that based on the MQTT connection status between the plug-in and PG3. The PG3 log may provide more information (like if it's sending the status and/or if IoX is accepting or rejecting it.

It's not getting the data it expects from the devices. If you enable debug log level, it will show more info on what it is getting from the devices.

So this is what's at the bottom of the logs. The plug-in reports successfully sending the dewpoint value of 52.2 for node three. 2024-06-28 18:32:06.477 MQTT udi_interface.interface INFO interface:_message: Successfully set e8db84e738_5 :: DEWPT to 52.2 UOM 17 2024-06-28 18:32:06.397 [pg3] info: Received commands on topic udi/pg3/ns/status/00:21:b9:02:66:d1_11: set 2024-06-28 18:32:06.432 [pg3] info: IoX Request: [Try: 1] [00:21:b9:02:66:d1] :: - http://127.0.0.1:8080/rest/ns/11/nodes/n011_e8db84e738_5/report/status/DEWPT/52.2/17 2024-06-28 18:32:06.432 [pg3] info: IoX Response: [Try: 1] [00:21:b9:02:66:d1] :: [200] :: 0.867211ms - http://127.0.0.1:8080/rest/ns/11/nodes/n011_e8db84e738_5/report/status/DEWPT/52.2/17 In the PG3 log we see that it received the command from the plugin (set command to set the value). That log message isn't all that good as it don't provide much. But following that we see PG3 making the request to IoX to update the value. Then, we immediately see IoX respond with a status of 200, which means it was successful. From these log messages, it does appear that the plug-in is sending updates (so nothing wrong with the plug-in) and PG3 is sending those to IoX (so nothing wrong with PG3). I'm not sure what else to do at this point. You could check the IoX logs, but since it is reporting success back to PG3 I don't think you'll see any errors there.

@tlightne You'll need to describe your setup a bit better for me to understand what I'm looking at in the log. However, I don't really see anything that looks obviously wrong. I see 6 nodes being created: Brad East with address e8db84e738 main with address e8db84e738_1 indoor with address e8db84e738_2 one with address e8db84e738_3 two with address e8db84e738_4 three with address e8db84e738_5 All of those appear to be getting data from Ambient.net and publishing the values to PG3. Is the node on the eisy that's not getting updated one of those? If it's not, then it's probably an orphaned node that the plug-in doesn't know anything about. The plug-in creates the nodes and determines what data it can get from Ambient.net by parsing the data returned when it makes a query for all data. Anything it sees in that data that it doesn't understand is ignored. To do any more debugging I'd need you to do a couple of things. First set the plug-in's log level to debug, then restart the plug-in. Let it run long enough to do a couple of queries to Ambient.net. Then download the log package (not just the plug-in log). The package will include the PG3. That way I can see if PG3/IoX is rejecting updates from the plug-in. After downloading the log, you can set the plug-in's log level back to INFO.

That looks like the same error. It starts with a network error with the encryption protocol, which results in the plug-in being disconnected from the bridge. encryption errors like that are happening at a level in the software stack that the plug-in doesn't have direct access to so it's not a problem with the plug-in. What I may be able to do in the plug-in, is detect the disconnect and attempt to recover and reconnect instead of just stopping. I'll look into that. While I'm at it, I'll add support for the SerenaTiltOnlyWoodBlind that shows up as unsupported in your log.