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 
P.S.
(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:
modbus.write_register to issue a commandWith 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
covers:
tapparella_studio:
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') }}"
open_cover:
service: script.command_cover
data:
address: 0x0211
command: 0b01000
entity_id: tapparella_studio
new_state: opening
new_position: 25
close_cover:
service: script.command_cover
data:
address: 0x0211
command: 0b10000
entity_id: tapparella_studio
new_state: closing
new_position: 75
stop_cover:
service: script.command_cover
data:
address: 0x0211
command: 0b11000
entity_id: tapparella_studio
new_state: open
new_position: 50
the script configuration
command_cover:
sequence:
- service: modbus.write_register
data:
hub: ave
address: '{{ address }}'
unit: 0
value: '{{ command }}'
- service: input_number.set_value
target:
entity_id: input_number.{{entity_id}}
data:
value: '{{ new_position }}'
- service: input_select.select_option
target:
entity_id: input_select.{{entity_id}}
data:
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:
02 means it is a cover)11 device number in exadecimal notation, which convert to 17 in decimal notation)for example my modbus configuration looks like this:
modbus:
- 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:
/var/DPDdata/configuration.xmlIn 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
<family>3</family>
<address>17</address> // this is the modbus address in base 10
<line>0</line>
<branch>0</branch>
<subbranch>0</subbranch>
The address is in base 10, so you need to translate to exadecimal value (17 → 0x11).
Ciao!
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?
Thanks!
I don’t know about that. I have Ave Domina Plus, which relies on a bus connection, hence the server.
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.