I believe i created it through the app. The virtual device looks like the devices from before with the Device Network Id = "MQTT:virtual_Big Garage Door".
below is a log dump as well indicating it was created. I'll take another look at the groovy and see if something looks odd.
Thanks!
app:992020-11-23 02:09:05.901 pm infoMQTT: Adding data contact_Topic to Big Garage Door
app:992020-11-23 02:09:05.889 pm infoMQTT: Found attribute contact in Big Garage Door [ContactSensor]
app:992020-11-23 02:09:05.884 pm infoMQTT: Found ContactSensor in childDev Big Garage Door
app:992020-11-23 02:09:05.869 pm infoMQTT: Created Child Virtual Contact Sensor with name Big Garage Door
dev:1652020-11-23 02:09:05.845 pm infoBig Garage Door was closed
Could you post a screen capture of the data values for one of these devices (from the devices menu).
Update : Yes I have some virtual devices that are now showing this error. I think it maybe a bug in 2.2.4.145 reading data values back from devices. I will check tomorrow
In the device that is created can you look at the origin data value and let me know what it is (it should be user). Only devices created manually by yourself as a user can be edited.
I know the dropdown allows selection of other virtual devices e.g. those created directly in the hub or discovered from Home Assistant or homie but there is no ability to apply a second filter to the input list to hide them Such devices can not be edited as the values are populated directly from the provided MQTT payloads.
I think that device.updateDataValue (name,value) has become broken in 2.2.4.145 again, certainly on child devices. No errors are thrown but no data values are added to the device.
I have the same driver for my Ikea shades and ran into the same error message as @hovee referencing the MissingMethodException on line 4469 while attempting to publish my shades to MQTT.
I commented out the extraneous text on line 4469 and it seems to have fixed the error and allowed the shades to be published. Before the $state would stick on "init" and all the devices would be uncontrollable in HA (and no shades present), now it is "ready" and all devices including the shades are controllable.
I didn't see any further discussion on this one so I wanted to give a heads-up that despite the useless error groovy spit out, it really is that mashed up line of text on line 4469 of the app code that looks to be the root cause.
I feel like I'm being very stupid, so I hope somebody can set me straight.
I've got MQTT going OUT of my HE just fine, the states report in MQTT Explorer and can trigger stuff in Node-RED, but I can't for the life of me work out how to correctly issue a command through MQTT to trigger that change in HE.
Taking my Office bulb, for example, I can see the following:
However, my logical thought would be that publishing false to onoff would change the state in HE, but that doesn't work. After half an hour of googling and scouring the forum, I'm still stumped.
They don't always seem to update for me though. I've got a virtual switch I activate through Alexa to set my night mode stuff, for example, and twice now it's failed to show up as changed in Node-RED even when I turn the switch on directly from the HE.
Maybe I'd be better off trying to narrow down why the API is failing to update Node-RED, haha.
The topics for controlling anything are the same as the status topics but with .../set appended, assuming the device is $settable=true
so your office light would be controlled by the topic
homie/hubitat-elevation/office/dim = 50
or homie/hubitat-elevation/office/onoff = false (or off)
That is indeed logical but in MQTT you can't use the same topic to provide status and to control the device. They are always two different topics with the control topic typically being appended with ... /set (or in some other systems .../cmd or .../command)
I will try and improve the documentation to make this clearer as it has stumped a couple of people before too.
NodeRED does create an alternate solution for you and you should be able to get it working reliably although it then only provides a HE<>NodeRED link and doesn't expose HE devices to any other controllers you may have or add later.
Yes you could onwardly pass the NodeRED info to MQTT and monitor MQTT for changes with NR but you are essentially tied into HE/NR. If you use MQTT directly you are 'open' to interaction with all other MQTT capable devices and no longer tied to NR or HE. You can also import other MQTT devices into HE. So it provides much greater flexibility , particularly in larger systems or when your system evolves later in life..
You can still use NodeRED with MQTT of course with there being that one extra step of MQTT inbetween. Speed will not be a concern either way.
You can sort of regard MQTT as an open state model for everything in your system - kind of like HubConnect or HubMesh but accessible to all MQTT capable controllers, not just HE
Exactly!!! I agree!!! The ultimate setup imho is to use MQTT as the generic communications "backbone" to tie everything together.
At present for me and my use-case it is more practical time-wise to use the HE Nodes as part of an HE/NR integrated system - at least for the systems I install and support. I do use MQTT for other communications like pulling from a Personal Weather Station and also generating custom "events" in NR.