bpwwer

The log helped. I think I understand what's happening and I made another change to better detect the dropped connection and attempt to re-connect automatically. This change is in version 2.0.4

I had left a comment in the code wondering if it needed to perform a discovery after the reconnect. So maybe the answer to that is yes. I did add a log message that says it's trying to re-connect and it should log that every 30 seconds while disconnected. Do either of you know if that's happening?

Did you make changes to blue-iris-poly.py file at some point? The update process is failing because it sees that someone changed that file and it doesn't want to nuke those changes. There's a couple of things you can do - 1) revert the file back to it's original using 'git' commands. git checkout blue-iris-poly.py or rm blue-iris-poly.py; git checkout and then do the re-install via the GUI 2) delete the node server and then re-install 3) install the new version to a different slot 4) force git to update the files - git fetch origin master; git reset --hard origin/master The safest way is delete and re-install. Running git commands manually could end up causing problems for future updates unless you also make sure all the permissions/file ownership is correct.

First off, my comments and reasons for not wanting to allow for automated restarts of node servers/PG3 are really because that tends to be used as a band-aid to handle poorly behaving node servers. The right way to do things is to get the node servers to not behave badly. In this case, the node server isn't really behaving badly, it's behaving mostly as intended. When it can't communicate with Blue Iris, it goes into a disconnected state and waits for someone to take action to resolve the issue. Now it could and should handle this better. It should try to re-connect, the code is mostly there, just not the logic to attempt that. In cases like this, where the author has pretty much abandoned the node server, I'll typically take a look if I have time. Unfortunately, I don't always have time to dig into someone else code to figure out how it works and what can be done to resolve any issues. You happened to ask at a time when I'm not real busy so I'm going to try and make some changes. Version 2.0.3 should try to re-connect when it fails to query the Blue Iris server. I have no way to test this.

Yes, for plug-in's it doesn't display historical information, just real-time. The PG3x log itself does display historical information (back to midnight of the current day). Each daily log is saved for 2 weeks, I believe, but there's no way to view those daily logs via the GUI. debug would show the most information, critical shows the least. Typically you'd want to have this set to error or warnings. Those will show (as you might expect) error messages and warning messages. The plug-in developer determines what messages are shows at each level and there isn't any standard for what messages get shown at what level. So how useful each level is, depends on the developer. The log messages are supposed to be just human readable text. Some additional information is included in them by default: date/time, the log level, the module where the message was generated from. For the most part, you can ignore all of that. Here's a breakdown of a log message: DATE TIME Thread Name Module LOGLEVEL MESSAGE 2024-10-27 00:00:35.500 Thread-3 (run_forever) udi_interface DEBUG picos:btn_callback: Button on was Press

From the log, it appears to be working. Successfully set {UID} :: CLIFRS to 0 UOM 25 Successfully set {UID} :: CLIFRS to 1 UOM 25 Successfully set {UID} :: CLIFRS to 2 UOM 25 Successfully set {UID} :: CLIFRS to 3 UOM 25 That shows it setting the fan value to low, medium, high, auto There's nothing in that log that shows it setting the level to 'Not Supported' Based on what I see, the plug-in is working correctly. Have you restarted the Admin Console? If not, try that.

You can set the log level to debug and change the fan level. It looks like the debug log might show what the device sends which would help.

Your device isn't reporting any fan level so that value is correct. That's what was causing the failures after the first fix I added. The code was expecting a fan level and crashed if it didn't see one. It's possible that the code has the field name wrong and that's why it doesn't see it, but there's no documentation on what the field names are so I have no way to check that.

Actually, it's not the same error. It's now failing on 'fanLevel' not 'auto' like it was before. It looks like the code tried to handle the missing key 'fanLevel' but didn't do it right. I've corrected it and released as 2.0.5

I can see what the problem is from the log, but I'm not sure what to do to fix it since I don't know anything about the sensibo devices. It's failing to create a node because when it tries to update the node drivers initially (specifically the CLIMD (mode) node driver, it encounters an error. It's trying to set the mode to 'auto' but 'auto' isn't defined as a valid mode for it to set. The node defines 'cool', 'heat', 'fan', 'dry', and 'auto' as modes that can be sent to the sensibo to control it, but then it defines 'cool', 'heat', and 'fan' as modes that the sensibo can return as the current set mode. However, the sensibo is apparently returning the current mode as 'auto' which crashes the plug-in. I would say the fix is to simply add 'auto' to the list of valid modes the sensibo can return. But the control defines the modes as cool=0, heat=1, fan=2, dry=3, auto=4. While the sensibo mode status is defined as cool=2, heat=1, fan=6(?). So I think that things break if the sensibo ever sends a mode status of 'fan' since 6 isn't defined as a valid mode either. I don't know if the mode status values should match the mode control values or if they really are different. And if they're different, what should the mode status 'auto' be? The API documentation is of no help as it doesn't define what's returned by the calls at all. So I made a guess and changed the mode status to match the mode control values. I just pushed this change out as version 2.0.4 to the production store. See if works.

Yes. They should be running the same version of all OS components. However, the eisy does run a Linux VM specifically to control the wireless network card in the eisy. I believe that is because that specific network card is not supported by FreeBSD.

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.

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.