WLED
WLED copied to clipboard
HA Service call to WLED entities works but generates KeyError: 'b'
What happened?
I've recently upgraded from 0.13.1-b6, since then after each HA service call to a WLED entity (i.e. turning off the master, selecting presets) I'm getting a get a toast notification with an error in the HA GUI and a new entry in the error log, the action however completes successfully.
This stops HA scripts from completing causing issues in automations.
To Reproduce Bug
Example service call:
service: select.select_option
data:
option: Rainbow
target:
entity_id: select.wled_left_preset
Expected Behavior
Not generate an error...
Install Method
Self-Compiled
What version of WLED?
WLED 0.13.2-a0 (build 2203191)
Which microcontroller/board are you seeing the problem on?
ESP32
Relevant log/trace output
Calling homeassistant.turn_off on wled_master:
Logger: homeassistant.helpers.script.websocket_api_script
Source: components/wled/button.py:78
First occurred: 08:14:32 (1 occurrences)
Last logged: 08:14:32
websocket_api script: Error executing script. Unexpected error for call_service at pos 1: 'b'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 367, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 570, in _async_call_service_step
await service_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1636, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1673, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/usr/src/homeassistant/homeassistant/components/homeassistant/__init__.py", line 122, in async_handle_turn_service
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/core.py", line 1636, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1673, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 671, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 949, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 708, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/light/__init__.py", line 513, in async_handle_light_off_service
await light.async_turn_off(**filter_turn_off_params(light, params))
File "/usr/src/homeassistant/homeassistant/components/wled/helpers.py", line 18, in handler
self.coordinator.update_listeners()
File "/usr/src/homeassistant/homeassistant/components/wled/coordinator.py", line 60, in update_listeners
update_callback()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 325, in _handle_coordinator_update
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 553, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 590, in _async_write_ha_state
state = self._stringify_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 557, in _stringify_state
if not self.available:
File "/usr/src/homeassistant/homeassistant/components/wled/button.py", line 78, in available
and beta > current
File "/usr/local/lib/python3.9/site-packages/awesomeversion/awesomeversion.py", line 164, in __gt__
return self.string != compareto.string and self._compare_versions(
File "/usr/local/lib/python3.9/site-packages/awesomeversion/awesomeversion.py", line 201, in _compare_versions
result = handler(AwesomeVersion(version_a), AwesomeVersion(version_b))
File "/usr/local/lib/python3.9/site-packages/awesomeversion/comparehandlers/modifier.py", line 28, in compare_handler_semver_modifier
SEMVER_MODIFIER_MAP[version_a.modifier_type]
KeyError: 'b'
Anything else?
Self-compliled with -D USERMOD_MULTI_RELAY HA 2022.3.8 (same issue in 2022.4.0b3) Deleting/adding the WLED integration makes no difference
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Hi and thank you for the report! Does the issue occur in release 0.13.1 or only in latest main? @Frenck sorry for pinging, do you think this issue is caused by WLED?
v0.13.1 does NOT seem to be affected however since I've started troubleshooting this and messing with versions I've somehow managed to put both of my lamps into a state where WLED freezes after only a couple minutes of uptime and needs to be unplugged from power to start responding again. I've put ESPHome on one of the ESP32 to test whether it's a HW issue, that seems to be running stable so far. Will report this is a separate issue if it persists (is there a log somewhere that would help troubleshoot that?)
I'm not sure if this is related or a different bug, but I am getting something sort of similar with KeyError: 'b'. I also get that code when some WLED devices get updated via Node-Red service calls (Message: Call-service error. 'b').
I have over 12 WLED devices, so I cannot pinpoint which one is causing the errors (unless it is all of them). I get about 50-100 of these reoccurring errors within 60 seconds causing the number to reach over 1000 very quickly. Cannot confirm when it started, but I know it has been happening with HA 2022.3.
Home Assistant: 2022.4 WLED: 0.13.1
Logger: homeassistant
Source: components/wled/binary_sensor.py:59
First occurred: 11:00:22 (144 occurrences)
Last logged: 11:02:13
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 137, in _handle_refresh_interval
await self._async_refresh(log_failures=True, scheduled=True)
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 268, in _async_refresh
update_callback()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 328, in _handle_coordinator_update
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 532, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 570, in _async_write_ha_state
state = self._stringify_state(available)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 538, in _stringify_state
if (state := self.state) is None:
File "/usr/src/homeassistant/homeassistant/components/binary_sensor/__init__.py", line 209, in state
if (is_on := self.is_on) is None:
File "/usr/src/homeassistant/homeassistant/components/wled/binary_sensor.py", line 59, in is_on
and beta > current
File "/usr/local/lib/python3.9/site-packages/awesomeversion/awesomeversion.py", line 164, in __gt__
return self.string != compareto.string and self._compare_versions(
File "/usr/local/lib/python3.9/site-packages/awesomeversion/awesomeversion.py", line 201, in _compare_versions
result = handler(AwesomeVersion(version_a), AwesomeVersion(version_b))
File "/usr/local/lib/python3.9/site-packages/awesomeversion/comparehandlers/modifier.py", line 28, in compare_handler_semver_modifier
SEMVER_MODIFIER_MAP[version_a.modifier_type]
KeyError: 'b'
same issue which is blocking any automation with wled service calls. Don't have much more to add, same build as OP.
I'm getting the same error printed every 10 seconds in my Home Assistant log.
Please consider raising this issue at https://github.com/home-assistant/core too
Found the issue, it is caused by 0.13.2-a0
as the version number, which is not a valid versioning identifier. This is not a Home Assistant issue, but WLED not using general versioning standards. Not much I can do about that from an Home Assistant perspective.
general versioning standards
Would this suffice?
Alphanumeric suffix is a common scheme adopted by semantic versioning. In this scheme, versions have affixed a dash plus some alphanumeric characters to indicate the status.
@blazoncek 🤷 Its not working with the Semver schema as it seems. The error can be handled nicer (for which an issue now is open @ awesomeversion to not throw a key error), but that would not fix the version number.
Anyways, if the version isn't matching Semver (or another standard), it will simply not be possible to compare versions and thus handle updates and/or backward compatibility with older WLED versions.
Could you just trim after the third digit?
Could you just trim after the third digit?
That is making assumptions on an upstream version number, which sounds odd to do.
That is making assumptions on an upstream version number, which sounds odd to do.
But you said it should follow standards and first three digits (actually I meant numbers) are considered standard. Now I do not understand what assumptions are you referring to.
Ok... sorry to hear that, let me try again: the version number doesn't fit any common version scheme specification and that causes issues.
Nothing more nothing less.
Well, let's first clarify something. There is no common standard in the software industry for versioning. Every vendor does it differently. You will find "semantic versioning" which uses real words. And you will find versions with several dots and letters, like "01.02.07.fm4-launch1.b200".
It would be nice to know what your specific "common version scheme specification" looks like, so we could try to get WLED working in HA. We might find a way to deliver what HA expects, however I doubt that WLED itself will adopt something completely different just to satisfy HA needs.
There is no common standard in the software industry for versioning
? Have you been under some kind of rock? Buildver? calver? semver? Simver? PEP440?
We might find a way to deliver what HA expects
Anything listed above will do just fine (even mixed) and will be version comparable with tons of tools out there.
however I doubt that WLED itself will adopt something completely different just to satisfy HA needs.
Then it will keep throwing errors for alpha's 🤷
As a matter of fact, I've discussed the issue of unknown versioning (e.g., in forks or custom builds) with Aircoookie before implementation and we decided to make it the problem of the forks/custom builds and just ignore those. I guess this makes this issue in the exact same category.
If I have to choose between that or having to remove things like backward compatibility and firmware upgrades, I will definitely choose the errors happening on alphas.
Considering your last part of the response (doubting of adjustment), I'll adjust the documentation to list this error as a known issue/limitation caused by WLEDs versioning.
Hey no reason to be insulting. I'm not asking if you spent your life in dreamlead, did I?
Hey no reason to be insulting.
It wasn't meant insulting, there is no nicer way to put it 🤷 The fact is that there are many versioning schemes out there. Like it or not.
i like it. And still no idea what you ask for. Just heard buzzwords not content.
And still no idea what you ask for.
I don't ask for anything. I've just reported back the root cause of the issue and why it is happening, but looking back at the responses to that, I guess I should have not. I'll skip similar next issue reports for my own well-being.
Just heard buzzwords not content.
ok. Good luck with the issue.
I still do not get it @frenck, why do you insist WLED is not following SemVer or the standards as defined by Wikipedia?
This is clearly not a WLED issue.
This is clearly not a WLED issue.
It also not an issue I can fix on my end, as its not parsable as a common version pattern, which is used for things mentioned earlier.
As said: If I have to choose between that or having to remove things like backward compatibility and firmware upgrades, I will definitely choose the errors happening on alphas.
WLED supports SemVer 2.0.0 even in beta versions. If this is still problem please open an issue in HomeAssistant repository.