Local python service MQTT vs REST communication

Apps & Services 3rd Party
, ,
21

you are absolutely right. TCP and MQTT and so on are for sure way more future-proof than domain sockets.

TCP just forced me to shift some of my logic to my service, because that logic is really timing-critical and does not allow for any delays caused by MQTT.

22

I finally tried homie, and i am slighty confused.
If i have, for instance, a ringer, which is configured as a contact in openhab,
how does homies “true/false” for a switch work together with openhabs “ON/OFF/OPEN/CLOSED” for switches/contacts?

23

That’s the reason why there is a binding :wink: It performs all those mappings transparently for you.

24

thanks for the answer.
What binding do you mean? The MQTT binding? I am somehow unable to find a binding that transforms those values by itself


25

The MQTT binding exactly. It consists of 3 bundles that are all installed at once, and one is the Homie MQTT part. It works for auto-discovered things only, of course. That’s the entire purpose of Homie.

26

thanks, that is exactly what i have been searching for.

Is there a reason sending a command to a homie-item does not update its state?
And even manually updating its state through a rule does change its state,
it does not trigger a MQTT publish though.

As far as i can judge a homie-thing is read-only so far


27

Maybe my items are not writable because the items themselves are switches, yet the homie property is configured as a contact.

Although the homie type looks like that: “homie/bleio-dfb3a20fa00c/contact/$type contact”, it is recognized by openhab as a switch.

When linking the channel to a Contact regardless i get the following error: “Command ‘CLOSED’ not supported by type ‘OnOffValue’: No enum constant org.eclipse.smarthome.core.library.types.OnOffType.CLOSED”

28


 is not specified. Only $datatype. And OH also only use that one, so if your data is a boolean, openHAB will create a switch channel. If $settable=false it will create a read-only switch channel.

A “sensor contact” cannot be expressed by Homie yet, because we would indeed need to specify valid values for $type, which did not yet happen in the Homie Spec Group.