Logon screen timeout

[therealdb]

@toggledbits pardon me for the silly question, but I'm having a tough time pushing all the Vera's variables via MQTT. Is that possibile via the echo capability?

 echo:
      include_entities:
        - "vera>*"
        - "hass>*"
      #exclude_entities: []
      #include_capabilities: []
      #exclude_capabilities: []
      primary_attributes: true

I've tried both with empy include_entities, setting primary_attributes to false with no luck.

Logs seems to be very generic about that:

[latest-21342]2021-12-09T13:32:02.804Z <Structure:INFO> Starting controller MQTTController#mqtt
[latest-21342]2021-12-09T13:32:02.806Z <MQTTController:NOTICE> Connecting to broker mqtt://192.168.1.26:1883/
[latest-21342]2021-12-09T13:32:02.901Z <Structure:INFO> Starting controller SystemController#reactor_system
[latest-21342]2021-12-09T13:32:02.903Z <SystemController:NOTICE> Controller SystemController#reactor_system is now online.
[latest-21342]2021-12-09T13:32:02.959Z <app:INFO> Structure running; pausing for controllers' initial ready
[latest-21342]2021-12-09T13:32:02.997Z <MQTTController:INFO> connected; opening subscriptions
[latest-21342]2021-12-09T13:32:03.001Z <MQTTController:INFO> Sending inits and going online!
[latest-21342]2021-12-09T13:32:03.002Z <MQTTController:NOTICE> Controller MQTTController#mqtt is now online.

Thanks!

[therealdb]

Ok, I've got it. echo it's under config, but per the doc this is not clear. I'll probably post a new snippet. Now onto parsing all these messages and remove my UDP broker from my Vera.

[toggledbits]

All good. You did remind me that that section needs more debug, but it is working for me, so yeah, let's see what happens when you move echo under config. Should be OK. Are you also using something like MQTT Explorer to eavesdrop?

[therealdb]

@toggledbits yep, I'm using MQTTExplorer to see the messages.

All good now. I've just re-routed all the messages to my broker and my dashboards are now working via MSR (but still sending commands to Vera atm). I just wrote a small piece of code to transform the incoming messages, and everything is good now.

I confirm that echo is under config: I've looked at the code to confirm this behavior.

Is there a way to get the current house mode, or should I send a custom message in a reaction?

Thanks again for this fantastic tool!

[toggledbits]

There's a house mode entity that's created and maintained by VeraController. You can find it in the Entities list. Easiest to filter by the capability x_vera_housemode.

Docs have been fixed so the config example is correct and more clear.

[therealdb]

I'm aware of this entity, but it's not pushed to mqtt. Do I need to add something special to the included entities, beside vera>*? Thanks!

[therealdb]

Nevermind. For a future reader, I've just created a new Rule with a trigger based using changes and a reaction to send the current housemode (via an expression) to reactor/mqtt/vera/housemode/value, so I could easily get the status in my own daemon. I'm simply loving it!

So, after a restart because I changed some configuration, I've seen a new reactor/mqtt/vera/housemode/state/x_vera_housemode with { "mode": "home" } inside. No need to write a rule, after all.

[toggledbits]

Some details to consider (you probably know now, but for the benefit of others reading now and later):

1. To publish the house mode entity or any other, it has to match the list of selected entities (i.e. pass the filters). With your vera>* rule, it certainly should.
2. MQTTController does not usually "blast" all the statuses at startup. The retain flag is set by default on most messages, so the broker is expected to retain the last state and offer it to clients on connection/subscription.
3. A follow-on to #2 is that there is also no initial message sent out the first time an entity is published... if you change your config so a bunch of new entities are selected, there won't be initial messages going out for them to establish baseline state/retention. Maybe that needs to be addressed. In any case, both #2 and #3 here suggest that when starting to use MQTTController, or modifying config, you need to "stimulate" an initial publish to get that initial state into a retained message into the broker's cache.

FYI, there's an update to MQTTController available (21343) now. It just adds support for the new dynamic groups, and some additional debug/diagnostic messages where it was a bit thin before. Also, very important, the default exclude_capabilities filter has changed and now excludes extended capabilities by default (the x_-named capabilities). You can (and probably will need to) undo this by giving an empty exclude list (exclude nothing, exclude_capabilities: []). Docs are updated to reflect the latest changes.

[therealdb]

Yep, I'm calling Vera to get the status in my system and update my internal data. MQTT is used to push the updates and it's working very well. I've noted your points and I've updated my config. I'll update the MQTTController build later tomorrow. I'm just testing all my changes in production today, to be sure everything's working.

I've also added reactor_system>* to the published controllers, and I'll use sun information later when working on my new automations based on solar.