WLED icon indicating copy to clipboard operation
WLED copied to clipboard

HA Service call to WLED entities works but generates KeyError: 'b'

Open Plawasan opened this issue 2 years ago • 21 comments

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

Plawasan avatar Apr 03 '22 06:04 Plawasan

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?

Aircoookie avatar Apr 03 '22 08:04 Aircoookie

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?)

Plawasan avatar Apr 03 '22 10:04 Plawasan

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'

jaredguiles avatar Apr 06 '22 18:04 jaredguiles

same issue which is blocking any automation with wled service calls. Don't have much more to add, same build as OP.

addd45 avatar Apr 15 '22 21:04 addd45

I'm getting the same error printed every 10 seconds in my Home Assistant log.

fraser-mendeco avatar Apr 28 '22 11:04 fraser-mendeco

Please consider raising this issue at https://github.com/home-assistant/core too

Aircoookie avatar May 03 '22 09:05 Aircoookie

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.

frenck avatar Jul 18 '22 18:07 frenck

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 avatar Jul 18 '22 19:07 blazoncek

@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.

frenck avatar Jul 18 '22 20:07 frenck

Could you just trim after the third digit?

blazoncek avatar Jul 18 '22 20:07 blazoncek

Could you just trim after the third digit?

That is making assumptions on an upstream version number, which sounds odd to do.

frenck avatar Jul 18 '22 20:07 frenck

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.

blazoncek avatar Jul 19 '22 05:07 blazoncek

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.

frenck avatar Jul 19 '22 05:07 frenck

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.

softhack007 avatar Jul 19 '22 18:07 softhack007

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.

frenck avatar Jul 19 '22 18:07 frenck

Hey no reason to be insulting. I'm not asking if you spent your life in dreamlead, did I?

softhack007 avatar Jul 19 '22 19:07 softhack007

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.

frenck avatar Jul 19 '22 19:07 frenck

i like it. And still no idea what you ask for. Just heard buzzwords not content.

softhack007 avatar Jul 19 '22 19:07 softhack007

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.

frenck avatar Jul 19 '22 19:07 frenck

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.

blazoncek avatar Jul 19 '22 19:07 blazoncek

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.

frenck avatar Jul 19 '22 19:07 frenck

WLED supports SemVer 2.0.0 even in beta versions. If this is still problem please open an issue in HomeAssistant repository.

blazoncek avatar Dec 31 '23 09:12 blazoncek