So the code is just for one-way sending of messages. There is no publishing, only subscribing. I have a Sense Energy Monitor that tells me when my devices turn on and off. No device control.
This takes the MQTT message from Home Assistant with the Sense component and send the ON/OFF status of my Sense devices.
The payload message is: OFF or ON.
Sample Home Assistant Automation code to control the MQTT messages to Hubitat
- id: '1562365442134'
alias: Freezer Publish Off
trigger:
- entity_id: binary_sensor.freezer
from: 'on'
platform: state
to: 'off'
condition: []
action:
- data:
payload: 'OFF'
retain: 'true'
topic: /home/freezer/state
service: mqtt.publish
- id: '1562371629250'
alias: Freezer Publish ON
trigger:
- entity_id: binary_sensor.freezer
from: 'off'
platform: state
to: 'on'
condition: []
action:
- data:
payload: 'ON'
retain: 'true'
topic: /home/freezer/state
service: mqtt.publish
Is there a post or thread about this anywhere? I was thinking about writing a Home Assistant component myself (a component seems like the best way--it's what their ST integration uses, but with their new cloud API), but I would much rather use or contribute to another if that is the case.
Is anyone able to successfully have multiple distinct MQTT devices connected to the same queue? I am seeing lots of disconnects - "Error: Connection lost: Connection lost". Wondering if there is only one MQTT connection behind the scenes and the multiple devices are fighting for the channel.
Looks like they needed unique clientid's, which makes sense. Mosquitto was doing this as four different clients w/ the same client id were connecting and reconnecting:
New connection from XX on port 1883 Client hubitat already connected, closing old connection
Are you saying that multiple connections to MQTT are being made by my MQTT HE app using the same clientID ?? This would of course cause problems but I only use one broker connection for all devices, publish topics and subscriptions so this shouldn't happen.
... Or are you saying you were connecting your own external 'distinct devices' to the MQTT broker using the same clientID's, which also wouldn't work ...and so you've now fixed your devices clientID's to be unique ?
Hi
I have an Arduino (WeMosD1mini) sketch for my Garage with a 'smart' relay (on/off - not toggle), and two GarageDoorSensors
GaragePortSensor1 - triggers when the door is fully closed (0/1)
GaragePortSensor2 - triggers when the door is fully open (0/1)
The sensors are picked up by the MQTT Client, and shows up correctly in Hubitat.
How can I program a GarageTile so that it shows correctly even if I use the physical switch or the key-chain remote on the garage-system not connected to Hubitat?
I'd like to pick up the sensor data (closed), and have the tile turn green, and vice-versa - automatically.
I also have a temp-probe on the Arduino. How can I have this show up on a Tile.
In MQTT I can name the sensors whatever I choose, it that is of any help.
But I am getting errors due to the "true." Based on documentation this should be the retained option boolean of true/false but I get this error in my logs:
dev:28712019-09-11 08:51:29.181 am errorgroovy.lang.MissingMethodException: No signature of method: hubitat.helper.interfaces.Mqtt.publish() is applicable for argument types: (java.lang.String, java.lang.String, java.lang.Boolean) values: [wardhome/salt-tank/delay, 1, true]
You are missing a parameter, there are 4 parameters for that call: void publish(String topic, String payload, int qos = 1, boolean retained = false)
1 - topic
2 - payload
3 - qos
4 - retained
The last 2 are defaults, so if you leave them off they default to 1 and false.. but if you want to change the 4th parameter you also have to pass the 3rd parameter
For the uninitiated in MQTT, can someone layout the use case for having this? I stumbled across a project where someone made his "dumb" tv smart by connecting it to a raspberrypi via hmdi-cec and MQTT. He used it to turn the TV on/off, change the input and do cool things like using Alexa voice commands to switch the tv input to show his front door camera. I was investigating how to accomplish something like that - which brought me here.
I have a hubitat hub, a raspberrypi 4 and an ancient (by todays standards) Panasonic TV which supports hdmi-cec with its veira link feature.
Has anyone done something similar here? What other use cases does this present? I am confused by why folks are using mqtt to connect to other hubs.
MQTT is a great IoT protocol that uses topics. A lot of the DIY smarthome environments have gone down this path verses direct proprietary protocols such as Zwave, Zigbee and even Wifi (perse').
I used this for my Salt Tank project using an arduino WeMo D1 and a Ultrasonic Sensor.
The biggest benefit to MQTT is speed. All devices listening on a topic receive the message at the same time. For lights this eliminates the popcorn affect the other protocols suffer from as all the lights receive the message to do something and they do it at the exact same time.
If you do some simple YouTube searches for "MQTT Smarthome projects" you will see a ton of great IoT solutions to 1st world problems that are significantly cheaper OR don't exist as a solution today.
To get started you will need an MQTT broker installed on a RPi. This is the "hub" of the MQTT messages. Once this is done install a MQTT Explorer to see what is going on in the MQTT hub. Probably not much without a client BUT with the tutorial I sent you above you can goof around and begin to understand the use cases.
I can't answer your question on what/how to do it on your TV.
But in general MQTT is valuable for connecting data from dissimilar systems together - without having to use a proprietary API/interface on each system type. It provides a standard messaging protocol so that regardless how an individual system works internally, if they support MQTT messaging, they can share (and receive) data from other systems in a very fast, efficient, secure, and low overhead way.
Iām controlling my Panasonic TV with hmdi-cec but itās convoluted I send commands from Hubitat to a Apache server running on a Raspberry Pi which runs a python script. I will probably be switching to MQTT and using Node-Red. Using these nodes node-red-contrib-viera - Node-RED and node-red-contrib-cec - Node-RED.
While MQTT is great, I must defend Zigbee: it supports group messaging, which usually also eliminates the "popcorn effect." But that's only part of the story. Most (maybe all? I haven't used a lot but all I have do) Zigbee bulbs support scene clusters, and each bulb remembers it setting for a scene, which can also be recalled with one command. This is what what makes Hue scenes so fast (a recent Bridge update might have changed this, but traditionally, accessories like the Tap and Dimmer have just broadcast this command and the bulbs would immediately respond--they knew what to do--without Bridge communication being necessary) and Hubitat scenes sometimes a bit slow (the hub is emulating this, bless its little heart, with individual commands to each bulb for things like color and level). Theoretically, MQTT could do this too (broadcast a command like "activate scene 28"), but I'm not aware of any bulbs or lighting systems that support this.
In other words, Zigbee handles this quite well, and the "popcorn" effect has nothing to do with the protocol. (It's also not proprietary; it's an IEEE specification. Anyone can make a proprietary profile on top of the standard protocol, but most devices people here use are ZHA 1.2 or Zigbee 3.0 using the standard clusters and whatnot as intended. Z-Wave is a similar story. Wi-Fi is...a mess beyond the fact the protocol itself is standardized, which helps in no way with how people actually use it for devices.)
(Z-Wave might have something similar; I know nothing about Z-Wave bulbs except that color implementation is generally a mess, and I have low hopes for the rest so I'd doubt it.)
Yes you are correct. If someone invests in a homogeneous Zigbee 3.0 enabled network it is about the same. BUT that isnāt the case with many people such as myself. Using low cost solutions like Shelly, Tasmota, SonOff devices that are MQTT enabled actually provide a lower cost but more robust solution over the standard Zigbee and other proprietary (which Zigbee is even though it is an open protocol) systems.
