Maveo (garage door) integration

Does Maveo send any interesting messages after it connects to a fake MQTT server? Can you at least see status changes, e.g. door open/opening/closing/closed?

The client does not check server’s certificate at all, but the Amazon cloud does check client’s certificate, so it is not easily possible to eavesdrop the original MQTT message flow…

Well I have tried it myself. It is sending the same {id}/rsp messages as the above linked thtemme’s cloud client is receiving! (and some more messages {id}/cloud_request to the cloud service like full status report and firmware update request). It seems to be usable locally already - if it also receives the same {id}/cmd messages (yes, it is suscribing to this topic). Hope Maveo is not going to upgrade the Stick to check server’s certificate in near future for others… I am blocking its access to internet already since now :slight_smile:

1 Like

Hi,

I’ve made my own implementation of the cloud communication (without knowing about this one). It is a little bit more complete and resistant to deconnections : yoda-jm/ha-maveo: Python library and CLI for the Marantec Maveo smart garage door system, built as a foundation for a Home Assistant integration.
I would gladly have some traces of the ventilation position to see what differs from my garage door (I don’t have the icon in the app, so probably there is some information in the cloud about this supported feature, I can already guess what status versions they can be)

cc @thtemme

PS: there is also a cli version in the repository to ease local development

I’m getting new garage doors installed with Maveo and am interested in replicating what you’ve done here. Can you confirm if I’m understanding correctly?

  1. Connected Maveo to Wifi
  2. Monitored its connections and found a DNS record it was reaching out to (for you eu-central-1.iot-prod.marantec-cloud.de)
  3. Hosted your own eclipse-mosquito instance.
  4. Created your own cert and key
  5. Set this broker to publish records to Home Assistant
  6. Used pihole as your local DNS server to override the record and point to the local instance
  7. Restarted the Maveo, which pulled the new IP address from pihole’s DNS record and published/subscribed to the local server instead.

Is that all correct? If so, I then have a few questions…

  1. If you publish to the appropriate topic on the broker, can you start/pause the door?
  2. How did you generate the cert and key?
  3. Could you (or @kouli ) share where the topic data structure looks like?

Actually I just got this setup myself with the mosquitto eclipse MQTT broker. I can see state changes like { "StoA_s": 4 } coming through. Did you already build Home Assistant entities that can translate these into something readable (like a cover) and have the commands to send back?

I have also reached the same level with a MQTT broker running into HA. This was pretty smooth, thanks to the information in this topic.

However, I have not yet been able to reverse engineer the commands necessary. Has anybody found the commands to open and close through MQTT?

I should have dug a bit deeper first! All the commands are documented here: ha-maveo/docs/iot-mqtt.md at 1f4aa7a8ed1243d0a0f61f98ac65de6e3732d1ec · yoda-jm/ha-maveo · GitHub

I managed to open and close with {"AtoS_g": 1} and {"AtoS_g": 2} and it works great!

Now, I will need to integrate this properly, but I am quite happy to have reached this point.

P.S. Using EMQX app allows to handle the no-authentication case that the Mosquitto app cannot do.

If this is useful for someone, I got it fully integrated into HA with this configuration.

You can find your device ID by using the log traces tools of EQMX

mqtt:
  cover:
    - name: "Garage Door Left"
      unique_id: "maveo_garage_60031772017094155"
      state_topic: "60031772017094155/rsp"
      command_topic: "60031772017094155/cmd"
      payload_open: '{"AtoS_g": 1}'
      payload_close: '{"AtoS_g": 2}'
      payload_stop: '{"AtoS_g": 0}'
      state_opening: "1"
      state_open: "3"
      state_closing: "2"
      state_closed: "4"
      value_template: "{{ value_json.StoA_s }}"
      device_class: garage
      qos: 1

  light:
    - name: "Garage Light Left"
      unique_id: "maveo_light_60031772017094155"
      state_topic: "60031772017094155/rsp"
      command_topic: "60031772017094155/cmd"
      payload_on: '{"AtoS_l": 1}'
      payload_off: '{"AtoS_l": 0}'
      state_value_template: >
        {% if value_json.StoA_l_r == 1 %}
          {"AtoS_l": 1}
        {% else %}
          {"AtoS_l": 0}
        {% endif %}
      qos: 1

That sounds promising, but I don’t really understand how you made it now.

Could you please write a little how to?

I mostly followed what is in this thread.

You have to connect to Wifi using the standard app. And then you do a DNS rewrite for eu-central-1.iot-prod.marantec-cloud.de to the IP address of your HA server, running EMQX. That will give you all the information about it. And then you should be able to use the yaml I have added before.

You can find the device IDs usings the topics that were registred into EMQX.

For me it doesn’t connect to EMQX due to authentication error. It’s sending a username of “?SDK=C&Version=3.0.1” and an empty password. Did you set a specific authorization policy?

No, it worked out of the box for me, I think. From what I have read, if you add some authentication methods to EQMX, it will then stop allowing anonymous.

Did you just install EQMX or were you already using it before?

I just installed it and moved all my usernames/passwords from mosquitto to it. I guess that’s why maveo wouldn’t connect.

Do you have a userstore configured?

I have no authentication configured in EQMX.

Interesting. It DOES work without authentication, but that feels… icky.
Thank you for all your work, though! I appreciate it!

1 Like

It’s better for Maveo to connect to you with authentication locally, than through to the internet to a cloud :slight_smile:

So your PS means that it does not work with Mosquitto, right?

Can I fully replace Mosquitto by EQMX easily? Otherwise I would have to run EQMX for the garage door only, if I get it right.

Any thoughts on that appreciated.

I have done exactly that and I wish I had known about EQMX from the start. I wouldn't have tried with mosquitto at all then, it's just better in every conceivable way.
Short version:
Remove mosquitto addon.
Install EMQX addon.
Do NOT configure a user-store in EMQX (as it doesn't support empty passwords).
Update MQTT Integration to point to EMQX (it won't be hostname core-mosquitto anymore).
If you use Zigbee2MQTT, update that to the new hostname as well.
Done. HomeAssistant will pick up any MQTT entity that was in mosquitto from EMQX now, no reconfiguration of entities / devices needed.

1 Like

Yes, as far as I have found, Mosquitto does not support anonymous access.

If all your current integrations can use EQMX, i would say yes, but I am far from an expert, I was not using MQTT before.

1 Like

HA's mosquito doesn't support anonymous access, it has been removed during compilation.
The mosquito app in TrueNAS, fort example, does support it.

1 Like