Custom modbus integration (AVE)

I totally agree… but the AVE support think at his server as black box that the user can touch…
Anyway i will try the MQTT bridge… i need MQTT both for AVE and AgentDVR…
Tnk for the reply :slight_smile:

(ti farei leggere la mail del supporto AVE… dove definiscono il loro server come un IPHONE :P)

Another question…
in my first try i chose to use mqtt.yaml to map the single AVE entities…
But now… when configuring the MQTT i see this

Is possible to let MQTT detect entities and devices from AVE Broker ? and if… what is the birth message to listen for ?

nah I don’t think so.

the implementation of mqtt that AVE uses is undocumented and I am not sure why is there at all, since it’s not required by AVE to operate. To my knowledge there is no official interface that make use of mqtt.

So the mqtt you get is an happy accident, and the integration I hacked togheter is done by listening for messages.

By the way do you have a copy of your configuration? Because otherwise trying to pinpoint all the name/adress yourself will be a pain the ass.

Hi everyone.
Sorry if I reopen the discussion but in my case, pressing the mqtt switch created, does not command anything. I found that in the command_topic you have to put “cmd” and not “state”.

state_topic: /XX:XX:XX:XX:XX:XX/devices/lights/<id>/state
command_topic: /XX:XX:XX:XX:XX:XX/devices/lights/<id>/cmd

I have another small problem: when I command the switch from the home assistant on the AVE app, the status changes while on the home assistant the status does not change, this happens because the AVE webserver does not return the status via the state_topic.
Has anyone solved this or are there other ways?

I think you’re AVE installation may have a different implementation of the mqtt service than the one I have. It is an undocumented feature, and could be changed by the developer as they want. For sure I didn’t have any firmware update from AVE since my installation.

So you’re on uncharted waters

I suggest you start testing as I did, start listening to any message sent on the mqtt (mosquitto_sub) and look if you can spot a pattern.

Or you can go the modbus way, which is documented by AVE. The HA modbus integration doesn’t fit properly with the AVE implementation, but you could hack you’re way. From the modbus HA integration you’ll use 2 tools:

  • sensor to listen and pull data from the ave server
  • modbus.write_register to issue a command

With the sensor you read the value of the device which will be different depending on the state (the relation value/state can be found in the document above); with the modbus.write_register service, you can write any value to the modbus device. You cobble these two togheter with the template integration and you’ll be fine.

For example I didn’t like the mqtt cover impletation I wrote, so I changed to a modbus one, using the cover template platform. Here an example of my configuration

- platform: template
      device_class: shutter
      unique_id: tapparella_studio
      friendly_name: Tapparella Studio
      value_template: "{{ states('input_select.tapparella_studio') }}"
      position_template: "{{ states('input_number.tapparella_studio') }}"
        service: script.command_cover
          address: 0x0211
          command: 0b01000
          entity_id: tapparella_studio
          new_state: opening
          new_position: 25
        service: script.command_cover
          address: 0x0211
          command: 0b10000
          entity_id: tapparella_studio
          new_state: closing
          new_position: 75
        service: script.command_cover
          address: 0x0211
          command: 0b11000
          entity_id: tapparella_studio
          new_state: open
          new_position: 50

the script configuration

  - service: modbus.write_register
      hub: ave
      address: '{{ address }}'
      unit: 0
      value: '{{ command }}'
  - service: input_number.set_value
      entity_id: input_number.{{entity_id}}
      value: '{{ new_position }}'
  - service: input_select.select_option
      entity_id: input_select.{{entity_id}}
      option: '{{ new_state }}'
  - delay:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 250
  mode: queued
  alias: command_cover
  max: 10

Be aware that these two yaml are not enough on their own, I also have a Node-Red flow which basically polls/listens for change in the modbus sensor and updates the helpers input_number and input_select accordingly. I think I could have done without the node-red part, but I did’t want to write an automation for each device.

Thanks for the quick answer. After establishing communication you create everything you can create with what you have available.
I can not understand the modbus addresses of the various sensors. Are these the ids assigned by the AVE server?

Yes, the ID are assigned by the AVE server. In the example above the device, a cover, has this adress in exadecimal:

You can read it splitting in two part:

  • the first two digit represent the family (02 means it is a cover)
  • the last two digits represent the id of the device (11 device number in exadecimal notation, which convert to 17 in decimal notation)

for example my modbus configuration looks like this:

  - name: ave
    close_comm_on_error: true
    type: tcp
    host: <ip adress of ave server>
    port: 502
    sensors: # list of all sensors
    - name: tapparella_studio
      address: 0x0211
      data_type: uint16

To retrieve the modbus address for each device there are at least 3 way that works for me:

  1. use the ave desktop app that loads download/upload the configuration of the server (I forgot the name, you have to look on the ave server)
  2. if you can ssh to the ave server, the configuration file shuld be located in /var/DPDdata/configuration.xml

In the configuraion.xml you can search your device by name and retrieve the modbus id; for example the entry for the tapparella_studio in xml file looks like this:

    <device id="6"> // this is the ID for mqtt
      <name>TP STUDIO</name> // name of the device in the AVE configuration
      <address>17</address> // this is the modbus address in base 10

The address is in base 10, so you need to translate to exadecimal value (17 → 0x11).


Is the integration you developed working with the AVE Wifi Mesh Smart Home system, or is it another AVE IoT product?

I’m looking at the documentation of their wifi mesh products, and I don’t think they need a hub, while in this thread I see mentions of a server.

Maybe the server is the root node of the mesh network?


I don’t know about that. I have Ave Domina Plus, which relies on a bus connection, hence the server.

1 Like

Hi, I’ve also this issue but I solved it by setting the flag optimistic: true on all switch entities, and leaving also the state topic with the correct value.
Doing like this you can have a false state just the first time, then with the optimistic flag enabled, HA doesn’t wait for a response so it work correctly.
The state topic remains useful because it register the light state change done with the physical switch or the official AVE application.