search

snowdd1 / homebridge-knx

KNX platform shim for homebridge
https://github.com/nfarina/homebridge
GNU General Public License v2.0
97 stars 55 forks source link

New Option for "Listen" group addresses to opt-out of "Response" type telegrams #76

Open snowdd1 opened 7 years ago

snowdd1 commented 7 years ago

In case you want to trigger an action with the Listen address, you probably do not want to trigger it upon responses coming from answers to Read type telegrams, especially if the READ telegram was sent by another bus client, and not homebridge-knx.

snowdd1 commented 7 years ago

Does anybody want to have that?

matevzg commented 7 years ago

If you want to trigger an action you do a write to a GA. What's an example use case for triggering based on read telegrams?

snowdd1 commented 7 years ago

Sorry, I might have expressed unclearly:
Not the Read Telegram is the trigger, but the Answer Telegram. Example: My GIRA homeserver sends a READ every X minutes to my gas boiler to get the current temperature of the floor heating water. The answer of the boiler is an ANSWER telegram, that is processed in homebridge-knx just as an WRITE telegram. (See here)

I was just thinking about cases in which you want an action based on WRITE but not on ANSWER.

I could think of a door contact that is polled regularly by an alarm device (READ --> ANSWER) to check for tampering and such, and that is actually sending an active WRITE on status changes.

matevzg commented 7 years ago

I get it now. And yes, for completeness sake, replies (answers) should definitely be handled differently than direct status change writes.

In case of HomeKit automations this situation would screw up any automation that is based on accessory control - i.e. 'do this, when this happens' - if answers are treated the same as writes.