bpwwer

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

Yes, there shouldn't be any visible changes. It's only internal to PG3 where it check for a valid license before starting the plug-in. The screen you showed initially is where you'd see which license is being used. Most of mine seem to show correctly (maybe because I've never activated the trial for those). So you might want to submit a ticket since it seems like a bug in PG3.

It worked fine, my fears were unfounded. Version 2.0.5 has been pushed to the store. This should fix the error.

Looks like the library being used by the plug-in has a bug. Likely, that bug was not something that older versions of Python flagged but newer versions do. The library was released in Oct. 2020 so It's now 4 years old and has had many, many changes since them. The TotalConnect plug-in will need to be updated to use a newer version of the library, but there's a high probability that attempting to do so, will cause more issues and require more debugging/updates to the plug-in. I believe this plug-in is currently unmaintained. However, I can make a quick attempt to update the library and see what happens.

The trial and the perpetual purchase are two different licenses. If you activated the trial and installed it. That installation will only be good for the length of the trial (1 month in this case). After purchasing the perpetual license, I believe you need to re-install for that license to take effect. You can do that by clicking the "Install" button and then selecting the "Reinstall here?" button to install it to the same slot. Using the reinstall option is, in almost every case, perfectly safe. PG3 will remember any configuration you did previously and re-use that for the re-install. In this case, everything should be the same except for the license being used, after the re-install it will use the perpetual license instead of the trial license.

It shows that you can install it because you have purchased it. If you didn't already have a license the button would show "Purchase" (or "Activate" in the case of the trial) instead of "Install". Like this: Although if you have it installed, it should show the slot it's installed in on the "Installed" column so something seems wrong there.

Not really a direct answer. My interpretation of that is that the older versions of the plug-in will stop working when they turn off version 2.5 of the one call API.

Yes, it is very confusing. And again, I doubt anyone on this forum can answer your question since we don't work for OpenWeatherMap. The plug-in has been using version 2.5 of the onecall API since sometime in 2020 (which was pre-PG3). This version of the API does not work with API keys for the 3.0 version of the onecall API, however, it seemed to be working with API keys from the professional collections. Given the messaging from OpenWeatherMap, my assumption is that version 2.5 of the onecall API will cease working in June (for all/any API keys).

@johnnyt That's not really something that can be answered here. My interpretation of the messaging sent out by OpenWeatherMap was that the older versions of the API were being discontinued and would stop working. The only way forward was to migrate to the latest version of the API. You can certainly continue to use the older version of the plug-in for as long as OpenWeatherMap allows it to work. Yes, OpenWeatherMap now wants a credit card for the OneCall 3.0 plans, even if you never plan to exceed the free limits. That's one of the reasons I was resisting switching the plug-in to use the OneCall 3.0 API. But the message I got from OpenWeatherMap indicated that using the older API would not longer be an option.