Einbinden eines Modbus-Schalters

Integrationen
1

Ich habe eine Anzahl von Schaltsteckdosen, die über Modbus TCP geschaltet und abgefragt werden können. Ich versuche nun, die über die YAML-Konfiguration HA beizubringen - scheitere aber zunächst.

In configuration.yaml habe ich eine Zeile switch: !include switch.yaml eingebaut, weil ich die Bastelei in einer anderen Datei veranstalten möchte.

Die Datei switch.yaml sieht so aus:

- platform:  modbus
  name: Treppenlicht
  type: tcp    
  host: 192.168.178.47
  port: 502
  slave: 1

  switches:
    name: Schalter
    address: 0
    write_type: holding
    command_on: 1
    command_off: 0
      
  binary_sensors:
    name: "Treppenlicht"
    address: 0
    scan_interval: 20
    input_type: holding

Sie wird syntaktisch akzeptiert, ich finde aber nirgends in HA die darin vorgenommenen Einträge. Irgendwie habe ich die Hierarchie noch nicht richtig verstanden, fürchte ich. Ich war davon ausgegangen, dass sich die Definition irgendwie als Schalter “Treppenlicht” finden würde.

Wie muss ich das angehen?

2

Das sollte ehr modbus: !include modbus.yaml wenn ich mir die Doku richtig angucke:

Und on und off Command musst du nicht setzen für 1 und 0:

command_on integer (optional, default: 1)
Value to write to turn on the switch.

command_off integer (optional, default: 0)
Value to write to turn off the switch.

Die modbus.yaml müsste dann ungefähr so aussehen:

- type: tcp
  host: 192.168.178.47
  port: 502
  name: Treppenlicht
  switches:
    - name: Schalter
      address: 0
      write_type: holding
  binary_sensors:
    - name: Treppenlicht
      address: 0
      scan_interval: 20
      input_type: holding

hoffe das funktioniert so, habe selber nichts mit Modbus.

Edit:
Du kannst aber auch gleich ein Licht konfigurieren.

LG
Tobi

3

Uh, da geht es rund mit:

grafik
grafik1037×244 58.7 KB

4

Was er für eine Problem hat mit type: tcp weiß ich nicht weil so steht es in der Doku. baudrate, bytesize, method, parity, stopbits brauchst du nur bei type: serial und zeigt er wohl an da er mit type: tcp ein Problem hat.

Wenn ich es bei mir in die Config einfüge hat er keine Probleme (klick für Bilder)

image
image

image
image1077×267 19.2 KB

Also muss bei dir irgendwo ein Fehler sein, nochmal gucken ob du überall richtig eingerückt hast usw. da ist yaml sehr empfindlich.

LG
Tobi

6

Ja, akzeptieren tut er das bei mir auch - syntaktisch also okay. Aber da taucht nirgends ein Gerät, eine Entität oder so was auf in HA…

Nachtrag:
In der Homeassistant-App kann ich ein Widget mit der Entity “switch.schalter” anlegen, das aber nichts tut. Bekannt ist das Ding also doch irgendwie.

Okay…

Nächster Versuch [2]

modbus.yaml:

  - name: Treppenlicht
    type: rtuovertcp
    host: 192.168.178.47
    port: 502
    lights:
      - name: Treppenlicht
        device_address: 1
        address: 1
        write_type: holding
        unique_id: TreppenlichSW
        verify:
          input_type: holding
          address: 1

Führt zu einer Entität:

grafik
grafik1359×49 2.2 KB

…die aber “Unavailable” bleibt.

Logger: homeassistant.components.modbus.modbus
Quelle: components/modbus/modbus.py:331
Integration: Modbus (Dokumentation, Probleme)
Erstmals aufgetreten: 16:46:15 (1 Vorkommnisse)
Zuletzt protokolliert: 16:46:15

Pymodbus: Treppenlicht: Error: device: 1 address: 1 -> Modbus Error: [Input/Output] ERROR: No response received after 3 retries

Ich kann das Gerät von der Shell aus sehen:

PING 192.168.178.47 (192.168.178.47) 56(84) bytes of data.
64 bytes from 192.168.178.47: icmp_seq=1 ttl=255 time=7.19 ms
64 bytes from 192.168.178.47: icmp_seq=2 ttl=255 time=3.36 ms
64 bytes from 192.168.178.47: icmp_seq=3 ttl=255 time=3.87 ms
64 bytes from 192.168.178.47: icmp_seq=4 ttl=255 time=3.00 ms
^C
--- 192.168.178.47 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 3.002/4.355/7.189/1.665 ms

Auf meinem PC antwortet es auch:

$ ./SyncClient 192.168.178.47:502:1 1 1
Using 192.168.178.47:502:1 @1/1
[N] Response: @5EB382E90EF0/5:
  | 0000: 01 03 02 00 00                                    |.....

Im Log des Geräts sieht man auch die erfolgreichen Zugriffe - vom HA sieht man gar nichts:

[I] 3805603265| main.cpp             [ 496] SetState: Switch ON
Event: Modbus on            17:01
17:01:49  ON 0:00:05 | Run 1056:53:45 | ON 45:30:05
9

Ich habe mich jetzt von meiner Proxmox-Installation getrennt und den Raspi dediziert mit HAOS neu aufgesetzt, in der Hoffnung, dass es sich um ein Netzwerkproblem der Virtualisierung handeln könnte.

Dem ist leider nicht so, auch unter nativem HAOS kommt

2024-06-07 14:33:34.682 ERROR (MainThread) [homeassistant.components.modbus.modbus] Pymodbus: Treppenlicht: Error: device: 1 address: 1 -> Modbus Error: [Input/Output] ERROR: No response received after 3 retries
2024-06-07 14:34:25.524 ERROR (MainThread) [pymodbus.logging] Cancel send, because not connected!

Kann ich irgendwie ausgeben lassen, was genau pymodbus da an wen schicken will?

Nachtrag:

Ich habe mir die inetutilsim Container installiert und festgestellt:

  • ich kann die Modbusgeräte anpingen
  • ich kann sogar eine telnet-Session darauf öffnen
  • im tcpdump tauchen die Geräte nie auf. Weder in ARP- noch in IP-Paketen.
  • dort sehe ich eigentlich nur mDNS-Multicasts meiner Repeater und der Fritzbox, sowie die Pakete zu meinem Endgerät, mit dem ich auf HA zugreife.

Da muss also irgendwas in HA selber fehlen, was die Verbindung überhaupt erst versucht.

Nachtrag2:
Im Augenblick sieht es für mich so aus, als wäre die Modbus-Integration in HA seit einigen Versionen schadhaft. Es gibt im Core-Github einige Issues dazu, nur sind die Entwickler bisher nicht geneigt, die schon als Anlass zur Suche zu nehmen :slightly_frowning_face:

Das Fehlerbild ist immer ähnlich: bestehende Entities laufen nach wie vor, neu definierte sind nicht kontaktierbar.

:pencil2: by tarag: Beiträge zusammengeführt

10

Der Fehler saß vor der Tastatur. :roll_eyes:

Ich hatte als type: rtuovertcp gesetzt, weil ich den Eindruck hatte, dass bei TCP die Angabe einer device_address nicht akzeptiert wurde.

Das führte dazu, dass HA immer eine RTU-Prüfsumme an die Pakete anfügte, die dann den TCP-Server zum Abweisen des Requests zwang.

Mit type: tcp geht es jetzt und natürlich akzeptiert HA auch eine device_address…

Warum ich die Pakete nicht im TCP-Dump gefunden habe, weiß der Himmel. Vielleicht gehen die nicht über das im Container sichtbare Interface eth0?