bpwwer

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.

Ok, I updated my development system and tested the plug-in. I did have to re-install and then re-pair with the bridge to get it working, but it's working fine now that I've done that.

The log doesn't show anything useful. If it is still repeatedly connecting/disconnecting, I'll need to see a log for the time when that is happening. Better yet would be the log package since that would include the PG3 log as well.

I'm not able to reproduce this on my system. It looks like you may have upgraded the eisy recently, were you using this plug-in before upgrading and was it working fine prior to the upgrade? The error is happening because the network connection between the plug-in and the smart bridge failed which is not something that should ever happen.

Ignore that menu on the admin console. I don't believe it works for any PG3 plug-in. All configuration should be done using the PG3 UI. The configuration instructions for the WLED plug-in aren't very clear. My guess is that you have to create a custom parameter with the key being a name and the value being a comma separated list of ip address for the WLED lights. So something like: key=WLED_LIGHTS value=192.168.1.4,192.168.1.5

What does the plug-in log file show? The only reason it would repeatedly connect/disconnect is if the plug-in is crashing.

When the ISY reports that UUID, it means that something in UDX failed and is not able to supply the ISY with the correct hardware address. You can try power cycling one or two more times and see if it corrects itself (probably give it 5 - 10 minutes after the power cycle before starting the Admin console. If that doesn't work, you'll have to submit a support ticket and get UDI involved.

Yes, at some point I'll have time to investigate the issue more and hopefully find a fix. I'm pretty busy with other things right now so I don't have a timeline yet.

The Roomba plug-in won't work with Python 3.11 (or 3.10). Starting with version 3.10, Python removed support for a feature that the plug-in relies on.

My fault. I tried updating the plug-in to use a newer version of the total-connect-client library and apparently the changes in the library are not compatible with the plug-in. I've reverted it back so re-installing should fix the issue.

ahh, I think only the original author has the ability to modify the PG2 version. I don't have access to the code, but my changes to the PG3 version probably are the same changes needed in the PG2 version.

The code change to preserve those values is pretty simple. I've made the changes in my tree and @bmercier is ok with it, I can push those to the main tree.

No. When doing an update (which is defined by installing in a slot that already has the same plug-in installed), it does a database update vs. a database add. The update does use the plug-in store entries. The exception is for custom parameters, those are not replaced/overwritten by the update. shortPoll and longPoll are not part of the custom parameters so they do get overwritten by the update. So should they be? I can make arguments for having it either way, but I'm leaning towards thinking they should not be overwritten. It would be nice if we had some "smart" control over them. Like a way for the author to control that or away to ask the user if they want them overwritten, but since we can't do anything of that, I think the user would expect them to not be overwritten. Looking over the code, what about LogLevel? That is also overwritten by the default value when re-installing. Maybe that too should be left at whatever level the user has set.

As far as I know, the only way the poll values can be set is via the UI. The only exception is when the plug-in is installed, it will default to either what's in the plug-in store entry or shortpoll=60 and longpoll=300. However, there should always be a store entry as that's not optional. These are the initial settings before the user has a chance to modify them. There is only one place in the PG3 code where it updates the database with new poll values and that is when an update to do so comes from the UI. So the only possible way this could be happening is if: 1) the default value set at install time is 60 seconds. 2) when updated in the UI, the database update fails but PG3's internal timers are updated. If the database update fails for any reason, it should be logging and error message. I'd suggest checking the PG3 log after changing the poll value(s) for errors. Another thing you can check is to try this from the command line: sudo sqlite3 /var/polyglot/pg3/pg3.db "select shortPoll from nodeserver where profileNum=2;" The profileNum is the slot number for the plugin. This command will return the value saved in the database for short poll. And case is important (i.e. shortPoll and profileNum).