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

Some sensor enities have been changed to buttons #129150

Open
Dust-E opened this issue Oct 25, 2024 · 11 comments
Open

Some sensor enities have been changed to buttons #129150

Dust-E opened this issue Oct 25, 2024 · 11 comments

Comments

@Dust-E
Copy link

Dust-E commented Oct 25, 2024

The problem

Some sensor enities have been changed to buttons in the Z-Wave intergration

Currently, I see this with the according devices:

Carbon monoxide FireAngel
Heat Detector FireAngel
Smoke Detectors FireAngel ZST-630
Fibaro Dimmer 2
Fibaro Motion Sensor

When this happened I dare not say but I suspect 1 to 2 months ago

Below some screenshots as an example of:
Smoke Detector Attic hall

image

sensor.smoke_detector_attic_hall_smoke_alarm_alarm_status
I am now missing the Atrributes of the sensor enitities
image

button.smoke_detector_attic_hall_idle_alarm_status
image

What version of Home Assistant Core has the issue?

core-2024.10.3

What was the last working version of Home Assistant Core?

core-2024.7.0 I think

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Z-Wave JS

Link to integration documentation on our website

https://www.home-assistant.io/integrations/zwave_js

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

@home-assistant
Copy link

Hey there @home-assistant/z-wave, mind taking a look at this issue as it has been labeled with an integration (zwave_js) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of zwave_js can trigger bot actions by commenting:

  • @home-assistant close Closes the issue.
  • @home-assistant rename Awesome new title Renames the issue.
  • @home-assistant reopen Reopen the issue.
  • @home-assistant unassign zwave_js Removes the current integration label and assignees on the issue, add the integration domain after the command.
  • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
  • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

(message by CodeOwnersMention)


zwave_js documentation
zwave_js source
(message by IssueLinks)

@AlCalzone
Copy link
Contributor

The buttons reset the corresponding sensor back to idle. They are not a replacement for sensors, and they have existed for months.

@kpine
Copy link
Contributor

kpine commented Oct 26, 2024

Those notification sensors were removed in 2024.10 (#125326), but it was not announced.

You can migrate to using the binary_sensors which are actually quite visible in the screenshot. There should be a couple of others in the Diagnostics panel, like for the cover removed sensor.

@Dust-E
Copy link
Author

Dust-E commented Oct 26, 2024

2 of them are indeed in the Diagnostics panel

image

@patrick-reijnen
Copy link

Same here, since update from core-2024.09.x to core 2024.10.4 yesterday. For me at least for Fibaro CO and Smoke sensors. Haven't checked others yet.

The lack of notification of this change is painful, as is the apparent lack of documentation how to solve issues. A bunch of automations, based on attribute values simply do not work anymore, and the buttons to be pressed result in litterally nothing? At least nothing I can detect visuallly or by looking up status of sensors .....

@Dust-E
Copy link
Author

Dust-E commented Oct 27, 2024

@patrick-reijnen
I feel the same pain but in the end I think this is better because you can make automations easier without having to write those attributes in your automation. So you no longer have attributes but an 'OK' or 'Problem'.
It is indeed some work to do it all over again.

@AlCalzone
Copy link
Contributor

I don't know why the change wasn't announced, but I can at least clear up this confusion:

the buttons to be pressed result in litterally nothing

If the corresponding sensor is not idle, then pressing the button will reset it back to idle. This can be useful if the sensor got stuck in a wrong state, e.g. because the device didn't send the idle command itself.
For example if the smoke alarm claims there is smoke when there is clearly none, pressing the "Idle Smoke Alarm - Alarm Status" button will reset the sensor back to "no smoke".

@patrick-reijnen
Copy link

patrick-reijnen commented Oct 28, 2024

I don't know why the change wasn't announced, but I can at least clear up this confusion:

the buttons to be pressed result in litterally nothing

If the corresponding sensor is not idle, then pressing the button will reset it back to idle. This can be useful if the sensor got stuck in a wrong state, e.g. because the device didn't send the idle command itself. For example if the smoke alarm claims there is smoke when there is clearly none, pressing the "Idle Smoke Alarm - Alarm Status" button will reset the sensor back to "no smoke".

I'll get that point.

What I'm bumping my head into now, is that I have used the test attributes of Fibaro CO and Smoke sensors to automate and test a setup in which, at the moment one of the sensors fires, lights go on and music in house starts as additional visible and audible alarms to wake up everybody.

For production setup (real fire or CO) the attributes are still available and seem to work, but my test setup is no longer working and I'm trying to find out, at no success sofar, what I should replace "binary_sensor.overloop_1ste_co_sensor_co_alarm_carbon_monoxide_test" (for the CO sensor as example) with to find out that I somewhere manually initiated a test of a CO or Smoke sensor, thus getting lights and music started again.
It looks like there is no replacement for the test attributes ... ??

@AlCalzone
Copy link
Contributor

Can you share the node diagnostics?

@kpine
Copy link
Contributor

kpine commented Oct 28, 2024

The integration provides a "test" binary_sensor entity, which is shown in the OP's screenshot. The change mentioned here does not remove that. If you don't have a test binary entity then you have a different issue. I'd suggest posting the Device diagnostic in that case.

@patrick-reijnen
Copy link

patrick-reijnen commented Oct 29, 2024

Right ... Was able to go one step forward. As I wasn't seeing the binary_sensor test_status, using the Zwave Control Panel I've re-interviewed the CO node, which actually resulted in the binary sensor test_status popping up in HA.
It being a binary sensor still s..ks though. When I manually trigger the CO sensor for a test by pushing its button, state of the binary sensor nicely switches to On / Detected, which I can use to fire off the automation. The CO node itself hoewever never automatically returns the state to Off / Undetected and there is no button in HA to reset the test_status to Idle / Off / Undetected. As it seems not possible to create an automation to switch state of a binary sensor, I'm not stuck to going into UI mode (Development Tools) to switch its status to off everytime I run a test. Sofar for real automation of my test setup.
Any ideas to solve this, as I'm not expecting the former sensor entities to return?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants