bpwwer

The brighten / dim need to be renamed, those are for temperature up/down and that's what's not currently coded to do anything other than log a debug message. So if you try those and then check the log (with debug level set), let me know what the log messages say. I think I see the problem with the quiet fan mode, that should be fixed now. I'll just update the change log with the changes so anyone upgrading has the opportunity to see what changed before upgrading.

It's not running on your computer that's running the Admin console. That is just acting as a display for the your eisy/polisy. The plug-in is running on the eisy/polisy. When I enter your API (from post above) in my installation, it works fine. Make sure you don't have any extra spaces before or after the configuration values as that will cause problems.

@Freddy Kilowatt I just pushed out version 2.0.11 with the changes. I don't have the temperature adjustments working (temp up/down). It should log a debug message with the info needed to make those work, so if you can capture that message when you try bumping the temp up and down, that would be great. I didn't work on adding the filter change yet either. If I didn't screw it all up, I'm expecting the fan mode and main mode to work. It should now display the temp in the upper right instead of on/off.

I'm not surprised that commands aren't working. They need to be added to the nodedef and mapped in the plug-in to functions to handle them. Most should map to the existing functions. I might have to add some debugging messages to see what gets sent to the plug-in in some cases. I'm not sure why the fan mode isn't displaying something. I thought I had that right so it would display. It might be the status name. The plug-in is using CLIFSR and it probably should be using CLIFS. CLIFSR is fan running state vs. CLIFS is the fan mode. I think it's showing on/off instead of the temperature because the plug-in status is showing power on/off. I believe the thermostat status should be it's current temperature. I just checked the Insteon thermostat nodedef and, yes has the current temperature in the ST driver and doesn't use CLITEMP at all. I'll go ahead and make all these changes and we can see it gets a little closer.

I don't think MODES is even needed anymore since we don't need to translate what IoX sends us and we can use that value directly. We only need to translate that value to the string that Sensibo needs. I had an idea about fan mode. I wonder the built in modes for UOM 68 can be extended with NLS. So I tried that. If it works, it should now show up in the thermostat specific view. I also removed GV2 and replaced it with the heat and cool setpoint status names (CLISPH, CLISPC). Both of these map to the Sensibo target temperature. What's missing from the Sensibo is the current operating state. CLIHCS / UOM=66. I don't know if that information is available in the Sensibo API. I can see where limiting the temperature range to what the fujitsu supports would be nice, but since we don't know of that's correct for any other mini-splits, it's probably better for it to be more generic. It might be worth adding the "shouldCleanFilters" into the plug-in. Seems like that could be handy. Does that show up in the data updates that the plug-in sees? maybe in acstate?

I wouldn't expect the AC to look any different, but I'm surprised that the UD mobile doesn't. Here's what i see for a normal thermostat on the IOS version. I wouldn't expect the Sensibo node to display like that unless it used the same type of nodedef/editor/nls profile files. I understand it's a bit of challenge to make changes without being a developer, but you seem to understand how to work around that with the diff's and such that you've provided already. I can make the changes, but since I don't have any Sensibo devices, I can't test that the changes do what I think they should. But if that's easier for you, I can do that and release an updated version. I looked at the fan modes and it's missing both "low" and "strong" so it doesn't seem like a good fit. The Insteon thermostat fan modes are just on and auto so that's even worse. I went ahead and made the changes to the editor for mode so you can re-install version 2.0.9 and see if that works

You're right, it is wrong. I understand your changes and, yes, that should fix it. However, do you think it might make more sense to fix the nodedef and editor so that the node is of type 67 as that type is specific for thermostat modes? I'm not aware of anything that would care, but it's possible that IoX, UD mobile, or the new eisy-ui may handle type 67 and type 25 differently (I.E. have a more thermostat specific display for type 67). Is that something you can test? I realize it's probably a bit of effort to do that as you probably have to remove the node on the IoX and then restart the plug-in with the changes so you might lose any programming/scenes associated with the node.

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.