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.
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 ?
@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.
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.
This is exactly where I'm heading but need to keep WAF high in the meantime. I plan on introducing a node red & and DB server into the mix, I'm just not there yet. Need to learn node-red.
Well yes it trys to offer a lot but in fairness you just donāt use the bits you donāt want. They donāt cause the app to run slower or anything but they do make for a more complex interface due to the options. That I believe is why Jason is offering the YAMA app. His app makes it much simpler to integrate HE to MQTT
Yes it focuses on HE outwards as does YAMA but it does the reverse with auto discovery admirably I hope.
My MQTT driver is not generic ie something to be useful to other apps. It is heavily entwined with my app and handles message decoding within the driver so that isnāt an option.
My HA system is what I would call MQTT based and secondarily I access that from many controllers HE being one and I wrote the app to facilitate that.
Glad you got the YAMA driver working well for you, MQTT disconnects can be quite problematic to handle with concurrency etc. Multiple rapid disconnects in particular.
Your z2m is on a Pi or something ?
Keep at it and let us know if you create something useful for discovery from zigbee2mqtt
Yes its been running on a pi 3b+ for about a year. Was an early version of z2m that I haven't touched/updated nothing. Setting up a new one now.
Tried a pine rock64 board (3b+ clone that I got for ~$15 w/case/powersupply/sd card and display) but its onboard uart fixes the baud rate at 1500000 and no matter what I tried it wouldn't connect to the cc2530/cc2591 radio.
All of the devices attached to it are what someone else would probably toss in their junk draw of shame.
OK - Jasonās YAMA driver suits you and others well, with your mods.
If you have a moment please PM me an expanded topic tree screenshot of zigbee2mqtt so I can look over how hard it would be to do auto discovery in either my app or another standalone app. Do you use ZWave2mqtt too ? I donāt want to clutter Jasonās topic anymore than I have already.
I will try both myself soon
zigbee2mqtt only. I only have 6 zwave devices (glass break sensor) and made sure 100% support by hubitat before purchase.
PM coming soon.
At the moment although MQTT is very well adopted in HA and OH worlds it is evolving in HE acceptance where more people want a simple functional solution around one controller ie HE. I think Jasonās YAMA is well positioned for this if you need HE exposed to MQTT, although that in itself has an inference some other device consumes that data.
As many will attest to here. I love Node Red, but it is almost infinitely deep on how far you can go with it. Many stick to the drag and drop nodes which allow you to do almost anything. I have for better or worse put logic into function nodes. This can often replace many nodes with one set of logic, but because you right the code in function nodes in Javascript, it is also easy to go very deep there as well. I have become enamored with refactoring the code in my function nodes over and over as I learn JS better.
Good luck on the WAF.
I finally got everything working. But get this error when the remote sends something to HE.
app:24602021-02-05 06:21:12.412 pm errorjava.lang.NullPointerException: Cannot invoke method getParameters() on null object on line 305 (deviceEvent)
What is the MQTT topic?
Turn on debug logging (in the app), do it again, and see what it shows for:
"event device: "
"event type: "
"event value: "
app:24602021-02-05 06:38:13.254 pm errorjava.lang.NullPointerException: Cannot invoke method getParameters() on null object on line 305 (deviceEvent)
app:24602021-02-05 06:38:13.249 pm debugeventDeviceCommand: null
app:24602021-02-05 06:38:13.245 pm debugeventDeviceCommands: [startLevelChange, hold, stopLevelChange, doubleTap, push, refresh, setDimmerCustomBrightness, configure, release, setLevel, off, on]
app:24602021-02-05 06:38:13.240 pm debugeventDevice: Office Light
app:24602021-02-05 06:38:13.238 pm debugevent value: off
app:24602021-02-05 06:38:13.236 pm debugevent type: switch
app:24602021-02-05 06:38:13.235 pm debugevent device: Office Light
I enabled a couple of other debuts to see what was going on.
Hmmm. I'll take a look this weekend - no time tonight.
I get why it throws an error, just have to go back and do some testing to remind myself why I did it that way.
What topic are you writing to in MQTT?
No problem. Iām just playing around at this point. At your convience.
Topic: hubitat/house-hub/Office Light/switch/set
Download the Hubitat app
