search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.9k stars 503 forks source link

DDF add support for HEIMAN IR control HS2IRC #7860

Open Smanar opened 3 months ago

Smanar commented 3 months ago

Product name : IR control HS2IRC Manufacturer : HEIMAN Model identifier : HS2IRC

See https://github.com/dresden-elektronik/deconz-rest-plugin/issues/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 

    config/learnkey
    config/sendkey

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

github-actions[bot] commented 3 months ago

Hey @Smanar, thanks for your pull request!

[!TIP] Modified bundles can be downloaded here. Relative expire date

DDB changes

Modified

Validation

[!TIP] Everything is fine !

:clock8: Updated for commit 5b0a3d8df0d19a12894c89dd59ead368c936346a

Idaho947 commented 2 months ago

Hello, possible to put this PR in the next release ?

manup commented 1 month ago

@Smanar @ebaauw @SwoopX I think we should be more explicit here on the device type. The ZHAControl seems to be too broad (controlling what and how?) isn't this just another ZHASwitch somehow?

Idaho947 commented 1 month ago

Maybe zhaIRcontrol because it s infra red remote ?

Idaho947 commented 1 month ago

Yes I confirm it is the first case. The device learn IR commande from device remote and can send it to control other device.

Smanar commented 1 month ago

I think we should be more explicit here on the device type. The ZHAControl seems to be too broad (controlling what and how?) isn't this just another ZHASwitch somehow?

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. Can use ZHAIRControl if you prefer ?

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.

Nope, only config, the only return usefull is the complete device list, but not set in the DDF.

SwoopX commented 1 month ago

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.

Idaho947 commented 1 month ago

So how can I help with this ?