bpwwer

@jwagner010 Are you running PG3 or PG3x on the Polisy? I know that none of the changes being made for eisy-ui are being tested on PG3. I'm also pretty sure that nothing is being tested with an ISY994i and it's firmware version. They aren't intentionally trying to break that setup but it could happen. My current plug-in development environment is still PG3 based so I can test on that if needed.

He has 3 different Nuheat plugin repositories. The python one is at least 2 years older than the two javascript based versions. The version I've been maintaining is based on the private version and I've made updates to it since then. Oh, looking at the python version more closely, that looks like a PG2 node server, not PG3. Yes, I can update the store entry/db or if you want to take it over, UDI can switch the developer field in the database to you.

if you go to the polyinterface github, there are instructions in the Oauth2.md file on how to add oauth2 support into a plugin. https://github.com/UniversalDevicesInc/udi_python_interface.git except that the Nuheat plugin is written in javascript and I don't think the javascript interface got any of the updates for oauth2. It does have some basic support, but it's not documented. I think @simplextech was really the only developer that created plugins using javascript so that interface isn't nearly as well supported as the python interface. If the plugin needs a re-write anyway, maybe it makes sense to switch to python. Do you have a Nuheat thermostat? Or were you able to get credentials without one?

Umm, I seem to have lost the memory of sending you an email. I'm a bit confused.

@Panda88 If you figure anything out, let me know. The plugin interface does have the ability to do oauth authentication which is what the new API needs, I believe.

I personally would do a package upgrade from the admin console first. That way the Polisy is running the very latest supported versions of everything for the Polisy. Then do the manual ssh package upgrade to get the new eisy-ui and it's dependencies. And, yeah, back up first. I sometimes forget to do that and it's not always ended well.

@bmercier Is this the right place to report issues with the integrated plugins feature?

PG3 (and PG2) are standalone web apps. Prior to this new beta release if eisy-ui, eisy-ui simply integrated the PG3 main menu into it's menu structure and made calls to the PG3 web app to manage the plugin (formally node servers). PG3 did plugin management (install/remove, start, stop, configure) by making calls to IoX. eisy-ui also makes calls to IoX for integrated nodes (insteon, z-wave, zmatter, etc.), programs, variables and such. So this beta is basically just combining them so it's one common layer that communicates with IoX instead of two. The PG3 look and feel will change to match eisy-ui but the functionality will be mostly the same. Way back when we were developing PG3 we talked about the eventual goal being a combined PG3/Admin console web app. It's great to see that finally happening.

My home is and has been running on a Polisy with version 5.91 pretty much since 5.9 came out. None of upgrades since have added anything that would make any difference to how I use it. I use the admin console or the PG3x interface no more that 3 or 4 times a year. For the most part it just runs and does what it's supposed to. For something that's controlling things in my home, I tend to try and not break things. Upgrades sometimes (not often) break things. Moving to 6.1.1 and eisy-ui is a big change, I'm still trying to decide if it's worth the risk.

I'm not sure I understand what this means, at least to me. I've never used "developer mode", my primary development environment was running a local version of pg3 under my account so I had access to everything. In that environment I have 24 plugins listed in my local store. I have two development/test environments, one on a Polisy and one on an eisy. I also have plugins in local stores associated with the production installations of PG3x. When I have to debug plugins running on a production installation of PG3x, I just use sudo to access the files and logs. Never had a need for "developer mode". It sounds like none of this will be usable with eisy-ui and that I'll have to potentially re-create 50+ local store entries if I want to continue developing, debugging and maintaining my plugins.

So maybe the API keys are compatible? That certainly wasn't the case in the past when they updated the API. The plugin (current version) is not making calls to the 4.0 API, it's simply able to use the API key you generated with the 3.0 API calls. I had assumed that wouldn't work (base on the previous update) so I didn't test that. I do have it partially working with a newly generated key and the 4.0 API. Thanks for the update!

Disconnected typically means it crashed on startup or did not start at all. Possibly it wasn't fully installed. The PG3x log may have some information about what is happening when it attempts to start the plugin. 1.0.13 is a fairly small change that UDI had me make, in my testing the change didn't change anything. I was able to install and run it on 6.1.1 but the IoX refuses to let it connect and get the "inventory" information. UDI is trying to determine why.

I'm looking at making the API version a configuration option. Two versions would be another option, but it has some disadvantages as it could result in someone having to buy both. There's also a good chance that they'll change things again given that they've now changed API's about every 2 years since I wrote the plugin. I used my existing account (that has a 3.0 subscription) to subscribe to the 4.0 API. Even though both subscriptions are active, apparently I can now only generate API keys for 4.0. And the really nice thing about their API keys is that you have no way of knowing what key is for what version unless you put something in the name of the key. Sorry, I'm only a little frustrated with OpenWeatherMaps.

I believe that the One Call subscriptions are only valid for the specific API. The plug-in is using the One Call 3.0 API and does work with a One Call 3.0 subscription. I just verified that. I would not expect a 4.0 API key to work with the 3.0 API given all the issues I've seen and the 401 response you are seeing matches that. OpenWeatherMap has been a bit of pain for the past couple of years. I switched the plugin over to use the 3.0 API when they said the previous (2.5) API was going away. But it looks like you can still use the 2.5 API. Now they have the 4.0 API which is incompatible with the 3.0 API which means I have no good options yet again. If I leave the plugin alone and working with only the 3.0 API, anyone that gets a 4.0 subscriptions can't use it as it doesn't look like you can get a subscription to the 3.0 API anymore If I switch the plugin to use the 4.0 API, all existing users setup will fail until they get a new subscription and key for the 4.0 API. I'll have to give this some thought.

@simplextech isn't around anymore and isn't maintaining his plugins. He passed them all over to me and I do my best to maintain them. I don't have any way to reproduce this issue as I don't have the hardware or an account. But if you can switch the logging level to debug, restart the plugin, download the log and send it to me (a PM is fine), I'll take a look at it.