Gotta love easy fixes 
Thanks for the quick update.
Just bear in mind, as mentioned in the HA thread I am going to have to change the DNI that HA created devices use (as HA allows duplicate device names).
As you're an 
alpha tester I can send you a 'pre beta 2' version that has these changes should you wish ?
Sure I'll take a look/test it out...
It's a slow day here at work
@kevin Trying to add the MQTT Client device and I keep getting this in the logs:
2020-01-29 07:48:26.270 pm infoMQTT> MQTT connect failed attempt:[null], try again in 10 secs
dev:19812020-01-29 07:48:25.269 pm infoMQTT> Connecting as Hubitat_temporary to MQTT broker null
dev:19812020-01-29 07:48:25.268 pm infoMQTT> MQTT> client beta 1 initialising
dev:19812020-01-29 07:48:20.057 pm errorjava.lang.NullPointerException: Cannot invoke method next() on null object on line 319 (heartbeat)
dev:19812020-01-29 07:48:20.031 pm debugMQTT> Tx: heartbeat [null] none
dev:19812020-01-29 07:48:15.262 pm infoMQTT> MQTT connect failed attempt:[null], try again in 10 secs
dev:19812020-01-29 07:48:14.259 pm infoMQTT> Connecting as Hubitat_temporary to MQTT broker null
It just sits there trying to create the device and loops with the above in the logs. Looks like its failing to connect to the broker but I haven't even had the device created to enter in the broker IP yet so i'm not sure what its trying to connect to on device creation? If I click out and go to devices i see the device i tried to create but when i enter the broker IP at this point it fails with the following:
2020-01-29 07:55:02.558 pm infoMQTT> MQTT connect failed attempt:[null], try again in 10 secs
dev:19812020-01-29 07:55:01.558 pm infoMQTT> Connecting as Hubitat_temporary to MQTT broker null
dev:19812020-01-29 07:55:01.556 pm infoMQTT> MQTT> client beta 1 initialising
dev:19812020-01-29 07:55:00.046 pm debugMQTT> Tx: heartbeat [4] none
dev:19812020-01-29 07:54:51.553 pm infoMQTT> MQTT connect failed attempt:[null], try again in 10 secs
dev:19812020-01-29 07:54:50.553 pm infoMQTT> Connecting as Hubitat_temporary to MQTT broker null
dev:19812020-01-29 07:54:50.551 pm infoMQTT> MQTT> client beta 1 initialising
dev:19812020-01-29 07:54:40.547 pm infoMQTT> MQTT connect failed attempt:[null], try again in 10 secs
dev:19812020-01-29 07:54:40.027 pm debugMQTT> Tx: heartbeat [3] none
dev:19812020-01-29 07:54:39.548 pm infoMQTT> Connecting as Hubitat_temporary to MQTT broker null
dev:19812020-01-29 07:54:39.546 pm infoMQTT> MQTT> client beta 1 initialising
dev:19812020-01-29 07:54:30.103 pm errorMQTT> MQTT message queue idle
dev:19812020-01-29 07:54:29.543 pm infoMQTT> MQTT connect failed attempt:[null], try again in 10 secs
dev:19812020-01-29 07:54:28.543 pm infoMQTT> Connecting as Hubitat_temporary to MQTT broker null
dev:19812020-01-29 07:54:28.540 pm infoMQTT> MQTT> client beta 1 initialising
Assuming you’ve entered the credentials correctly reboot your hub. It’s an issue with new installs which will be fixed in beta 2. Make sure you only have one MQTT client device created
I have published a new version of the MQTT Client driver that should fix this -- beta 1a
It has 2 new commands connect() and disconnect() and will no longer try and connect on install. Instead the app will now ask it to connect when started.
2 Likes
Thank you for adding MQTT client to HE!
I have been moving my Hue and Wink devices over to HE and have found that the Hue motion sensors do not send Illumination data through MQTT. Is this a future feature or something I'm doing wrong?
fwiw, hue motion sensors work much better on HE than they ever did with Hue. Having 9 or more motion sensors on the Hue hub would never work, it would always connect to 8 of them leaving rest disconnected (regardless of channel used). Now they are all working all the time.
Another question, does the app and driver update automatically through github or do I need to import each time? Thank you.
I assume they do provide illuminance information within HE ?
Do you have them enabled under the illuminance dropdown selector as well as the motion dropdown ? Update: It looks like I’m not supporting illuminance as a capability, I’ll add it to the feature requests. You could also try enabling the device under the top ‘enable everything’ dropdown, that might work.
You have to update either manually from github or use the ‘import’ url feature. Once this is used once you can just import again to get the latest version.
Kevin,
Thank you for the quick reply.
I did the 'enable everything' before and illuminance is still missing. As you discovered there is no section for illuminance, only motion, temp, and battery.
I look forward to testing this once it has been added.
/cheers
@PiXEL8 will be in beta2
Anyone need any other capabilities / attributes that are not implemented yet ?
1 Like
Kevin,
first, thanks for app. It opens lots of possibilities.
I had difficulties with the Beta but Beta1 installs without problems.
However, I cannot get any Hubitat devices to respond to commands.
For instance, for an Iris Outlet, I get:
When I send ../switch/set = on, the 'set' line changes accordingly but neither the 'switch' nor actual device react.
Also, one of the categories is 'Unknown'. Is that something to be expected or did I press a wrong button somewhere?
Thanks!
Hmm no, that isn’t a correct homie representation. What device driver is it ?
It’s coming through as a sensor with only a measure-power property - not settable. It should have a $settable = true and an ‘onoff’ property with a true/false payload
What capability drop down(s) is it enabled under and what attributes does it have ?
Does it appear under switches , outlets ?
Did you perhaps create the switch topic as well as ..switch/set ?
Also make sure all your devices are enabled here..
Thank you again for adding Illuminance sensors.
Could all the states for locks (schlage be468/469) be added? Currently it's only sending lock state and battery states. Additional items include; codeChanged, lastCodeName, lockCodes, codeLength, and maxCodes. There are probably others, but I'm just now moving this over from Wink.
/cheers
Sorry for the lag of promised feedback, but another project took priority. Anyway I moved from OpenMQTTGateway on an ESP32 to a RPi Zero W running miflora-mqtt-daemon
It's finally up and running stable where it can see all 6 of the miflora sensors that matter.
Based on the following from the log, I'm guessing I've got it configured correctly. It's just that my devices aren't supported yet
Does this point to anything wrong? Or do I just need to wait for support of those units. Also I am going to add a MQTT feed from my AirThings Wave Plus via bluetooth along with a PM2.5 sensor attached to the zero. I'm guessing pm2.5, voc, co2, and radon won't be supported yet either. I'm not really that concerned about temp, humidity, and pressure. I can offer to help, but I can't commit to any sort of regular schedule because of health issues.
app:3852020-02-02 02:31:53.582 pm infoMQTT: ================== Startup complete ==================
app:3852020-02-02 02:31:53.539 pm infoMQTT: [1] Total Hubitat endpoints enabled on MQTT
app:3852020-02-02 02:31:53.536 pm infoMQTT: [0] Total Hubitat devices are enabled on MQTT
app:3852020-02-02 02:31:53.437 pm infoMQTT: ==================================================
dev:4822020-02-02 02:31:53.340 pm infoMQTT> ======== Regardless asking Startup Summary to run ============
dev:4822020-02-02 02:31:53.338 pm infoMQTT> ======== Regardless HA Discovery has completed =============
dev:4822020-02-02 02:31:53.331 pm infoMQTT> ============ HA Discovery has completed =============
dev:4822020-02-02 02:31:53.282 pm warnMQTT> Received unexpected message from homie [homie, miflora-mqtt-daemon, Sixth, temperature, $unit] [°C]
dev:4822020-02-02 02:31:53.233 pm warnMQTT> Received unexpected message from homie [homie, miflora-mqtt-daemon, Sixth, moisture, $unit] [percent]
dev:4822020-02-02 02:31:53.187 pm warnMQTT> Received unexpected message from homie [homie, miflora-mqtt-daemon, Sixth, light, $unit] [lux]
dev:4822020-02-02 02:31:53.140 pm warnMQTT> Received unexpected message from homie [homie, miflora-mqtt-daemon, Sixth, conductivity, $unit] [µS/cm]
dev:4822020-02-02 02:31:53.092 pm warnMQTT> Received unexpected message from homie [homie, miflora-mqtt-daemon, Sixth, battery, $unit] [percent]
dev:4822020-02-02 02:31:53.039 pm warnMQTT> Received unexpected message from homie [homie, miflora-mqtt-daemon, Fifth, temperature, $unit] [°C]
dev:4822020-02-02 02:31:52.974 pm warnMQTT> Received unexpected message from homie [homie, miflora-mqtt-daemon, Fifth, moisture, $unit] [percent]
dev:4822020-02-02 02:31:52.918 pm warnMQTT> Received unexpected message from homie [homie, miflora-mqtt-daemon, Fifth, light, $unit] [lux]
dev:4822020-02-02 02:31:52.871 pm warnMQTT> Received unexpected message from homie [homie, miflora-mqtt-daemon, Fifth, conductivity, $unit] [µS/cm]
dev:4822020-02-02 02:31:52.825 pm warnMQTT> Received unexpected message from homie [homie, miflora-mqtt-daemon, Fifth, battery, $unit] [percent]That's progress @LostJen - and yes it looks like I could add better support for those - let me take a look.
Could you post a screengrab of a fully expanded MQTT tree for one of these devices/nodes (all sub topics expanded) from MQTT Explorer and let's see what I can do.
Ok, this shows the first sensor fully expanded, but I have a ton of work to do with the air quality stuff so this is easy to backburner.
Kevin,
You are right! For the outlets, I only had 'Outlet' category selected but missed the 'Switch' category. The outlets work now.
I don't know if that's an issue at all but 'unknown' topic still exists.
For instance, for a dimmable bulb, whenever I use the HE web interface to change the device states, I get updates to 'onoff' (or 'dim') and also to 'unknown/switch' or 'unknown/level', respectively.
I could not get my valves to work - nothing is settable.
It's a Fortrezz valve but I am using a custom driver.
The driver has some additional capabilities:
capability "Actuator"
capability "Health Check"
capability "Valve"
capability "Refresh"
capability "Sensor"
Thanks!
Those 'unknowns' don't matter but shouldn't be there - the driver is what ?
I'll look into valves ..
With apologies, I am not sure I understood you question regarding the driver.
The first pic is for a GE bulb; the driver is HE Generic ZigBee bulb.
The valve uses a custom driver. Essentially, the driver is a copy-paste from ST.
