Just wanted to say my modbus is working again with 2021.7.4. And actually better/more reliable than it ever did before. Don’t know if it is some kind of coincidence or something changed with my wifi or something else. But there you go.
1 Like
So i switched back to the original scaling of 0.01
so you can see
- the day before the update to 2021.7.4
- the with crazy high values - i deleted them from the timeseries btween 9:00 and 10:30 then hat the 0.000001-scaling in place
- yesterday with the 0.1-scaling and a complete raspberry-reboot
what i can not wrap my head around is:
- what is the correct scaling now?
- have there been changes in the processing of recieved values?
- how are there even negativ values?
i never had negative values before:
for today - to have a reference - i will downgrade to 2021.6.6 again…
i consider purchasing another raspy as a staging- an testing-unit
any other ideas??
Silly me… the config still had
reverse_order: true
instead of the new swap-command…
so i read the wrong values…
thanks for the hint. changed now from
reverse_order: true
to
swap: word
everythins fine now 
I just got my wallbe Eco 2.0 (without “S”) installed today but have troubles setting it up in in hass. Would you mind sending the working config incl. sensors for yours? Seems I’m using an old outdated syntax or something that is not accepted but also not throwing an error.
Thanks,
Tobias
Hello
My lines in configuration.yaml are:
modbus:
- name: varta
close_comm_on_error: true
delay: 5
timeout: 5
type: tcp
host: 192.168.0.14
port: 502
retry_on_empty: true
retries: 10
sensors:-
name: ‘Scheinleistung’
address: 1067
unit_of_measurement: W -
name: ‘Netz’
address: 1078
unit_of_measurement: W
count: 1
slave: 1
-
regards; Dieter
Thanks a lot! Seems I was just using an old, outdated syntax. Working perfectly now - see this post.
Tobias
I have the following configuration that was working with 2021.6.6 (if not mistaken) and worked perfectly until I upgraded to the latest (2021.8.8) and stopped receiving data from the registers.
- name: victron
type: tcp
host: 192.168.1.XX
port: 502
I’ve followed some of the recommendations here and upgraded my configuration to include some new properties
- name: victron
type: tcp
host: 192.168.1.XX
port: 502
close_comm_on_error : false
delay : 2
retries: 10
retry_on_empty: true
But still no success, unable to fetch data from the victron GX device.
nevermind, after updating to the new syntax (sensors below modbus definition) and replacing registers to address did fix it.
I just upgraded from 4.4 to 9.3 and my connection to victron inverter is no longer working
My configuration.yaml section is below with the added 4 lines for delay and such, all my sensors are defined in rv.yaml which is included.
All my sensor are showing “Entity not available”
# Example configuration.yaml entry for a TCP connection
modbus:
name: VenusGX
type: tcp
host: 10.0.0.187
port: 502
delay: 5
close_comm_on_error: false
retry_on_empty: true
retries: 10
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
# sensors included by directory
sensor: !include_dir_merge_list sensor/
# switches included by directory
switch: !include_dir_merge_list switch/
I was able to get one test entry to work by moving it from my included rv.yaml file
Is it still possible to use an included file to define all the sensors?
modbus:
- name: VenusGX
type: tcp
host: 10.0.0.187
port: 502
delay: 5
close_comm_on_error: false
retry_on_empty: true
retries: 10
sensors:
- name: "Soc"
data_type: uint
unit_of_measurement: "%"
slave: 245
address: 266
scale: 0.1
precision: 1
did you put the modbus name into each sensor-entity definition?
ie
sensors:
- name: xyz
hub: <name of modbus entity>