bpwwer

The error message is coming from the WeatherBit server. It's telling you that their server is not accepting the key as configured in the plug-in. You'll have to contact WeatherBit to get more information on why your key is not valid, or create a new key and try that. If this is a new key, then please give it some time to be activated on the WeatherBit side.

What does unmanaged mean? PG3x loads plug-ins into an IoX slot, IoX has 100 slots available to load plug-ins so you have have upto 100 plug-ins installed. When PG3x starts, it queries the IoX to see what plug-ins are installed in which slot. If PG3x sees a plug-in installed in a slot but doesn't have a corresponding database entry for that plug-in in that slot, it makes the assumption that a different version of PG3 installed the plug-in and is managing it. Thus this PG3x is unable to manage that plug-in. This likely happened during a migration. Those plug-ins were migrated to the eisy IoX, but they are still being managed by the PG3 that was running on the Polisy. There are 2 ways to delete those: 1) as @Guy Lavoie says, go into the eisy admin console and delete them from the IoX. This is probably the easiest way to handle it. 2) you could run PG3 on the Polisy, if it's re-configured to use the IoX on the eisy, it can then delete them. In theory, this should work, but I'm not sure if the latest IoX supports installing/managing plug-ins from the Polisy.

On the Icon select screen, it would be nice to have a "tab" of typical HA related icons instead of having to search through the entire 2000+ icons. These look like the material design Icon set, but the web page to search through those returns more results. For example, if I search for "plug" on the eisyui, it found nothing, but the google/fonts search found 23 icons, including a couple of outlets, including one called "Smart Outlet" which I can't seem to find with the easyui icon search. When editing a tile: What do the two icons in the middle mean? The up/down arrow didn't seem to do anything and right arrow square seems to want to move the tile to a different page. It would be helpful if these could have tool tips to explain what they are when you hover the mouse over them.

I don't think I did anything that would have affected it. I downloaded it and ran the install with sudu. I looked at the log and when I saw the message I ran sqlite3 /var/eisyui/db/eisy.db. So yes, the file was there, but the sqlite commands .schema and .tables both returned nothing.

The database file was there, but it was empty; no schema and no tables. Running the deploy script looks to have created it properly and it seems to be working now. Thanks!

Installed, but not working: tail ui-current.log 2025-06-05 13:25:10 [info] startup: Modules loaded 2025-06-05 13:25:10 [info] startup: Running environment: production 2025-06-05 13:25:10 [info] startup: eisy-ui version: 0.4.0 2025-06-05 13:25:10 [info] startup: Using portal base url: https://my.isy.io:443 2025-06-05 13:25:10 [info] db: Prisma: Starting a sqlite pool with 9 connections. 2025-06-05 13:25:10 [debug] db: Prisma: Invalid `prisma.config.findUnique()` invocation: The table `main.Config` does not exist in the current database. Can't get to any website on the eisy, not at port 8080, 8443, 80, 443. Only thing I can get to is the standard PG3x at port 3000, that still works.

PG3 doesn't use a server.json file, that was for PG3 node servers. The information that was present in the server.json is now stored in the node server store record for the node server. Again, please read the documentation on creating plugins (node servers) https://developer.isy.io/docs/getstarted/ Most of the documentation is also available from the PG3 developers menu/

Ok, version 3.0.31 has been published to the store with the fix. It should work correctly now.

@ldb I'm not sure what you mean by "do not reset daily". There are only two fields that should reset daily; the daily rainfall and yesterday's rainfall. I do see a bug that looks like it would always set yesterday's rainfall to zero. Is that what you mean? I don't use nearcast data so I don't pay attention to what's there.

It does do something, there's just nothing visible that happens when you press it. It sends the plug-in's profile files to the IoX. It's the same thing that happens if you call the udi_interface function updateProfile() from within your plug-in.

https://developer.isy.io/docs/getstarted/

You're waiting for me. I bought a couple of the RGB Led bulbs and I think I have those working correctly. I need to apply some of the changes for the dimmers (and switch, I think). Other projects have interfered so I haven't had time to finish up and release it.

That makes sense. I had forgotten that it used the controller ID as part of the zone node addresses. Using multiple copies of the plug-in in different slots should have worked. Since all the nodes are prefixed with the slot number, there's no way they can be duplicated. Also plug-ins are restricted to only working with nodes prefixed with their slot numbers, they can't do anything to node created by plug-ins in any other slot. The other option you have is to change the controller ID's so they are unique. Then one copy of the plug-in should be able to manage all three.

Possibly. The plug-in is designed to support multiple controllers, just not when they all have the same IP address. If they are chained (Russound term), one controller acts as the master so to the plug-in, it would look like 1 controller with 18 zones.

Actually, it doesn't need the open '('. I've been doing a lot of programming lately in a different language that does require '()' in if statements. I don't have any Sensibo devices so I can't really test the changes. Version 2.0.8 with the fix was published to the store.

Do they all have the same IP address? The node address is created using the last part of the IP address so if they all have the same IP address, each new CAM/CAV you add will replace the previous one. The node addresses need to be unique and typically, the device IP address is. But if you're using a IP <-> serial box that has 1 IP address and different ports assigned to each serial port, that presents a problem. At this point, I don't have a solution.

Thanks for providing the feedback and solutions. That makes it easy to update. Version 2.0.7 is in the store and, if I made the changes correctly, should work for you now. The eisy/Polisy only accepts numbers for temperature values, there's no way to make that display a '-' or N/A.

Does this mean that it's showing all three controller nodes? If so, then it's probably configured properly. When the plug-in connects to a controller, it queries the controller for it's setup. The controller should return how many zones are configured and what those zones are named. If you're not seeing zones created for a controller, then that controller probably says it has no zones configured. Running the plug-in with debug level logging will provide a lot of details on what the plug-in is doing and what the controllers are sending back in response to queries.

Yes, the same way you added the first one. Install a second copy of the Caseta plug-in in an unused slot Set the IP address of the second hub in the plug-in configuration Press the black button on the hub to pair it when prompted by the plug-in

That's strange. I'm not able to reproduce any of that. After install, I get the "You need to set your API key" notice. I enter an API key (I don't have an Ambient system or account so I have to use someone else's key) The notice immediately disappears and the plug-in starts sending queries out. The plug-in does not have any code to send any other messages for PG3 to display. So I have no idea where the second box in #4 is coming from. The plug-in should be logging API key failures and if debug logging is enabled, it will show the URL it is using there. But there are no extra spaces in that URL. If you do re-install, please enable debug level logging before entering your API key and then download the log package (maybe even do a screen capture with both messages on the screen).

Well, that's one of my plug-ins and there shouldn't be anything that carries over from a plug-in restart. Next time it happens, download the log package and PM it to me.

No, it should not. "Restart IoX should only restart the IoX process. The "Reboot" button in the UD console will reboot the eisy, basically doing a shutdown -r now command. I believe the only way to power down the eisy is via the command line using the shutdown command. As far as I know, the only way to restart PG3x is to reboot the eisy**. This is not something that should be needed on a regular basis. You should be able to individually restart plug-ins using the Restart button in the plug-in's detail page of PG3. If that's not working, then it's a bug that should be reported. ** It is possible to restart the PG3x process via the FreeBSD command line, but this is not an operation that is recommended. When the eisy starts, it starts the various processes in a specific order so that they all set up to communicate with each other properly. Restarting PG3 outside of the process may cause issues.

The PG3 version shouldn't be the cause. However, the ISY994 is EOL'd and is not getting the firmware updates that Polisy/IoX eisy/IoX are getting and there have been changes in the profile file support in the new firmware that could be the cause. As you can see, we've been throwing out random suggestions on things to try but we don't really have enough information to determine what the issue is. Whenever there is a problem with a plug-in, you'll get the best support if you follow these steps when posting about the issue: Change the plug-in's log level to debug Restart the plug-in Do whatever makes the issue apparent Download the plug-in's log package PM the log package to the plug-in's author (or attach it to your post) Include the ISY/IoX firmware version and PG3 version information If you end up submitting a ticket to UDI, attaching the log package to that is also very helpful.

This type of issue tends to be related to the node definition files for the plug-in. When the plug-in starts, it sends the node definition files to the IoX. There's no retries on this so if the IoX rejects it or something else disrupts that send, the files on the IoX may be missing or incomplete. The plug-in details page has a button "Load Profile" that when pressed, will resend the files to IoX. The admin console reads those files from IoX when it starts (and only when it starts). So if the files are sent to IoX while the AC is running, it won't see the updates/new files. You need to restart the AC for it to re-read the files. Lastly, if there's been an update to the plug-in and the node definition files were changed, that could have introduced an error into the files that cause both IoX and the AC to fail while parsing them. @Geddy suggestion to restart the AC is the first step. I'd also suggest that you use the "Load Profile" button first, give it a minute and then restart the AC.

Are you saying that the RainMachine controller has failed and isn't working at all? In that case, you're right they'll probably never send you a replacement. Your only option would be to look for a used controller (ebay?) or switch to something else. Your post was a little ambiguous on that point, I wasn't sure if meant the controller had died or you couldn't get it working because they were out of business. If the controller and it's app are still working and it's just the plug-in that's not, you might want to set the log level to debug and make a post in the RainMachine sub-forum for help.