Are you using the ip address in mqtt explorer or "localhost"? That might explain the difference.
On the machine that the Mosquitto is installed, I use local host to connect to it. On the remote machine I tried the IP address. I think I also tried localhost, but don't remember for sure.
I haven't had time to mess with it the last couple days. Will try again next week.
Try the ip address and see if you get the error.
You would have to use the ip address of your mqtt broker. "localhost" is by very definition the local host.
APP
V0.0.7 - 01/30/21 - Split sendAll and Initialize methods apart. Delayed initialization code by 1s to prevent issues if the driver happens to send, or app sees, multiple "init" events.
Fixes pretty serious concurrency bug found on hub reboots. Upgrade highly recommended.
DRIVER
V0.0.8 - 01/30/21 - Minor code cleanup. Optional upgrade.
Jason:
What's your thinking on the heartbeat interval? If its to detect a broker connection failure, my testing of pulling the network cable to the broker shows that hubitat doesn't detect it for 90-180 seconds.
On my setup it simply helped the broker from timeout/dropping the connection. Without it I would get regular disconnects from my broker for reasons I couldn't seem to fix.
Other than that, and the fact I like seeing moving values when watching in MQTT Explorer, it is completely optional.
ok, are you using a local broker (rpi/mosquitto)?
I bumped mine up to 10 secs just to reduce load on hub.
Oh I did another PR for another issue I ran into.
VM on the local network.
Now that you mention it though, it would be very easy to set up a write and then read back heartbeat to detect Network outages much faster than the built-in connection does.
That's above my pay grade. Seriously though I prefer multiple single function machines.
Definitely above my paygrade, but if you write it and I will see if I can break it ( good at that) and decipher a fix.
I don't see any new PRs?
(and thank you, by the way, I appreciate any suggestions/improvements I can make!)
I don't really use github so probably made a mistake. Here's what i changed. If you have multiple devices using driver as is, only last connected works. Each new connection disconnects previous. So suggest using a more dynamic variable for the connection id. device id in this case as hubitat generates it randomly.
Your welcome, I'm using this as learning experience too.
def getHubId() {
//def hub = location.hub
def hub = device.deviceNetworkId
//def hubNameNormalized = normalize(hub.name)
def hubNameNormalized = normalize(hub)
hubNameNormalized = hubNameNormalized.toLowerCase()
return hubNameNormalized
}
1 Like
Yes, that’s what I did.
I guess I don't understand what you mean here. Are you doing multiple drivers on the same hub? Or do you have multiple hubs that you gave the exact same name (which you really shouldn't do)?
I don't think it would be common at all for people to have multiple hubs with the same hub name on the same network.
Here are the 3 hubs I have connected right now - 1 driver per hub - all connected and working:
Yes
no, single hub
I have 6 individual identical devices (not parent/child) using the driver on 1 hub. First device connected works fine. As soon as a second device is added/connected it causes the first to be disconnected and so forth as more devices added.
As soon as I changed the interface id to the individual unique device id the above problem went away. Perhaps my usage is different then your design intention. I'm not using the app and mqtt messages are inbound to the hub.
I'm using it to support some zigbee button and sensor devices (aqara) that aren't supported (or poorly) by hubitat.
If a second client connects to the same broker with an identical clientID the broker will kick the first off but why multiple drivers to the same broker?
The app (I assume) uses 1 driver and 1 connection to expose all the devices from that hub. A second ‘device’ should use the same existing connection to the broker. It should not try and reconnect for example which would lose the first connection and its subscription.
I'm not exposing devices on hubitat to the broker, other way around. Using zigbee2mqtt to support devices not supported or poorly supported by hubitat.
I have yet to find a decent example of a mqtt hubitat driver subscribing to multiple topics that is designed for inbound mqtt to hubitat.
If you know of one please point it out.
Ah... Gotcha. That wasn't the direction I was going with the app. The intent for this app was that all interaction with Hubitat would be done through Hubitat devices - real or virtual. So for interfacing with external systems, the expectation was that users would have to make virtual devices in Hubitat, then write values to those virtual devices outside of Hubitat/the YAMA app.
I see exactly why you are doing what you are doing, and why. I'm just not sure that this app will ever be the best tool for that.
I would think that putting tre zigbee2mqtt deivces in home assistant or homie compliant structure on the MQTT side and then using @kevin app would work much better.
1 Like
I don't think he likes my app 
- did you try it Mike ? It doesn't handle zigbee2mqtt specifically so no auto discovery but you can bring any mqtt payload into a virtual device you create. A little laborious but do-able. I didn't consider zwave2mqtt or zigbee2mqtt useful as HE supports both the radio platforms.
What controller originates your zigbee2mqtt ?
There is deConz available if you could use that ?
1 Like
@JasonJoel Actually your driver with a few little modifications works perfectly. I have no need for the app. I had a driver that I was using previously but where I was stumbling was a good example of handling auto reconnecting to the broker in the event of a broker issue (reboot, maintenance, etc). You driver provided that to me. Thanks.
@kevin Actually I did try beta3 iirc. It seemed a little overkill for my needs (no offense to your work or its focus) plus from my recollection I perceived it to be more focused on exporting hubitat devices to a broker/homeassistant. I may be wrong.
Yes z2m is a zigbee duplication but unfortunately I made a few bad purchases of zigbee devices that turned out to not be in my hubitat's best interest but work exceedingly well on z2m.
If your referring to the radio portion of z2m I use both cc2531 and a 2530/2591 board. May upgrade to more powerful radio though.
z2m supported all the devices I had plus all i needed to get it going was a cc2531 radio.
1 Like
While acknowledging that it includes more moving pieces, I run with the following setup:
Hubitat <--> Node Red <--> Mosquitto MQTT server <--> Zigbee2MQTT
This works well for exposing Z2M devices to Hubitat (virtual device), but it is very valuable for me because I am building all of my automation logic and advanced dashboards in Node Red. I also feed data from Node Red to InfluxDB for all data logging/analysis/display purposes.
