MQTT app beta3e March 2023- 'work in progress'

I tried beta 3d because I don't see a link to beta 3e anywhere in this thread. You mention that it is coming in the original post but I don't see it. What am i missing?

Just send me a PM asking for a link to beta 3e and confirm that you will accept the license terms (no redistribution and willing to test and feedback issues) and you can test beta 3e. Beta 3e release will be released as beta 4 here when the documentation is done and any bugs addressed.

For anyone testing beta3e I will only support against the latest beta version posted which currently is pre28a and will likely be pre29 by tomorrow. I really can't address issues 10 versions back as I lose track of the fixes in which version .

So first fix is to update to latest version and confirm the issues still exists and then PM me for help.

I'm really sorry but I can't help people who know little about MQTT . If you are new to MQTT decide if and why you want to use MQTT and then use one of the many other more 'focussed' MQTT apps that are available for your need , these will likely achieve your specific needs better.

This MQTT app is highly capable and like a 'Swiss army knife' for MQTT integration but you may only just want some very small aspect of this functionality that another app would suit better for.

beta 3e pre29 is posted for the testing group and fixes these HA issues plus a couple more.

Again if people want to test beta3e PM me. The only expectation is that you are competent with MQTT and have used the existing 3d version and are prepared to test / feedback any issues.

As pretty much all known bugs are squished I'm on with writing the documentation now pending the public release

1 Like

Without a "virtual battery" device how do I represent battery level?

The Hue outdoor motion sensor's standard reporting has motion, temperature, illuminance, and battery. I have a virtual motion sensor for the first 2 and a virtual illuminance sensor tied to the same device for #3. Do I have no way to address the battery?

I'm using these virtual devices to mirror the Hue outdoor motion sensor which is paired with a system other than HE.

TIA

The MQTT Text device contains a battery capability.

1 Like

Thanks! I would never have thought of that.

I added it because so few virtual devices have this capability despite it being needed.
I’m somewhat reliant on how Hubitat author their virtual drivers

1 Like

It's crazy, right? How many motion sensors don't have a battery? Only a silent minority I think.

LOL - I get it

1 Like

I do happen to have 2 zwave multi sensors, Aeotoc and Inovelli, that have motion detection and can use battery or USB power but they are so slow to respond that I use them only for testing.

@kevin, is there a way to prevent virtual omni sensor attributes that have no topic assigned from being reported? Tiles on @jpage4500's dashboard are displaying "present" along with temperature and it's messing up the tile.

I don't think so - not absolutely sure as the dashboard app doesn't support iOS which I use.

My app adds the virtual device type that you select and that includes the default capabilities and attributes for that type of device, even if they are not used. Choosing another device type that more closely matches the used attributes would be preferable if you can.

Altering the display within the Android Dashboard app to exclude unused or blank attributes would be more a feature of the dashboard app rather than my app.

I hear ya. Joe's an Android dev by trade so it's understandable, albeit unfortunate.

OK, but it seems an easy conditional...said the guy who isn't responsible for the code. I'll look through the code to see if I can add the test.

@kevin, a virtual switch I created in your app is not following the status topic and I believe it's because I don't know how to specify an element in a json object. This is the device's config

assignedTopics

and here is the relevant topics in Explorer

image

So how to specify the "value" element in the status topic?

Oddly, the command topic works without such a specification.

I think I found a workaround. The zwavejs2mqtt app wants boolean values and your app sends text it seems. I need to use node-red to convert between the two.

The json values are still identified the same as in beta 3d (as per the read me for that version). If you don’t extract the named values from a json payload the retrieved value in the value will actually be the whole json structure

That’s probably because your device will accept payloads that are not json formatted too

For custom devices the app will send whatever the mapped value is for example ‘false’ can be mapped to ‘0’. Note all payloads on MQTT are text. If you use the default homie implementation it will use true|false as that is as defined by the homie spec.

NodeRED can be used for payload translations of course but the MQTT payloads remain text values unless NR converts them to another data type for internal use. I use NR for payload massaging quite a bit eg fahrenheit/centigrade etc.

1 Like

Hi, Kevin.

I've configured a virtual audioVolume device in your app and it neither publishes changes nor responds to them.

Steve

Can you assist me with a little more information than that Steve...

What do you mean by 'configured' and from where within the app did you do that? Where is the device originating from?

What device (HE type) is it creating and with what capabilities/attributes/topics?

What does it actually publish on MQTT? and is it subscribing to anything at all?

Anything in the logs?