"Bytes must be in range" while re-adding

[RBMaurice90]

For some reason my WF-RAC integration stopped polling information last night. Rather than rebooting (which probably would have solved it straight away) my first thought was to disable and re-enable the device.

After a reboot that still did not work so I tried to delete the device and add it again. It is even automatically detected and suggested as a new device, but unfortunately it is impossible to add the device. Well it adds it, but you end up with a device called airco and some random string with zero entities in it.

In journalctl I see this: Nov 16 19:20:52 homeassistant homeassistant[492]: 2022-11-16 20:20:52.015 WARNING (MainThread) [custom_components.mitsubishi-wf-rac] Something whent wrong setting up device [192.168.2.123] bytes must be in range(0, 256)

Also in the logs I found errors from the time when the reading was not working correctly: Nov 16 17:07:10 homeassistant homeassistant[492]: 2022-11-16 18:07:10.504 ERROR (MainThread) [homeassistant.helpers.entity] Update for climate.airco_a043b0bd3ff9 fails Nov 16 17:07:10 homeassistant homeassistant[492]: Traceback (most recent call last): Nov 16 17:07:10 homeassistant homeassistant[492]: File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 527, in async_update_ha_state Nov 16 17:07:10 homeassistant homeassistant[492]: await self.async_device_update() Nov 16 17:07:10 homeassistant homeassistant[492]: File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 722, in async_device_update Nov 16 17:07:10 homeassistant homeassistant[492]: raise exc Nov 16 17:07:10 homeassistant homeassistant[492]: File "/config/custom_components/mitsubishi-wf-rac/climate.py", line 151, in async_update Nov 16 17:07:10 homeassistant homeassistant[492]: await self._device.update() Nov 16 17:07:10 homeassistant homeassistant[492]: File "/config/custom_components/mitsubishi-wf-rac/wfrac/device.py", line 69, in update Nov 16 17:07:10 homeassistant homeassistant[492]: self._airco = self._parser.translate_bytes(response["airconStat"]) Nov 16 17:07:10 homeassistant homeassistant[492]: File "/config/custom_components/mitsubishi-wf-rac/wfrac/rac_parser.py", line 270, in translate_bytes Nov 16 17:07:10 homeassistant homeassistant[492]: ac_device.Electric = int.from_bytes(vals[i + 2: i + 3], "little", signed=False ) * 0.25 Nov 16 17:07:10 homeassistant homeassistant[492]: ValueError: bytes must be in range(0, 256)

Is it possible the AC is running too long (has been on 24x7 for ±1 week heating at 20C ) forcing some value to go out of the expected range? (since I would never cool for 1 week continiously) Because it seems the reading were already out of range causing it to malfunction. Have not started and stopped the AC unit yet.

I do use a static IP and did also reset the WF-RAC hardware module on the AC unit just to rule that out.

Worked amazingly well until today 👍

[RBMaurice90]

Can confirm that turning off the unit does not work. But starting it again (and resetting the power used since last cycle) does solve this bug.

Hope you can look into this 🥇

[mcheijink]

I think that you have nailed the cause of this error. It would appear that the function int from bytes can only parse values up to 255. (~64 kWh). ac_device.Electric = int.from_bytes(vals[i + 2: i + 3], "little", signed=False ) 0.25The current input to this function is two bytes long, and will exceed 255.I do not know how to program this nicely in Python, but the line below will probably solve this issue: ac_device.Electric = int.from_bytes(vals[i + 2], "little", signed=False ) 64 + int.from_bytes(vals[i + 3], "little", signed=False ) * 0.25Op 16 nov. 2022 om 22:07 heeft RBMaurice90 @.**> het volgende geschreven: For some reason my WF-RAC integration stopped polling information last night. Rather than rebooting (which probably would have solved it straight away) my first thought was to disable and re-enable the device. After a reboot that still did not work so I tried to delete the device and add it again. It is even automatically detected and suggested as a new device, but unfortunately it is impossible to add the device. Well it adds it, but you end up with a device called airco and some random string with zero entities in it. In journalctl I see this: Nov 16 19:20:52 homeassistant homeassistant[492]: 2022-11-16 20:20:52.015 WARNING (MainThread) [custom_components.mitsubishi-wf-rac] Something whent wrong setting up device [192.168.2.123] bytes must be in range(0, 256) Also in the logs I found errors from the time when the reading was not working correctly: Nov 16 17:07:10 homeassistant homeassistant[492]: 2022-11-16 18:07:10.504 ERROR (MainThread) [homeassistant.helpers.entity] Update for climate.airco_a043b0bd3ff9 fails Nov 16 17:07:10 homeassistant homeassistant[492]: Traceback (most recent call last): Nov 16 17:07:10 homeassistant homeassistant[492]: File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 527, in async_update_ha_state Nov 16 17:07:10 homeassistant homeassistant[492]: await self.async_device_update() Nov 16 17:07:10 homeassistant homeassistant[492]: File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 722, in async_device_update Nov 16 17:07:10 homeassistant homeassistant[492]: raise exc Nov 16 17:07:10 homeassistant homeassistant[492]: File "/config/custom_components/mitsubishi-wf-rac/climate.py", line 151, in async_update Nov 16 17:07:10 homeassistant homeassistant[492]: await self._device.update() Nov 16 17:07:10 homeassistant homeassistant[492]: File "/config/custom_components/mitsubishi-wf-rac/wfrac/device.py", line 69, in update Nov 16 17:07:10 homeassistant homeassistant[492]: self._airco = self._parser.translate_bytes(response["airconStat"]) Nov 16 17:07:10 homeassistant homeassistant[492]: File "/config/custom_components/mitsubishi-wf-rac/wfrac/rac_parser.py", line 270, in translate_bytes Nov 16 17:07:10 homeassistant homeassistant[492]: ac_device.Electric = int.from_bytes(vals[i + 2: i + 3], "little", signed=False ) 0.25 Nov 16 17:07:10 homeassistant homeassistant[492]: ValueError: bytes must be in range(0, 256) Is it possible the AC is running too long (has been on 24x7 for ±1 week heating at 20C ) that some value is going out of the expected range? Because it seems the reading were already out of range causing it to malfunction. Have not started and stopped the AC unit yet. I do use a static IP and did also reset the WF-RAC hardware module on the AC unit just to rule that out.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mcheijink]

I think that you have nailed the cause of this error. It would appear that the function int from bytes can only parse values up to 255. (~64 kWh).

ac_device.Electric = int.from_bytes(vals[i + 2: i + 3], "little", signed=False ) * 0.25

The current input to this function is two bytes long, and will exceed 255. I do not know how to program this nicely in Python, but the line below will probably solve this issue:

ac_device.Electric = int.from_bytes(vals[i + 2], "little", signed=False ) * 64 + int.from_bytes(vals[i + 3], "little", signed=False ) * 0.25

[tpylvane]

I have the same issue and would like to get the remote commanding back to operation. Since this is my first HACS integration I am a bit lost. Can I just change that line in .py file and reboot to get the integration back working?

[maglerod]

I'll wait until there will be a new version with fix, until that i just turn off the Airco and on again via the remote. Then WF-RAC interface resets the calculation and it will work again. Atleast it does for me :).

Update , i just added an try except around the area where the problem is. I don't care about the sensor values since i have other sensors that handle that stuff.

[RBMaurice90]

That should fix it yes 👍

Verstuurd vanaf mijn iPhone

Op 22 nov. 2022 om 09:55 heeft maglerod @.***> het volgende geschreven:



I'll wait until there will be a new version with fix, until that i just turn off the Airco and on again via the remote. Then WF-RAC interface resets the calculation and it will work again. Atleast it does for me :).

— Reply to this email directly, view it on GitHubhttps://github.com/jeatheak/Mitsubishi-WF-RAC-Integration/issues/28#issuecomment-1323318833, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZXT7OQYSUITDGARTDSNMGDWJSC7VANCNFSM6AAAAAASCVJ6SE. You are receiving this because you authored the thread.Message ID: @.***>

[jeatheak]

Hey Guys,

It looks like it is indeed what @mcheijink is saying. I will try to implement it but have very little time at the moment. Sorry for the delay.

[maglerod]

My try except did the trick until bug is fixed :)

[glsf91]

I think that you have nailed the cause of this error. It would appear that the function int from bytes can only parse values up to 255. (~64 kWh).

The error also occurred here but when reaching 32 kWh and not 64 kWh. 31.75 was the last value I saw before the error. Looks like vals[i+2] is a signed byte. I have a SRK35ZS-W2

edit: vals[x] is a signed integer already because of this:

content_byte_array = [ (256 - a) * (-1) if a > 127 else a for a in content_byte_array ]

For me this is working when reaching 32kWh: ac_device.Electric = ( ((vals[i + 3] & 0x7f) + (vals[i + 3] & 0xF0) * 64) + (vals[i + 2] & 0x7f) + (vals[i + 2] & 0xF0) )* 0.25

[tpylvane]

I think that you have nailed the cause of this error. It would appear that the function int from bytes can only parse values up to 255. (~64 kWh).

The error also occurred here but when reaching 32 kWh and not 64 kWh. 31.75 was the last value I saw before the error. Looks like vals[i+2] is a signed byte. I have a SRK35ZS-W2

edit: vals[x] is a signed integer already because of this:

content_byte_array = [ (256 - a) * (-1) if a > 127 else a for a in content_byte_array ]

For me this is working when reaching 32kWh: ac_device.Electric = ( ((vals[i + 3] & 0x7f) + (vals[i + 3] & 0xF0) * 64) + (vals[i + 2] & 0x7f) + (vals[i + 2] & 0xF0) )* 0.25

I changed the line to this and now it works, BUT I am pretty sure the calculation is now wrong. But for me this is ok, i mainly need the controllability. Thanks guys.

[glsf91]

For me it is working also above 64kWh and matching my kWh meter.

[bjorne]

I don't understand what kind of encoding could work with your expression @glsf91, can you elaborate? Why are the upper bits of the first byte multiplied by 64, but the other masks not multiplied at all?

I think the original code is wrong for two reasons:

• it slices just the first byte (vals[i + 2: i + 3]) when it should take both bytes (vals[i + 2: i + 4])
• it assumes the value is unsigned, but that is no longer try because of the content_byte_array manipulation mentioned by @glsf91 above

So wouldn't the best fix just be to undo the signing prior to conversion (with both bytes included), like so:

int.from_bytes([(256 + v) % 256 for v in vals[i + 2: i + 4]], "little", signed=False ) * 0.25

I wrote a quick comparison for some example values. Unfortunately I don't have any values >32kWh handy right now, but let me know if this seems correct: https://gist.github.com/bjorne/20829735df1063b1e776ca83f259bf2c

I'm gonna try my version for a while and see what happens :)

[glsf91]

Basically I make it unsigned. I think your are right: also the upper upper bit should by included in the multiply. So my solution should be: ac_device.Electric = ( (((vals[i + 3] & 0x7f) + (vals[i + 3] & 0xF0)) * 64) + (vals[i + 2] & 0x7f) + (vals[i + 2] & 0xF0) )* 0.25 I'm not a python expert. So there are many ways to do this.

[FrankM0]

I don't understand what kind of encoding could work with your expression @glsf91, can you elaborate? Why are the upper bits of the first byte multiplied by 64, but the other masks not multiplied at all?

I think the original code is wrong for two reasons:

• it slices just the first byte (vals[i + 2: i + 3]) when it should take both bytes (vals[i + 2: i + 4])
• it assumes the value is unsigned, but that is no longer try because of the content_byte_array manipulation mentioned by @glsf91 above

So wouldn't the best fix just be to undo the signing prior to conversion (with both bytes included), like so:

int.from_bytes([(256 + v) % 256 for v in vals[i + 2: i + 4]], "little", signed=False ) * 0.25

I wrote a quick comparison for some example values. Unfortunately I don't have any values >32kWh handy right now, but let me know if this seems correct: https://gist.github.com/bjorne/20829735df1063b1e776ca83f259bf2c

I'm gonna try my version for a while and see what happens :) I have the MHI running 24/7 so i've ran into this issue several times now, until i found this thread.

I'm no expert in all of this so i had a quick learning curve in HA to change what you guys wrote about:

Here goes:

/config/custom_components/mitsubishi-wf-rac/wfrac/rac_parser.py (Use 'File Editor' in HA) Change ac_device.Electric = int.from_bytes(vals[i + 2: i + 3], "little", signed=False ) * 0.25 to ac_device.Electric = int.from_bytes([(256 + v) % 256 for v in vals[i + 2: i + 4]], "little", signed=False ) * 0.25

Just changed that single line to yours, restarted HA and MHI WF-RAC integration started working again without restarting the AC. Hope it will continue to work until the fix is added.

My 'Energy usage cycle' is above 32 kWh, it's 40 kWh. Is that what you're referring to?

Thanks!

[bjorne]

Great to hear @FrankM0. It’s working well for me as well, 125 kWh and counting:

[RBMaurice90]

Is the definitive fix ready to be pushed to the main project?

Op 19 dec. 2022 om 22:21 heeft Björn Ramberg @.***> het volgende geschreven:



Great to hear @FrankM0https://github.com/FrankM0. It’s working well for me as well, 125 kWh and counting:

[D2FB9BF9-594B-4EE3-9354-43BD990E41B0]https://user-images.githubusercontent.com/65805/208526235-701eb55a-8305-4403-8f87-c28889aecc05.jpeg

— Reply to this email directly, view it on GitHubhttps://github.com/jeatheak/Mitsubishi-WF-RAC-Integration/issues/28#issuecomment-1358384266, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZXT7OXJWINFPKQTKSHJVG3WODGVFANCNFSM6AAAAAASCVJ6SE. You are receiving this because you authored the thread.Message ID: @.***>

[RBMaurice90]

Any timeline on a fix?

[FrankM0]

@RBMaurice90 the change has been merged into main, as far as i understand. https://github.com/jeatheak/Mitsubishi-WF-RAC-Integration/commit/38e6dc4af8859e9aa3e440f8eae9a9861be4cff0 Doing this manually has fixed it for me.

So i guess if you redownload main you'll have the fix?

[RBMaurice90]

It doesn’t have a new version number? So I can’t upgrade I think, only delete and start over? How do I get this change without breaking my existing HA entities/integrations.