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

That did the trick! Just deleted the Child device and tried again without restart and it connected right away. Thank you again for the help and for creating this amazing app.

I'm fairly new to MQTT and am still learning but looks like it will open up a whole lot of possibilities with HE.

2 Likes

I see there is measure-light rather than measure-illuminance - that is an error - it should be measure-illuminance. I will update that but in the meantime you can use measure-light.

Hmm, it is for me - there's should never have been a 'motion' topic within the motion tree but the top level topic (also called motion) should be updating - currently showing false in your screenshot. I suspect your other 'motion' topic doesn't really exist and is a retained topic in your MQTT broker. Click on it and click on the waste bin icon and delete it. It will re-create itself if it is being sent by my app.

If you select all the devices in 'everything' then yes. The app has to build and store property data values for every device and writing these to HE takes a bit of extra time. Fortunately this is only done at app startup and in normal usage this is only ever needed once at launch.

In a following build I shall avoid this 'data' step if no alterations were made to your 'MQTT enabled devices' which will speed this up but it will still be slightly slower during startup than before. However it is faster in actioning updates and set commands now which is what counts. Startup speed is not a big worry really but overall performance is. It would be nice to minimise both though.

Roger, Kevin.

Good. I thought that was odd. I'll go update my NR.

Suspected that might be it and it's really not a problem, just a holdover from "testing" mode. :wink:

@Losinit
The offending line for illuminance is on 4237, edit it if you wish...

			`category='measure-light'   // value and unit enum lux`

it should read

			`category='measure-illuminance'   // value and unit enum lux`

I have corrected the beta 3 version on GitHub for current downloads

Thanks :+1:

Kevin, I just received my Aeotec Multisensor 6 and I notice that all of it's measured values show in the HE log but humidity is not getting published:
Screenshot_2020-05-19_19-38-08
For comparison here is one of Iman's multisensors where the value is getting published:
Screenshot_2020-05-19_19-38-36

I'll take a look but although it's a bit unusual for one sensor to work but another not.

I don't have an Aeotec Multi 6 unfortunately. It has a listed humidity value in the devices humidity attribute ?

Is it enabled under 'Everything' or individual capabilities and if the latter is humidity enabled ? It does look unusual as the property exists. Maybe it's awaiting an update from the device.

What attributes are listed under that 'unknown' topic in the aeotec and also out of interest in 'custom' within Iman's ? Just FYI Custom attributes might only get values reported at startup currently and not when they change value.

Hot off the press:
Screenshot_2020-05-19_21-27-49

Yes.

Wait... What? Now it's showing up! (scratches head)
Screenshot_2020-05-19_21-30-21

Damn, you're good! You fixed it telepathically!

The NR folks are suggesting that I set the retained flag on all messages so that the latest data is available to NR when it (re)starts. So I did that:
Screenshot_2020-05-20_16-58-40
I'm probably misunderstanding things again but shouldn't Explorer show RETAINED for all of them now?


Like it does here?

Don't worry, the homie states are all retained if that option is on (and typically it should be)..

It's misleading in MQTT Explorer - what it shows there is whether the payload value displayed is 'retained' i.e. the value when MQTT Explorer connected or not meaning that it has updated since.

If you disconnect MQTT Explorer from your broker and then reconnect you will see all the retained topics re-populated into it. Non retained topics will not be listed. You will see that your measure-temperature topic then shows up with a 'retained' flag and a history of 1 value (you have had 6 updates currently)

Just for reference command topics that request a device to change state, which in homie is achieved using the .../set topic should never be sent retained.

Sure enough. :+1:

Heeeee's baaaaaack...
When your app restarts it publishes these and a few others like them:
Screenshot_2020-05-20_19-06-02
These are all named devices and they do show up properly under their name. I am able to delete these from the Explorer list but it seems to me they shouldn't be there in the first place, but what do I know? :wink:

Where are these enabled ? Under a capability or under 'Everything' - or neither but you're saying they get published anyway ? Can you not disable them ? There are no $properties posted...unless this screen grab was just early during the publishing time

They are not enabled in any list because they don't exist as HE devices. They were previously under those names when I first added them to the mesh but that was quite some time ago, except for the "aeon multisensor 6" which was yesterday. The HE has been rebooted twice just today for unrelated reasons.

Oh, and they were showing up before I set the retain option.

I really don't understand what you're saying here. These devices don't exist now but did before in HE ?

If so they would previously have been sent to MQTT as a retained topic and MQTT will remember them indefinitely unless you delete them from MQTT - you said you did this ? You clicked on the top level topic and then the waste bin icon and confirm delete. Now if you disconnect MQTT Explorer from MQTT and reconnect they would be gone (please confirm this bit)

Are you then saying that if you restart the MQTT app they get added again to MQTT i.e. in some way they are being remembered by my app on HE ?

When I get a new device type/model I simply accept whatever HE names it while I play with it. When I'm done playing and put it into use I give it a meaningful name. Does that clear it up?

No, because I've not had "retained" set in your app until a few hours ago. EDIT: Maybe I did when you were helping me setup for testing but it was off after that.

Yes

Yes, they are still gone.

Yes. Just restarted your app and now they are back. Here are the others I mentioned and they haven't been in the "play" mode for months, long before I first installed your app.
Screenshot_2020-05-20_20-04-34

I don't know what else could be doing it.

Here is the entirety of what is selected:
Screenshot_2020-05-20_19-59-21

OK - I'll take a look as I do use atomicState for some storage. You don't have one of these devices setup with both a 'Device Name' and a Device Label (displayName) that could be one of these older names ?

That's why I don't understand how my app finds those names unless they are retained on HE somewhere ! Not sure what 'play' mode means but if they were deleted before you installed my app then how does my app even know about them ?

they shouldn't really just ignore them FTTB but I will try and understand how they get there ... they do no harm although they could potentially confuse OpenHAB discovery.

Like this?


But if that is the source of the problem then why don't the Iris devices also get published errantly?

Me neither. And that's part of the reason I mentioned the reboots and timeline of installs.

image

Can we take this to PM rather than clog this thread up - I (or you) can post back here if we resolve it.. or we could have a new separate thread for your findings...
Just one observation - are these topics all device types
Aeotec ZW116
IM6001-otp01
ZGB:0D31
??