[BETA] YAMA (Yet Another MQTT App)

Not sure what that means. When the app initializes it builds all of the device command topics in the broker. In my screen shots earlier all of those topics were automatically built.

Attribute topics get built as attribute events happen in the hub. There really isn't any technical reason to pre-build those as the end consumer can always subscribe to any topic in a broker, whether it exists already or not.

If you want to force all topics for devices added to the app to get re-built in the broker immediately, though, click the sendAll command button on the driver.

In HA it says to send the info to the discovery topic. Then HA will supposedly create the devices automatically. I'm still trying to figure that out. I may delete everything and start over. I've probably got it so messed up now.

I'll let you know what I end up with.

No worries.

Yes, how HA does it is outside the scope of this app/driver. I intentionally did not put things in HA format, as I'm not integrating devices into HA and I don't like their MQTT topic structure for how I do things in node-red.

If you are integrating with HA, you really need to be using Kevin's app. That is exactly what it was designed for - out of the box, so to speak.

EDIT: That said, anyone can fork the git and add home assistant compatible topic formatting to the app. Not something I'm planning to do, though.

2 Likes

DRIVER

  • V0.1.1 - 02/06/21 - Fixed dumb periodic re-check scheduling mistake, changed heartbeat to schedule

This is kind of off topic, but I was using this driver as an example/basis to create a modified version for myself (for a completely different purpose), thanks for having some straight forward code!

The question I have, I noticed you are only scheduling your heartbeat and periodicReconnect within initialize, and they don't get unscheduled/scheduled within updated. Did you purposefully only configure these within initialize? Probably not much of an issue once things are up and running, as they will run at hub startup, but as I was going back and forth and setting this up/debugging, they never were actually scheduled.

  schedule('0 */5 * * * ? *', heartbeat)
  schedule('20 * * ? * *', periodicReconnect)

Just want to make sure I'm not missing some sort of logic bug or something that would make things go out of control, if I end up adding them to updated.

No reason I can think of offhand.

I will say that early on I had a lot of problems with concurrency (the app running multiple times simultaneously), and fiddled around a bit to ensure (as much as one can, which isn't much) that didn't happen.

It could have been an indirect results of that mess.

2 Likes

I installed it by copying in and saving the app and drive code, but I can't find how to change the settings. I presume it's something I did wrong. Suggestions for how to figure it out?

Where exactly are you stuck? @JasonJoel's directions in the first post of this thread are pretty clear. Did you skip them?

  1. Create a virtual device and assign the YAMA driver to it to create a YAMA device.
  2. Configure the YAMA device with the server name/IP/port etc.
  3. Load the YAMA app and pick the YAMA device and the Hubitat devices you wish to publish.

Oops, did not RTFM -- so I added the device but not seeing any messages from MQTT. Tried both name and IP address of the broker.

It is IP address only, no name resolution, no mdns, other. IP address only.

1 Like

Are you using MQTT or MQTTS? I would guess there is a credentialing issue given how rapidly the connection to the broker is closed.

But only you know how your broker is configured.

Good question, I never tested it w/any TLS security.

EDIT: Just FYI I installed and tried the code - still works for me.

MQTT Explorer:

Thermostat:

1 Like

Me neither. I’m using it with a firewalled broker on my LAN, so I’ve never used mqtts.

Also, I only ever tested it with the Hubitat hub and MQTT Broker on the same subnet, as that is how mine are setup. I typically use bridge MQTT servers if I need to do cross subnet/vlan/location MQTT.

1 Like

Ah ha -- the example shows

but all I see is

Rebooting didn't help

Those are two completely different screens. One is the app, one is the virtual device setup?

EDIT: Did you click SAVE DEVICE after specifying the YAMA driver for the virtual device? I just updated the OP to explicitly say that as well, to make it more clear.

Did you specify any other hubitat devices in the app?

The YAMA app doesn't assume which apps you want to send/receive from MQTT - you have to tell it.

In my install here is my driver:

Here is my app:

1 Like

Aha -- I need to first install the driver then add a device and then I can add the app.

I see 2022-08-08 13:38:01.966 2022-08-08 13:38:01 [hubitat/home2-hub/wiz_0efdba/commands/off/set]

I need to check my code to figure out why I'm not seeing the message since it is showing up when I monitor on my Mosquitto machine.

Thanks!

I do realize this isn't production code so accept that some futzing is required.

Is that how you define RTFM? Funny, first time this particular issue has arisen in this thread. But hey - you be you!

2 Likes

No worries, I hope it is helpful. It has been very pain free in my uses, which is why I haven't had to update the code in quite a long time. I am open to suggestions (on a non-committal basis of course), if you come up with any.

Be nice. :slight_smile:

3 Likes

Thanks! It is working well!

As to RTFM, just using the technical lingo. These days reading the manual has become passe as more and more software is self-explanatory simply to survive. The downside, today, is that trying and failing is the norm and if this were a supported business app I'd complain. But in this case, I am willing to put in the effort and share what I learn. I mentioned it because I want to preempt the usual "it's in the manual - did you read page 782?".

Given the structure of Hubitat I don't have a simple answer beyond, perhaps, having a "here is what you'd be surprised by if you expected a polished implementation"