bpwwer

No, don't try to create the nodes manually. The plugin won't know they exist so it will never try to update them. One of the main reasons nodes don't get created is because there's something wrong in the info being used to create the node. There are restrictions on what can be used for address and names and the plugin may fail to catch everything before trying to create the node. In the plugin log there should be lines like: "Adding Roomba 980: name (address)" so if you see those, then the plugin is attempting to create the node. At the same time (using the log timestamps), the PG3 log should be making http requests to IoX to add the nodes. If you send me the full log package which includes both the plugin log and the PG3 log, I can take a look. Keep in mind that both logs will reset at midnight so you need to start (restart) the plugin and then download the log package if you haven't done so today. You can PM the package or email it to bpaauwe at yahoo.com

I've noticed it too, but just in the past couple of days. Seemed like it stayed logged in longer a week or two back.

Probably something with the data feed, either missing or the format changed. It's not like the plug-in would suddenly decide to stop reporting the UV index. I don't know if I can still get a feed from them so if it continues to show zero, get a debug log when you can and I'll take a look.

@stillwater I understand what your doing as I also created a couple of node server like that back then. I don't think the API is going to to change in a way that will break your node server, but it may get harder for you to manage it. The API calls your node server is using are the same ones that PG2 and PG3 use, but they handle all the management so that everything on the admin console's plugins menu is not needed. In fact, it tended to confuse people as they would sometimes try to use that to configure PG3 plugins and overwrite the configuration that PG3 had done. That's likely why you don't see that menu/capability in eisy-ui. @bmercier will have to comment on the long-term viability/support for your type of node server. If you do want help converting it to a PG3 plugin, I can do that. In that case, you would have to put it in the local store.

I just pushed version 2.0.18 of the plug-in to the store. So give that one a try.

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