DDF add support for HEIMAN IR control HS2IRC #7860
Conversation
|
Hey @Smanar, thanks for your pull request! Tip Modified bundles can be downloaded here. DDB changesModified
ValidationTip Everything is fine ! 🕗 Updated for commit 5b0a3d8 |
|
Hello, possible to put this PR in the next release ? |
|
Maybe zhaIRcontrol because it s infra red remote ? |
There was a problem hiding this comment.
I don't know the device. Is it a sender, used to control other devices over IR (replacing a traditional IR remote), or is it an IR receiver, used to control Zigbee devices by an IR remote? In the second case, it would be a variation on the ZHASwitch theme. In the first case it would be a different sensors type, cf. ZHAThermostat or, Heaven forbid, a lights resource.
Looking at the DDF, I think it's the first case, so a new sensors type seems justified. I have no idea if similar devices exist, let alone how we'd want to standardise the API to support these. Maybe ZHAIRControl (that reads weird) to indicate an IR controller? Shouldn't config/learnkey be a state attribute instead? Or is it used to put the IR controller into learning mode? The type template mandates a EDIT it's there, but I missed it because the items aren't sorted.state/lastupdated, but this is missing from the device DDF.
Does the device have a state that can be updated at all? If not, a lights resource would seem more natural (less unnatural, maybe). We do have Warning device with a write-only state.
|
Yes I confirm it is the first case. The device learn IR commande from device remote and can send it to control other device. |
In fact, it's exaclty for that I have choosed ZHAControl, it's generic enought to be used by other devices without the need to create a new one.
Nope, only |
|
I have to say, I'm absolutely no fan of introducing a new device type here, especially if that is just for one single device. We've had a comparable discussion once before on the measurement cluster, which would have introduced 32 (!) new device types with close to zero benefit. I really don't wanna be the party pooper here, but in my very personal view, the urge to squeeze everything into some boxes or categories has proven to be more cumbersome that actually beneficial. It more feels like putting artificial chains on the zoo out there just waiting to be ripped apart again 🙂 If you keep things generic, you can dance around quite a number of challenges and if devices would describe theirselves, this would be even more enchanting. On the other hand, we're having discussions about resource items presumably just used once for one specific device and if names are not carefully chosen, one cannot even dare to safely reuse them. Maybe that's the more important question, how to expose device functionality more easily and consistently? Just my 2 cents. |
|
So how can I help with this ? |
Product name : IR control HS2IRC
Manufacturer : HEIMAN
Model identifier : HS2IRC
See #7814.
For the moment the device work with a mix, API + GUI.
To add a device :
"Get list response" is still WIP.
Can use it with API using field
With data as form "x,y"
curl -H 'Content-Type: application/json' -X PUT -d '{"learnkey": "2.3"}' http://IP:PORT/api/KEY/sensors/ID/config