[Beta] MQTT beta 3d (released 5th July)

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

dev:1652020-11-23 02:09:05.842 pm warninstalled...

Hmm curious...

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

2 Likes

@Curcloin @AwShifts

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.

origin = user

Kevin - I made a quick 1.5 minute clip so you can see the whole process. When I create the new switch (Pool Cleaner), and an old one I already had.

OK. What is evident is that the data values are now not being created on the device, let me see if they are here. It could still be a 2.2.4 bug.

Again just to double check you never used the beta 'external database' test feature did you ?

@gopher.ny

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.

Is that still a pending issue ?

I confirm that the fix hasn't made the cut to 145, but it is a part of the the upcoming version.

In a nutshell, if something else modifies the device in the meantime, the new value is fetched. That's why it works sometimes. Sorry about that...

1 Like

This updateDataValue issue should be fixed in 2.2.4.147, which has gone live a couple of minute ago.

1 Like

@gopher.ny @kevin

Absolutely amazing, updated to 147 and the device attributes are created with the virtual device. MQTT app creates the value and works perfectly.

I was an OpenHab convert and this is exactly why, 3 day turn around on an issue!

Amazing community and vendor!

3 Likes

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.

1 Like

Hi!

Sorry to be a fool - I'm struggling to get this working with Home Assistant and Mosquitto Broker.

I'm seeing this on the logs Hubitat side -

and this on the logs Mosquito side

Everything is setup for anonymous authent, just to keep it simple. Any ideas how/where to start debugging please?

Hmmm, my first thought is a network problem.

Have you been using Mosquitto with other stuff for a while or is this a new install?

What hardware is running Mosquitto?

Is it on the same LAN as HE?

What network equipment is between the two?

Try deleting the MQTT client device (not the driver code) and then (importantly) restarting your hub. A new device will be created.

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:

image

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.

Quick question - why not use the awesome HE Nodes for Hubitat?

edit: I get why you might want to go with MQTT everywhere it's nice to standardize on - that's kinda my long term goal as well..

I've got the HE Nodes, which are indeed great.

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.

1 Like

Might want to post that over on the Node-RED thread and ask @fblackburn / others..

I really haven't experienced that issue with Node-RED / HE at all.. interesting!

1 Like

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.

1 Like

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

1 Like

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.

I am still playing around with this though.

1 Like