Freddy Kilowatt

It always return the measurements:temperature in centigrade so the conversion for that in the code to 'ST' is proper. But for setting the acState:targetTemperature it needs to be centigrade or Fahrenheit based on temperatureUnit. There is also acState:nativeTargetTemperature which I believe always takes centigrade. Incrementing or decrementing that probably just works. I didn't know if you could dynamically set the editor values. If so setting the values based on what sensibo reports would be nice. But yes, different AC units may have different values. I suspect it would just be the extent of the range of centigrade values. My units take 16c-30c for cool, dry and auto and add 10c (50f) to that range only for heat (they call that Min.Heat). Another interesting note is Sensibo's Fahrenheit values are different (but more accurate) than my actual remote control. Sensibo uses [61, 63, 64, 66, 68, 70, 72, 73, 75, 77, 79, 81, 82, 84, 86]. My remote control uses [60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88] which is f = c * 2 + 28 Sensibo API output - Fujitsu mini-split Heat Pump.txt

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)

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

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

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': {}}

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.

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.

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

Then of course there is table 68 for fan mode.... But it doesn't have a value for low.

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.

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

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.

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.

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

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!