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.
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.
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.
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.
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.
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?
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.
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?
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.
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"
