Freddy Kilowatt Posted May 24 Posted May 24 Running an EISY with 5.9.1 firmware and Polyglot V3. I'm using the Sensibo plugin and it works fairly well. But, the mode displayed doesn't always match the mode set. Setting the mode does send the correct mode to the Sensibo device and air conditioner. But, the mode displayed is not correct. I looked over the code and think I found the reason. In sensibo_node.py line 155 the uom for the mode is defined as 67 which references a table of thermostat modes. But I think it should be 25 for index since it is used to lookup the value in the arrays defined in line 7 (MODEs) and 19 (MODE_COUNTER). The array index look up works for FAN_LEVEL in _update(self, data) and setFan(self, param). The code for MODES should probably work the same way in _update(self, data) and setMode(self, param). The mode that is displayed matches the table for uom 67. 67 = Thermostat mode 0 - Off 1 - Heat 2 - Cool 3 - Auto 4 - Aux/Emergency Heat 5 - Resume 6 - Fan Only 7 - Furnace 8 - Dry Air 9 - Moist Air 10 - Auto Changeover 11 - Energy Save Heat 12 - Energy Save Cool 13 - Away 14 = Program Auto 15 = Program Heat 16 = Program Cool When it should display the modes defined in MODES line 7 MODES = ['cool', 'heat', 'fan', 'dry', 'auto'] I'm not a python programmer and I am not sure how to make my own version and load it into the EISY or I would test this out myself. Thanks! Quote
Freddy Kilowatt Posted May 26 Author Posted May 26 (edited) My assumption above was incorrect. I figured out how to edit the sensibo plugin code directly on my EISY and debugged the issue. I made two changes to the file sensibo_node.py. Here is the diff output 19c19 < MODE_COUNTER = { 'cool': 0, 'heat': 1, 'fan': 2, 'dry': 3, 'auto': 4 } --- > #MODE_COUNTER = { 'cool': 0, 'heat': 1, 'fan': 2, 'dry': 3, 'auto': 4 } 20a21,23 > # This corrects the display of the mode on the Administrative Console > MODE_COUNTER = { 'cool': 2, 'heat': 1, 'fan': 6, 'dry': 8, 'auto': 3 } > 83c86 < self.setDriver('GV2', data['acState']['targetTemperature'], uom=temp_uom) --- > # self.setDriver('GV2', data['acState']['targetTemperature'], uom=temp_uom) 84a88,98 > # The line above was crashing because the targetTemperature is not returned when > # the mode is in fan only mode. Since it is undefined in fan only mode it should > # probably be displayed as "-" on the Administrative Console. I don't know how to > # do that so I just skipped doing the update. > > try: > if(data['acState']['targetTemperature']): > self.setDriver('GV2', data['acState']['targetTemperature'], uom=temp_uom) > except: > LOGGER.debug('targetTemperature not present in acState') > The first change to the MODE_COUNTER definition corrected the issue I was having with the Administrative Console displaying wrong values for the Mode. As I tested that it still correctly controlled the sensibo I observed a crash when the sensibo was set to Fan Only mode. In this mode the acState doesn't include targetTemperature since it is unused and thus undefined. This was causing an exception in the code of line 83. I changed this to not attempt to update the displayed Target Temperature if it was not reported. It would be better if it displayed "-" or "NA" but I do not know how to code that. I hope this helps and can be incorporated into the plugin code. I attached my final version of sensibo_node.py sensibo_node.py Edited May 26 by Freddy Kilowatt Quote
bpwwer Posted May 26 Posted May 26 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. Quote
Freddy Kilowatt Posted May 26 Author Posted May 26 (edited) Thanks! That was quick. I tried version 2.0.7 and at first it did not work. I found I needed to add a close parenthesis at the end of line 84 before the colon. Then it works fine. 84c84 < if('targetTemperature' in data['acState']: --- > if('targetTemperature' in data['acState']): I can only edit the file on my EISY so you will need to update the plugin to fix this typo. Edited May 27 by Freddy Kilowatt Quote
Solution bpwwer Posted May 27 Solution Posted May 27 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. Quote
Freddy Kilowatt Posted May 27 Author Posted May 27 (edited) Thanks! 2.0.8 is working fine. I haven't programmed in python (before my hacking on this). So, I'm not well versed in the syntax. But, I can understand what I'm reading. So I can see your method to test if targetTemperature is returned is a better solution than what I had used in my first attempt at a fix. Thanks for your help. I think this one is solved. Edited May 27 by Freddy Kilowatt Quote
Freddy Kilowatt Posted June 14 Author Posted June 14 (edited) I found there is still an issue with the Sensibo plugin. Although it is now displaying a reasonable mode in the administrative console, It doesn't properly allow the mode to be a test in a program. This has to do with the fact that the editor is using the MODES array to determine the mode for setting and for testing in a program. But the displayed mode is set using MODE_COUNTER and mapped to the uom type 67 (Thermostat Mode) table. These don't properly compare in and if statement of a program. This can be fixed by eliminating the translation between the MODES array and the uom type 67 using MODE_COUNTER and using uom 25 (index) in the driver. I tested this on my system and it fixes the compare issue for programs and displays the correct mode matching the five Sensibo modes used in the MODES array. Here is a diff output showing the changes I made (removing MODE_COUNTER and using uom 25 for CLIMD). 9d8 < # Not sure about this. Shouldn't this match modes above? 16,20d14 < #MODE_COUNTER = { 'cool': 2, 'heat': 1, 'fan': 6 } < # < # Try this instead??? < MODE_COUNTER = { 'cool': 2, 'heat': 1, 'fan': 6, 'dry': 8, 'auto': 3 } < 78c72 < self.setDriver('CLIMD', MODE_COUNTER[data['acState']['mode']]) --- > self.setDriver('CLIMD', MODES.index(data['acState']['mode'])) 91d84 < 150c143 < self.setDriver('CLIMD', MODE_COUNTER[MODES[int(param['value'])]]) --- > self.setDriver('CLIMD', int(param['value'])) 162c155 < {'driver': 'CLIMD', 'value': 0, 'uom': 67}, --- > {'driver': 'CLIMD', 'value': 0, 'uom': 25}, I attached my final version of sensibo_node.py Thanks! -Mark Smith sensibo_node.py Edited June 14 by Freddy Kilowatt Quote
bpwwer Posted June 15 Posted June 15 19 hours ago, Freddy Kilowatt said: This has to do with the fact that the editor is using the MODES array to determine the mode for setting and for testing in a program. But the displayed mode is set using MODE_COUNTER and mapped to the uom type 67 (Thermostat Mode) table. These don't properly compare in and if statement of a program. This can be fixed by eliminating the translation between the MODES array and the uom type 67 using MODE_COUNTER and using uom 25 (index) in the driver. I tested this on my system and it fixes the compare issue for programs and displays the correct mode matching the five Sensibo modes used in the MODES array. 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. Quote
Freddy Kilowatt Posted June 15 Author Posted June 15 I have not used eisy-ui so I can't speak to that. I have Sensibo devices for controlling my mini split heat pumps. And I have ecobee thermostats for controlling my hydronic oil heat. The display in both IoX administrative console and on the android version of UD Mobile look the same with the sensibo coded either way (uom 25 or 67) and the ecobee which does use uom 67. The only difference I see using oem 67 verses oem 25 is the actual text displayed for the mode. In version 2.0.8 we have it displaying the correct modes using the string definitions in the API table for Thermostat mode. They don't exactly match the text that the sensibo mobile app and web app display for the modes. For instance uom 67 displays "Fan Only" verses "Fan" and "Dry Air" verses "Dry". But these still make sense. Using oem 25 and the MODES array, the text matches the modes used by sensibo in their apps. I can test a version that corrects the nodedef and editor to use 67. It would not take me long to redo the programs I have if that is needed. Since I'm not setup as a developer I have to edit the files on my EISY to try out changes. If you think that is the best way to go, I can either try to make the changes myself or I can test out a version you create. Quote
Freddy Kilowatt Posted June 15 Author Posted June 15 Then of course there is table 68 for fan mode.... But it doesn't have a value for low. Quote
bpwwer Posted Sunday at 07:45 PM Posted Sunday at 07:45 PM 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 Quote
Freddy Kilowatt Posted Sunday at 10:44 PM Author Posted Sunday at 10:44 PM (edited) I tested the new version and it needs a couple edits to function properly. I removed 0 (off) from the editor mode list since it doesn't currently map to a sensibo mode setting. It would need other code changes to handle translating that to the sensibo on/off. > <range uom="67" subset="0-3,6,8" /> < <range uom="67" subset="1-3,6,8" /> I changed the MODES array to translate "1-3,6,8" to the 5 modes supported. > MODES = ['cool', 'heat', 'fan', 'dry', 'auto'] < MODES = ['', 'heat', 'cool', 'auto', '', '', 'fan', '', 'dry'] This works but, there may well be a better way to handle this translation. The plugin seems to work with these two changes. The mode tests properly in a program if statement. I found out how to get my UD Mobile to display the pretty thermostat display. By setting the device type to thermostat. Unfortunately it looks like this plugin would need a lot of work for that to be useful. The only thing that it currently displays is the mode, humidity, and on/off. Attempting to use any controls including setting the mode brings up error various messages. I don't think the proper functions are mapped to the controls. (Family Room is a Sensibo controlled heat pump.) The other issue with this plugin is the Sensibo device is configured by learning what AC remote control it supposed to mimic to control the AC. In my case it is controlling a Fujitsu mini-split. But for other devices it may behave differently and this plugin may not work well. The sensibo does report through the API what modes, fan modes, temperatures are supported for the current configuration but the plugin doesn't parse those and adjust accordingly. I attached what the API reports for my device. For me, I would change the editor for temperature to only include the values supported for my system but these may not be appropriate for others. > <range uom="4" min="18" max="30" prec="0" step="1" /> > <range uom="17" min="50" max="88" prec="0" step="1" /> < <range uom="4" subset="10, 16-30" /> < <range uom="17" subset="50, 61, 63, 64, 66, 68, 70, 72, 73, 75, 77, 79, 81, 82, 84, 86" /> Thank for your assistance. -Mark Sensibo API output - Fujitsu mini-split Heat Pump.txt Edited Sunday at 11:09 PM by Freddy Kilowatt Quote
bpwwer Posted Monday at 12:25 AM Posted Monday at 12:25 AM 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? Quote
Freddy Kilowatt Posted Monday at 01:32 AM Author Posted Monday at 01:32 AM Wow! that was a bunch of code changes. But it looks to be working pretty well. I agree we just need a way to translate to IoX mode to the string we need to send to Sensibo. The fan mode extension seems to work I can set all fan modes and they display correctly. I see the CLISPH and CLISPC both updating and reflecting the temp settings Current operating mode is tricky because the sensibo just sends IR to set the AC mode but doesn't get any feed back as to what the AC is currently doing. the closest thing we know is what mode we last sent to the AC (acState:mode). But if that is set to auto we can't tell if the AC is currently heating, idle, or cooling. Unless we can dynamically adapt the editor temp settings to what the API says it supports (which is reported) then we need to keep it generic. We might add 10c which maps to the minimum heat setting of 50f. We do have 50f currently available. Funny, I just reset the shouldCleanFilters notification for my units. So I can't test that for a while. I believe there is a boolean returned at filtersCleaning:shouldCleanFilters you can see it set false in the API output I included in my last message. The thermostat display looks better. But fan mode is not diplayed. and On/Off is diplayed in the upper right verses temp for my ecobee. But none of the settings work. I get a error message "Status could not be linked to command" for mode and the set temps. I get "Node Status Relation Cursor is empty. Nodeid: 478. Control: CLIFS" for the fan mode box. No response from the temp up and down arrows. Quote
bpwwer Posted Monday at 03:56 AM Posted Monday at 03:56 AM 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. Quote
bpwwer Posted Monday at 05:29 PM Posted Monday at 05:29 PM @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. Quote
Freddy Kilowatt Posted Monday at 10:35 PM Author Posted Monday at 10:35 PM (edited) This version is working quite well. And it looks good on the thermostat display. The temp up/down are working and no errors are logged. The fan setting is missing the quiet option but the fan status is properly displays that if set elsewhere. The status display has 2 labeled Target Temperature. It might be clearer if we added heat and cool to the labels to differentiate them. We have some redundant command buttons. We still have the original 3 Set Temperature, Set Fan Level and Set Mode. These are redundant now with the new ones added. But, maybe we need to keep them so we don't break someone's programs when they upgrade versions? Also we now have command buttons for Dim and Brighten which don't really apply. Overall I haven't found any other issues yet. I'll continue to test and let you know if I come across any other ones. Edited Monday at 11:02 PM by Freddy Kilowatt Quote
bpwwer Posted Monday at 11:46 PM Posted Monday at 11:46 PM 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. Quote
Freddy Kilowatt Posted Tuesday at 12:19 AM Author Posted Tuesday at 12:19 AM (edited) Minor observations: The power state on the IoX console is displayed on/off. The power state on the UD Mobile is displayed 1/0. From log brighten and dim: 2025-06-16 20:22:49.850 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message command 2025-06-16 20:22:49.850 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING command 2025-06-16 20:22:49.850 Command udi_interface.interface DEBUG interface:_handleInput: PROCESS command message {'address': 'spanndgf', 'cmd': 'BRT', 'query': {}} from Polyglot 2025-06-16 20:22:49.850 Command udi_interface DEBUG sensibo_node:adjTemperature: increment or decrement temp: {'address': 'spanndgf', 'cmd': 'BRT', 'query': {}} 2025-06-16 20:22:51.363 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message command 2025-06-16 20:22:51.363 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING command 2025-06-16 20:22:51.363 Command udi_interface.interface DEBUG interface:_handleInput: PROCESS command message {'address': 'spanndgf', 'cmd': 'DIM', 'query': {}} from Polyglot 2025-06-16 20:22:51.363 Command udi_interface DEBUG sensibo_node:adjTemperature: increment or decrement temp: {'address': 'spanndgf', 'cmd': 'DIM', 'query': {}} Edited Tuesday at 12:34 AM by Freddy Kilowatt Quote
bpwwer Posted Tuesday at 05:04 PM Posted Tuesday at 05:04 PM 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. Quote
Freddy Kilowatt Posted Tuesday at 05:34 PM Author Posted Tuesday at 05:34 PM (edited) 2.0.12 fails to start due to a syntax error. It works if I add and except: followed by a logger entry. from log: 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b90265f1_2/sensibo_poly.py", line 6, in <module> 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b90265f1_2/sensibo_poly.py", line 6, in <module> 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: from sensibo_node import SensiboNode 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: from sensibo_node import SensiboNode 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b90265f1_2/sensibo_node.py", line 109 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: def _changeProperty(self, property, value): 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: SyntaxError 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: : 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: expected 'except' or 'finally' block 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b90265f1_2/sensibo_node.py", line 109 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: def _changeProperty(self, property, value): 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: SyntaxError 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: : 2025-06-17 13:32:32.372 MainThread udi_interface ERROR udi_interface:write: expected 'except' or 'finally' block Edited Tuesday at 05:43 PM by Freddy Kilowatt Quote
bpwwer Posted Tuesday at 06:09 PM Posted Tuesday at 06:09 PM Opps, that's the problem with not testing. I just pushed out a new version with the fix. Quote
Freddy Kilowatt Posted Tuesday at 06:40 PM Author Posted Tuesday at 06:40 PM (edited) Fan mode quiet is fixed. We might want to remove 13 (not supported) from the editor subset since nobody should need to set the fans to that. I tried editing the order of the subset to "0,10,11,5,3,12" to make the sequence that is displayed in the settings to auto, quiet, low, medium, high, strong. But that doesn't seem to work. I don't know if there is another way to sort them. It would just seem cleaner. I am still seeing the redundant commands displayed but the don't do anything now. They log an error that the commands don't exist. Which I assume you would expect now. They are still in nodedef.xml deleting them there removes them. The Targetup and Targetdown buttons are not working. See debug log below. UD Mobile is now displaying on/off for Power State. I'll continue to test but have to step out for a bit. Mark 2025-06-17 14:24:49.933 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message command 2025-06-17 14:24:49.933 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING command 2025-06-17 14:24:49.933 Command udi_interface.interface DEBUG interface:_handleInput: PROCESS command message {'address': 'spanndgf', 'cmd': 'BRT', 'query': {}} from Polyglot 2025-06-17 14:24:50.565 Command udi_interface ERROR sensibo_node:adjTemperature: temperature adjustment failed 2025-06-17 14:24:50.833 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message command 2025-06-17 14:24:50.834 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING command 2025-06-17 14:24:50.834 Command udi_interface.interface DEBUG interface:_handleInput: PROCESS command message {'address': 'spanndgf', 'cmd': 'DIM', 'query': {}} from Polyglot 2025-06-17 14:24:51.439 Command udi_interface ERROR sensibo_node:adjTemperature: temperature adjustment failed Edited Tuesday at 07:32 PM by Freddy Kilowatt Quote
Freddy Kilowatt Posted Wednesday at 01:12 AM Author Posted Wednesday at 01:12 AM (edited) Took me awhile but I figured out why the Targetup and Targetdown are not working. The issue was the conversion to centigrade. It turns out that that is not needed by the API. It never actually happens in setTemperature() because the test was comparing a string param('uom') to an integer. Otherwise that function would have failed too. The increment/decrement by 1 for Fahrenheit is problematic since the valid values are [50, 61, 63, 64, 66, 68, 70, 72, 73, 75, 77, 79, 81, 82, 84, 86]. In many cases incrementing/decrementing by 1 will round back down when the next poll happens. adjusting by 2 for Fahrenheit is an improvement but decrementing 64 to 62 will result in a setting of 61. Converting to centigrade, incrementing/decrementing, and then converting back to Fahrenheit probably works correctly. It would be nice if the temperature editor could select between the C values and the F values offered based on the value of self.temp_uom. If you select from the C list while the unit is in Farenheit the temp gets set to the lowest valid F temp. And if you choose from the F list while in centigrade it sets the high valid C temp. I also just noticed the fan mode for Low and Strong display numbers (11 and 12) in the status on UD Mobile. The editor shows the correct text for selection. IoX shows the correct text for both the editor and the status. UD Mobile status shows False for Replace Filter. IoX displays No. I seems UD Mobile doesn't always substitute the nls defines. changes I made: nodedef.xml - remove the redundant commands 47,55d46 < <cmd id="SET_TEMPERATURE"> < <p id="" editor="temperature" /> < </cmd> < <cmd id="SET_FAN"> < <p id="" editor="fanmode" /> < </cmd> < <cmd id="SET_MODE"> < <p id="" editor="mode" /> < </cmd> editors.xml - add 10 C to temp setting selections, remove Not Supported from fan setting selections 7,8c7,8 < <range uom="4" min="18" max="30" prec="0" step="1" /> < <range uom="17" min="50" max="88" prec="0" step="1" /> --- > <range uom="4" subset="10,18-30" /> > <range uom="17" subset="50, 61-86" /> 28c28 < <range uom="68" subset="0,3,5,10,11,12,13" nls="SFAN" /> --- > <range uom="68" subset="0,3,5,10,11,12" nls="SFAN" /> 37a38 > sensibo_node.py - fix increment/decrement. Conversion to C not needed and actually fails. 143,146d142 < if param['uom'] == 17: < # expects temp in C? < temp = round(((temp - 32) * 5) / 9, 0) < 172,178c168 < temp = self._cur_target < < # if our temperature unit is F, convert to C for API < if self.temp_uom == 17: < # expects temp in C? < temp = round(((self._cur_target - 32) * 5) / 9, 0) < self._changeProperty('targetTemperature', temp) --- > self._changeProperty('targetTemperature', self._cur_target) Edited Wednesday at 01:18 PM by Freddy Kilowatt Quote
bpwwer Posted Thursday at 04:11 PM Posted Thursday at 04:11 PM 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. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.