Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Discussion: How to handle device specific quirks #1576

Closed
marcelveldt opened this issue Feb 3, 2021 · 9 comments
Closed

Discussion: How to handle device specific quirks #1576

marcelveldt opened this issue Feb 3, 2021 · 9 comments
Labels
enhancement New feature or request

Comments

@marcelveldt
Copy link

Any ideas how to handle devices that do not follow standards exactly ?
For example some Fan devices report themselves as Multilevel Switch (=light)

I've also seen reports for devices providing something in the manufacturer specific.

We (home assistant integration) could handle these quirks one-by-one in our code, and every other client utilizing this library but maybe we can come up with something more universal such as a quirks database which handles:

  • Mapping of a device to another deviceclass
  • Give hints about it's values and commandclasses to connected applications

We could then all utilize this quirks database (which could be as simple as a json file) to incorporate these manufacturer specific instructions.

@marcelveldt marcelveldt added the enhancement New feature or request label Feb 3, 2021
@robertsLando
Copy link
Member

On my side I keep a sort of db to handle this cases, but most times this can be guessed by checking the deviceClass

@marcelveldt
Copy link
Author

example: home-assistant/core#45703

@AlCalzone
Copy link
Member

I think the correct behavior depends on the specific quirk. Some can be influenced with compat flags, some (like treating a Multilevel Switch as a Fan Controller) should probably not be handled on the driver level.

I'm planning to separate the (currently included) application layer into a separate module some time in the future, so that is a place where such quirks could be handled.

@scott7685
Copy link

just a note I found this issue today -- I have a GE / Jasco 12730 that was coming through via ZWaveJS2MQTT correctly into HASS as a fan.device, however when I use the ZWaveJS web socket integration in HASS pointing to the same ZWaveJS2MQTT docker that device comes through as a light.dimmer

@jcam
Copy link
Contributor

jcam commented Feb 4, 2021

@marcelveldt perhaps instead of trying to maintain a database of these devices, it would be enough to give users the option to override the device type? this could also work for the fibaro RGBW dimmer that reports itself as a multilevel switch instead of a color light

@marcelveldt
Copy link
Author

Yeah, but maybe do this in a centralized manner so all consumers of the Z-Wave JS project can benefit.

@AlCalzone
Copy link
Member

this could also work for the fibaro RGBW dimmer that reports itself as a multilevel switch

To be fair, you can (mis-)use it as a 4-channel multilevel switch. I've done that already 😬

@jcam
Copy link
Contributor

jcam commented Feb 4, 2021

this could also work for the fibaro RGBW dimmer that reports itself as a multilevel switch

To be fair, you can (mis-)use it as a 4-channel multilevel switch. I've done that already 😬

This is actually an officially supported use, documented in the manual.
I think there are parameters to set it to send RGBW reports instead of multilevel reports, but that won't change the announced device class as far as i know (and i think is not why it's detected as a 4 channel switch)

@blhoward2
Copy link
Collaborator

just a note I found this issue today -- I have a GE / Jasco 12730 that was coming through via ZWaveJS2MQTT correctly into HASS as a fan.device, however when I use the ZWaveJS web socket integration in HASS pointing to the same ZWaveJS2MQTT docker that device comes through as a light.dimmer

This would need to be reported on the integration's project. That is happening on their end.

@zwave-js zwave-js locked and limited conversation to collaborators Oct 19, 2023
@AlCalzone AlCalzone converted this issue into discussion #6431 Oct 19, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants