Closed cyberkeiler closed 7 years ago
I see what you did there.
We have a fundamental difference in perceiving the messages. The current revision is sending events (as stated in the topic's name), i.e. whenever something changes, a message is sent with the meaning "the state switched to XY just now", whereas your change induces a (savable) state in the sense of "that's what it is currently".
I believe we should have both (and agree on a scheme to distinguish states from events).
I tend to not accept the pull request just now. Please change so that you code is an addition to the existing code, i.e. add the topics Netz39/Things/Door/State and Netz39/Things/DoorLock/State or something alike and keep the topic Netz39/Things/Door/Events.
In general: When changing established topics, all agents which use them must be adapted, too.
On other thing: Do not push directly on master - that branch should be for merges and really quick fixes only.
Please open a feature branch and create the pull request from there. This way the addition can be properly documented in the history.
I'm closing the request for now, but I'd be happy to hear from you again. I like the idea. Ask me if you need help in setting up the next pull request.
With this, my first pull request I just want to try creating a pull request and at the same time like to start a discussion about publishing the door states as two individual MQTT-topics:
Advantage is the easy resolution of the current states compared to the method, publishing all events on a single topic. Yes, the Events are (in normal operation - without failure of components or manipulation) "conditional" to each other (Door locked <-> Door unlocked/Door closed <-> Door open), but nevertheless there is some logic necessary to get to the states. (this is currently done by this rule )
Details: The naming of the state / MQTT-payload equals to the states of an openHAB Contact Item: "OPEN" and "CLOSED" ( A Contact is a read-only two state sensor. ) So it can be integrated without further transformation.
The Event-Topic is overwritten in this implementation, since I don't know about another subscriber than openHAB. Of course there are a few use cases, where a Event-Topic gets handy, so if its needed just tell me ;)