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.
1 Like
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.
1 Like
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
Did you create custom topics on the MQTT side? I've never seen a driver where there is a command called "switch". Attribute, yes. Command, no.
See below. To turn this switch on externally, I would write something (anything) to hubitat/colts-foot-c7-spare-hub/2-Left Dimmer/off/set
You will see the switch attribute in the list too at the bottom, but you can't write anything to that. It is an attribute, not a command.
This is making me think that I indeed should have separated out attributes and commands in the topic structure...
like:
hubitat/hubName/deviceName/attributes/xxxxxx/value
hubitat/hubName/deviceName/commands/xxxxxx/set
I thought only having the commands have a "set" topic would be enough, but maybe not.
I have a Zooz light switch. Standard built in driver. This is the item I added to your app. Nothing special that I did.
Edit: I misread your comment. I had to add the unit manually in the MQTT side. So probably got that wrong. I will look at it again.
OK. If you get time take a pic of the device details page so I can see what the commands at the top look like.
In the meantime, what you likely want to do is write to on/set and off/set, not switch/set.
APP
*** Breaking Change Alert!!!! ***
- V0.0.8 - 02/06/21 - Changed topic structure, putting attributes in hubitat/hubName/deviceName/attributes/* and commands in hubitat/hubName/deviceName/commands/*
DRIVER
*** Breaking Change Alert!!!! ***
- V0.0.9 - 02/06/21 - Edited subscriptions to support new topic structure with /attributes/ and /commands/
- V0.1.0 - 02/06/21 - Changed periodic re-check logic a little to have method always run every 60s
1 Like
I should back off here and explain what I am doing. I had a PI that I was not using and thought I would play around with Home Assistant. So decided to use your app, which appears to be great by the way. I just put in the one device.
In HA I had to add the following code to the YAML file. So apparently I don't have the command right. The state part works fine as I see the state of my switch in HA. I just couldn't control it from HA.
Here is the code snippet. I will play around with the command_topic.
switch:
- platform: mqtt
unique_id: Office_Light
name: "Office Light"
state_topic: "hubitat/house-hub/Office Light/switch/value"
command_topic: "hubitat/house-hub/Office Light/switch/set"
payload_on: "on"
payload_off: "off"
state_on: "on"
state_off: "off"
optimistic: false
qos: 0
retain: true
Yup, your command_topic is wrong for this app/driver structure. Also, you can't use only 1 command topic on this app/driver either, as each command is exposed separately.
Kevin's MQTT app exposes things in a more home assistant friendly format, though, if that is your goal.
Have to figure out how to do that. I looked at Kevin's app and got too confused. I guess I should revisit it.
Apparently your app doesn't send something to let the broker automatically discover the devices?
