MQTT Client

[Toby Mills]

Who saw today that the new update includes an MQTT Client!!!
Hooray and about time, would have loved it also had a server but its a start.

However, I only have a Gen 1 Miniserver, so can't use it.

The Gen 2 miniservers have been out so long now that I wonder if its worth waiting to see if any newer model with more processing power again comes out.
For those with Gen 2 miniservers, what is your CPU load like, are we approaching the limits of Gen 2 yet and would you consider upgrading to a Gen 2 this late in the cycle or holding out for a while?

Toby

[Jonathan Dixon]

yes! I saw this yesterday and gave it a quick test. A glaring drawback is it only supports 16 subscriptions per broker connection. My home miniserver already has 24 subscriptions (via loxberry) and I don't consider that particularly large usage - a few power monitors (emonpi) and a few CCTV object detections (frigate), plus stats from the MVHR system. There's a lot more I could have implemented if solid MQTT was there from the start!

The docs go to some length to explain how to do wildcard subscriptions, which almost would solve this limit, however the received messages only contain the values with no indication which topic they arrived on, so is completely useless. Just a jumbled stream of jibberish.

The obvious work around is to have multiple connections to the same broker - this appears to work ok, so heaven knows why they force subdividing it this way. 

Minor gripe: having subscriptions be text only, and having to manually wire up command recognition to extract numbers, is bit of a chore, vs most virtual inputs (and even RS232 extension) that can do this via params in the input reference.

Personally I'm fine they didn't include MQTT server support, especially if it would be similarly crippled functionality wise, as I already have several packaged options to choose from - and I think anyone considering MQTT probably has somewhere better to run one already.

To the gen2 question - yes i just made the upgrade a month ago, and don't regret doing so even if gen3 were now to be launched. I've generally avoided going wild adding cloud-connected integrations to all the smart consumer devices I could do (white goods, lawn mowers, etc) as personally I'd rather keep that sort of thing out of my core building control layer - much prefer doing that on a less critical computer/VM running Home Assistant. But I see why it's attractive for professional installers making an optimistic wish for "setup and forget" integrations with consumer devices.

my gen2 MS is at 37% utilization, vs about 70% on the the old gen1. (And the config has grown since then, as I now have Audio servers and some devices using SSL connections)

--
You received this message because you are subscribed to the Google Groups "Loxone English" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loxone-englis...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/loxone-english/eed4fe73-f833-40fa-a530-36c54f93f6f4n%40googlegroups.com.

[Steve Joyner]

Looks like a good start, but not sure how useful this will be out of the box (to me anyway) without some tinkering to other parts of an mqtt setup  Looks like you can only subscribe to 16 topics (I have 30odd boiler parameters being publish on different topics by ebusd).  Its possible to subscribe using wildcards, but the ’subscription’ block does not give you access to the full topic text - so if you subscribe to a partial topic with wildcards - like /boiler/params/#, then unless the payload values contain the topic or some other identifier, then its not possible to work out what value you are receiving.  I guess whatLoxone had in mind where json type value being publish which contian the name of the parameter as well as its value.

@Toby - my Gen2 is running at 25% for what I consider is a medium sized installation.

Steve

[Jonathan Dixon]

>  I guess whatLoxone had in mind where json type value being publish which contian the name of the parameter as well as its value.

yes, I guess that is true, although in my experience it's much more common for publishers to send naked values than JSON blobs in MQTT  :-/

It's ironic as another integration I'm working on I need to parse a incoming JSON out of an inbound webhook call and that's not possible in Loxone - you can pull content from an external server via HTTP GET using an "HTTP virtual input" but not receive the body of an incoming HTTP post. Shame as it makes Unifi Protect triggers much more cumbersome and less feature rich to implement. 

Still, if it's the challenge that keeps this interesting haha

To view this discussion visit https://groups.google.com/d/msgid/loxone-english/DAC7647F-A75C-4C6A-B287-D2C833739642%40gmail.com.

[Daniel Feist]

It's ironic as another integration I'm working on I need to parse a incoming JSON out of an inbound webhook call and that's not possible in Loxone - you can pull content from an external server via HTTP GET using an "HTTP virtual input" but not receive the body of an incoming HTTP post. Shame as it makes Unifi Protect triggers much more cumbersome and less feature rich to implement. 

Still, if it's the challenge that keeps this interesting haha

Do you ever open Loxone tickets for things like this?  I've generally found them to be pretty good, and they've fixed numerous issues relating to DALI DT8 support over the past year or two. 

How are you doing integration without this:

- Just different webhooks/virtual inputs for different unifi alarms.

- Going via loxberry

[Jonathan Dixon]

Yes I've raised several tickets with them and get good response on bugs. Adding http post body handling would be a significant feature request though I'd imagine so I wouldn't hold my breath. May as well ask for a proper JSON parser while at it 😅

Handling incoming webhook calls would be a  nice feature add though, like Mqtt, in the the quest for robust, cloud free local device connectivity. Shelly device notifications would benefit from it too, for example 

In meantime, aside using loxberry for mqtt, I got quite far my creating a different virtual input for each distinct event needing differentiating, triggered from its own distinct alarm in  Unifi protect. It's a bit tedious with many cameras x areas, and unworkable if having many different user accounts needing distinct authentication handling. Fortunately so far I have just needed a binary "some user was authenticated" signal, no need to know which one.

Now I say it, a webhook to Mqtt or usb bridge in loxberry would be handy, kind of surprised there isn't one already in it. 

[sk]

Do you have to have a broker for it?  

I have a glow energy monitor and it has an MQTT publish interface.  Can I simply point it at the miniserver on port 1833, provide a topic and the subscription will start? OR do I need a broker?

thanks,