Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
1 task done
Plawasan opened this issue Apr 3, 2022 · 22 comments
Closed
1 task done

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

Plawasan opened this issue Apr 3, 2022 · 22 comments
Labels
external Not part of WLED itself - an external plugin/remote etc.

Comments

@Plawasan
Copy link

Plawasan commented Apr 3, 2022

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

  • I agree to follow this project's Code of Conduct
@Plawasan Plawasan added the bug label Apr 3, 2022
@Aircoookie Aircoookie added the external Not part of WLED itself - an external plugin/remote etc. label Apr 3, 2022
@Aircoookie
Copy link
Owner

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?

@Plawasan
Copy link
Author

Plawasan commented Apr 3, 2022

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

@jaredguiles
Copy link

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'

@addd45
Copy link

addd45 commented Apr 15, 2022

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

@fraser-mendeco
Copy link

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

@Aircoookie
Copy link
Owner

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

@frenck
Copy link

frenck commented Jul 18, 2022

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.

@blazoncek
Copy link
Collaborator

blazoncek commented Jul 18, 2022

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.

@frenck
Copy link

frenck commented Jul 18, 2022

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

@blazoncek
Copy link
Collaborator

Could you just trim after the third digit?

@frenck
Copy link

frenck commented Jul 18, 2022

Could you just trim after the third digit?

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

@blazoncek
Copy link
Collaborator

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.

@frenck
Copy link

frenck commented Jul 19, 2022

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.

@softhack007
Copy link
Collaborator

softhack007 commented Jul 19, 2022

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.

@frenck
Copy link

frenck commented Jul 19, 2022

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.

@softhack007
Copy link
Collaborator

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

@frenck
Copy link

frenck commented Jul 19, 2022

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.

@softhack007
Copy link
Collaborator

softhack007 commented Jul 19, 2022

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

@frenck
Copy link

frenck commented Jul 19, 2022

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.

@blazoncek
Copy link
Collaborator

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.

@frenck
Copy link

frenck commented Jul 19, 2022

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.

@blazoncek
Copy link
Collaborator

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

@blazoncek blazoncek closed this as not planned Won't fix, can't repro, duplicate, stale Dec 31, 2023
@blazoncek blazoncek removed the bug label Dec 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external Not part of WLED itself - an external plugin/remote etc.
Projects
None yet
Development

No branches or pull requests

8 participants