@tpc77 Here is the info that you wanted. I want to thank you for looking at this and if you need any further info please ask.
and the Event Subscriptions.
and the Event Subscriptions.
@leeonestop from what you've shared so far, the bulb in MQTT Link appears to be configured correctly. For whatever reason, the messages aren't getting to the app.
Let me dig around to see if there is anything else that can be checked.
Chiming in... Thanks for publishing this. I'm a longtime ST user (from v1 hub days) who just jumped ship to Hubitat. I had ST talking to Home Assistant through MQTT (using the stock Mosquitto broker) and the ST bridge, and also have other devices like cheap temp sensors reporting into Hass via MQTT. So I'd prefer to add HE to the MQTT mix instead of getting involved with the Maker API to get HE and Hass talking.
Some quick observations from tinkering for a few days with debug enabled for driver and app, and monitoring traffic in mqtt-spy...
-
The app seems to open 5 sequential connections to the broker, within ms of each other, at each 60-second state refresh interval. The same topics (FW, IP, UPTIME, etc. plus device states) are published during each connection. An HE log entry is made for each connection even with debug off, which gets pretty chatty.
-
Devices selected in the MQTT Link app reliably report state to the broker.
-
Sending payloads back to MQTT Link is problematic. I was able to get it to work for only one device, a switch. It didn't work for another identical switch configured at the same time. First I tried sending payloads via the Hass UI, watched traffic in mqtt-spy, then sent payloads directly from mqtt-spy to confirm that they were formatted correctly and matched existing topics. In HE logs, "incoming target action"s were detected for the working device but not the other.
-
The driver seems to be sending ghost "incoming target action"s to the app during each connection. I'm currently seeing what appear to be two incoming payloads for different topics/devices being picked up by mqttLinkHandler in the HE log, in each of the 5 connections during a 60-second refresh. I never sent those payloads and they seem to be echoing the current state of each device. I'm wondering if this is related to Mosquitto's LWT behavior.
I would love to get this working and don't think I made any boneheaded mistakes. If you have time to troubleshoot/debug, please let me know which logs would be most useful.
@mwh thank you for the detailed analysis. I wonder if the third issue is the same one that is causing issues for leeonestop.
I will take a look at each of these next week when I have time off from work to see if I can make some improvements that will help everyone. Btw, if you are familiar with coding and happen to identify / correct any of these issues before I do, I would gladly accept pull requests.
Quick question..did I miss something along the way ?
just a simple IMO
I started with Wink, move to ST and then to HA a few years back. I've loved HA, but home automation area is getting more complex and truly scalable from just simple you must purchase these z-devices.
So I took the leap (I'm sure like many of you to Node-Red and Hassio) because I needed to some things HA couldn't. It's been years since I looked at HASSIO or OpenHAB. So I get HA working with Node-Red, and I install HASSIO Pi and get that all setup. I needed to levage the mosquitto pentair pool MQTT app in HASSIO. It does what I need it to do posting device status and pulling commands.
After using the Node-Red HA palette integration I'm left wondering why HA can't simply write a service app that allows us select which devices we want to expose to MQTT and have it write/read the values using the standardized home automation MQTT format. HASSIO is now very very powerful. So much I'm now thinking about dumping HA and just migrating. I really don't want to do that as I love the stability and simplicity of HA.
Can't we get a hubitat/location/device/type/attributes MQTT message out of HA for select devices? without major groovy custom app and device drivers?
What am I missing?
@gnvdude I have come to know HA to mean Home Assistant. Similarly, I've come to know HE as being short for Hubitat Elevation. So, I was having difficulty interpreting your post and have to assume that when you say HA you are actually referring to the Hubitat hub.
With that said, you asked the following:
why HA can't simply write a service app that allows us select which devices we want to expose to MQTT
That is the million dollar question that only the Hubitat team can answer. In the meantime, MQTT Link and others offerings, such as the one from @kevin, were created to bridge the gap.
If you're looking for something that's a bit more turn-key, check out the Hubitat integration in HACS for Home Assistant which leverages Hubitat's Maker API for communications.
I’m also having a little bit of confusion about when you might mean HA and when you mean HE. Anyway taking this as written this seems to be a question better suited for the HA forum rather than here on HE ...
A couple of comments.. there is no ‘standardised home automation MQTT format’ but Home Assistant promote their own for import discovery (not export / publish). OpenHAB supports this too. I think that is your question .. why don’t they publish too ? Additionally OpenHAB promote ‘homie’ as an MQTT offering but again they import but don’t publish in that format.
My MQTT app and AFAIK MQTT Link will allow almost any HE device to be published to MQTT. I leverage both the homie standard and the home assistant standard so devices can automatically be discovered by both OpenHAB or HomeAssistant or any other app supporting those standards.
For discovery into HE I support the homie standard and also the homeassistant statestream publish output to MQTT (this is because HA lacks the output support for MQTT discovery as you mention). You can also support any custom MQTT topic for input/output to HE.
Does that help or am I misunderstanding your question perhaps ?
I put in a PR to fix the mqtt connection issues and excessive logging: Fix spurious connected messages by DTTerastar · Pull Request #2 · mydevbox/hubitat-mqtt-link · GitHub
1 Like
Yup just read up on the Hubitat HACS integration looks exactly like what I want
I think I am seeing the same issue as @leeonestop and @mwh.
I can't get a virtual motion sensor to go active / inactive but can get a virtual switch to turn on / off.
When I turn the virtual sensor active / inactive in the device, I see the topic listed, showing the state in MQTT Explorer. If I publish back to HE a status change motion active or inactive the device state doesn't change in HE. However if I try the same with a virtual switch it turns on and off in HE.
If there is any info I can provide, please let me know.
Thanks. 
I just try and got virtual motion to work? You probably doing this already but make sure in the MQTT link app that you have the motion set correctly? publish again in the MQTT explorer also make sure your adding motion to end of the topic? Hope it help.
hubitat/hubitat-test-hub-hub-000d/test-motion-354 should be
hubitat/hubitat-test-hub-hub-000d/test-motion-354/motion
I believe I have it set-up correctly. 
Both the switch (that works) and the motion sensor (which doesn't) are set-up in a similar manner except for device types. My topic for the motion sensor is hubitat/home-hub-000d/indigo-motion-02-169/motion and the payload is inactive or active. The topic for the switch is hubitat/home-hub-000d/he-switch-02-200/switch with a payload of on or off. I have turned on debugging but can't see any evidence the motion sensor message is getting through.
If I alter either device in HE, then this is reflected in MQTT Explorer.
There is obviously something wrong with my set-up or I haven't set an option correctly. I can't see it at the moment. 
Make sure in the device page and check the driver that you are using? I'm using this one. Are you using a Virtual Motion sensor?
Yes, I am using a Virtual Motion Sensor.
When I publish an ON for the switch, I get this in the log:
dev:2002021-01-09 18:48:05.141 infoHE_SWITCH_02 is on
app:1002021-01-09 18:48:05.133 debug[mqttLinkHandler] MQTT incoming target action: [device:he-switch-02-200, type:switch, value:on, action:actionOnOff]
app:1002021-01-09 18:48:05.129 debug[mqttLinkHandler] Received inbound device event from MQTT Link Driver: [device:he-switch-02-200, type:switch, value:on]
dev:1682021-01-09 18:48:05.100 debug[parse] Received MQTT message: [topic:hubitat/home-hub-000d/he-switch-02-200/switch, payload:on]
I don't get anything when I do the equivalent publish for the motion sensor. I do detect this message in another system which has subscribed to it.
It is almost as if, the topic isn't being subscribed to in HE?
Can you check and make sure that your is showing in the MQTT Link app? Then go to next page and make sure that you topic is set correctly and matches what MQTT Explorer has which it should be the same exept you have to add motion on the end of the topic line in Mqtt explorer?
Apologies for the delay in replying: Yes, it all checks out OK AFAICS.
I tried something else based on my theory that there is no subscription for the message which is why it isn't being received.
I went to the MQTT Link device and entered "indigo-motion-02-169/motion" [no quotes] in the subscribe box and hit subscribe. I then published an "active" payload from MQTT Explorer which caused the following messages to appear in the HE log:
app:1002021-01-12 13:26:54.905 errorjava.lang.NullPointerException: Cannot get property 'attributes' on null object on line 855 (mqttLinkHandler)
app:1002021-01-12 13:26:54.852 debug[mqttLinkHandler] Received inbound device event from MQTT Link Driver: [device:indigo-motion-02-169, type:motion, value:active]
dev:1682021-01-12 13:26:54.821 debug[parse] Received MQTT message: [topic:hubitat/home-hub-000d/indigo-motion-02-169/motion, payload:active]
dev:1682021-01-12 13:26:33.997 debug[subscribe] full topic: hubitat/home-hub-000d/indigo-motion-02-169/motion
It didn't work but at least the incoming message is now being picked up.
Hopefully this might shed some light on what is happening? 
I think at this point if it was me, I would restart from the beginning? I would uninstall the devices and uninstall mqtt link, then reboot the hub and reinstall mqtt link and redo the sensors see if that helps? I only have a couple of items in mqtt link don't know how many you have. I would at least uninstall the sensors in mqtt link and redo the one that I was having the issues with and see if that helps.
I have done a soft reset of the Hub. Installed the MQTT Link driver and App. I added in two virtual devices: Motion Sensor and Switch.
So the MQTT Link Driver Device and two virtual devices are the only devices defined. MQTT Link is the only App.
The Switch responds to incoming MQTT messages but the Motion Sensor still doesn't. Both devices send out MQTT messages if they are changed.
I am now at a loss as to why this doesn't work.
I still think the issue is that that incoming MQTT messages for a Virtual Motion Sensor aren't being subscribed for. I wonder if there is a setting that you have to enable to allow a Virtual Motion Sensor to be modified via MQTT?
