bpwwer

Yes

Seconds. And you can't slow down data from the local hub. The local hub doesn't accept queries, it pushes the data to the plug-in at the interval defined in the hub firmware.

The log doesn't show anything wrong other than loudness being misspelled. I've fixed that in the code. There's no difference between starting up from a PG3x restart and restarting the plug-in manually. In both cases the plug-in is doing the same thing, in the same order. However, when PG3x is restarting, it is doing a lot to startup all the PI's and it's possible that it's dropping update data if too much gets sent at roughly the same time. I don't really know much about how UDM gets connected to IoX, at what stage in the PG3x restart does it connect, or how it gets the initial data for each node. Possibly it's querying IoX before the plug-in has fully started and then doesn't get any updates unless something changes. I was going to suggest trying to query the zone node(s) and see if that populates everything but I don't see a way to query the node from UDM.

Yes, it's seconds between calls. And yes, that could be made more obvious. The poll configuration was like that when I started using and then later developing PG3 so I never thought to improve the wording.

What you're describing doesn't sound right. If the data is updating in the PG3x Nodes page, but not updating in the Admin Console, the problem shouldn't be in the plug-in as it is only responsible for sending the data to PG3x. However, the only way to debug is using the log files. Set the WeatherFlow plug-in log level to debug and then do a restart. Wait 5 minutes or so, the download the log package from the plug-in log page. Either post that log package here or send it to me in a PM.

The data is displayed in the units that the service returns. The plug-in doesn't have the ability to do unit conversions.

Without any log information I can only guess, but my guess would be that the plug-in isn't running. It has to be running to create the typed configuration parameters that PG3 then displays with the fields for configuring the controller.

You should be able to view the device link tables and the PLM link table from the ISY. Right click on a device select "Diagnostics" and then show device link table or show isy link table. the former queries the device and the later shows the ISY's internal copy.

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.