bpwwer

That is interesting. I bet whatever micro-controller that is in the remote can't do floating point so they had to approximate the conversion formula.

RE: temperature range/step. That makes sense. It looks like internally it works with Celsius and just converts & rounds for Fahrenheit values. We could just hard code the editor range to match, but as we discussed above, that may not work for other mini-splits. I was looking the Home Assistant code and they pull the range from the device capabilities and use that. That's what I'd like to do here too. The only issue I see is that the editor profile is global so what happens if someone has two different units with two different ranges.

Opps, that's the problem with not testing. I just pushed out a new version with the fix.

Ok, version 2.0.12 should have working target temperature adjustment. It should also have a new driver value for the filter change flag. I did remove the redundant commands. RE: power display The plug-in and IoX send numeric values back and forth for all drivers. The plug-in sends IoX a map of numeric values to strings for things that it wants to display as text. For power, it maps 0 to Off and 1 to On (this is in the profile/NLS file). When the admin console starts (and I'm assuming the same for UD Mobile), it queries IoX for the profile files, including that mapping. Each application then has to apply that mapping when it displays the driver value to the user. If it doesn't have the mapping, it will just display the actual numeric value. This means that UD Mobile probably doesn't have the mapping file, but I don't know much about how UD Mobile works so it could also be something else. But the issue is likely on the UD Mobile side. In some rare cases, errors in the profile file can make it past the admin console parser but not the UD Mobile as they are written in different programming languages and have different parsers for those files.

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.