Autor Thema: neues Modul 66_EseraOneWire für den Esera 1-Wire Controller  (Gelesen 10597 mal)

Offline pizmus

  • Developer
  • Jr. Member
  • ****
  • Beiträge: 54
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #60 am: 02 Oktober 2019, 13:16:42 »
Die Probleme liegen in der TCP Verbindungsverwaltung. Das Modul verwendet https://wiki.fhem.de/wiki/DevIo für die Verbindungsverwaltung. Ich werde im ersten Schritt versuchen, die Kommunikation zwischen dem Modul und DevIo besser in der Log Datei darzustellen. Außerdem will ich die erfolglosen Initialisierungen los werden, die ohne Verbindung ohnehin nicht funktionieren können. Vielleicht sehen wir dann besser was passiert.
Deine Beobachtung, dass eine Neudefinition notwendig ist und ein Neustart nicht ausreicht, bedeutet wohl, dass das Problem im Zustand des FHEM Devices liegt, der einen Neustart überlebt und nur bei Neudefinition verschwindet. Das muss ich mir mal anschauen, was das sein könnte. Die nächsten Tage komme ich da leider nicht dazu. Kannst Du in der Zwischenzeit schon mal je ein „list“ für das Device im schlechten Zustand, nach einem Restart und nach einer Redefinition erzeugen?
Gruß,
pizmus

Offline Morgennebel

  • Hero Member
  • *****
  • Beiträge: 1391
  • Proud systemd-free zone
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #61 am: 02 Oktober 2019, 17:24:41 »
Seit heute morgen ist der Controller wieder mal disconnected.
Pings auf die IP gehen ganz normal auch mit normalen Antwortzeiten.

Klingt für mich nach Netzwerkproblemen.

Kannst Du mal den Output von mii-tool -v eth0 und ifconfig -a für die beteiligten Systeme posten?

Danke, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Offline maci

  • Full Member
  • ***
  • Beiträge: 487
  • ... und sie leben doch!
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #62 am: 03 Oktober 2019, 08:59:05 »
Die Probleme liegen in der TCP Verbindungsverwaltung. Das Modul verwendet https://wiki.fhem.de/wiki/DevIo für die Verbindungsverwaltung. Ich werde im ersten Schritt versuchen, die Kommunikation zwischen dem Modul und DevIo besser in der Log Datei darzustellen. Außerdem will ich die erfolglosen Initialisierungen los werden, die ohne Verbindung ohnehin nicht funktionieren können. Vielleicht sehen wir dann besser was passiert.
Deine Beobachtung, dass eine Neudefinition notwendig ist und ein Neustart nicht ausreicht, bedeutet wohl, dass das Problem im Zustand des FHEM Devices liegt, der einen Neustart überlebt und nur bei Neudefinition verschwindet. Das muss ich mir mal anschauen, was das sein könnte. Die nächsten Tage komme ich da leider nicht dazu. Kannst Du in der Zwischenzeit schon mal je ein „list“ für das Device im schlechten Zustand, nach einem Restart und nach einer Redefinition erzeugen?
Gruß,
pizmus

Sobald das Device wieder hängt, mache ich das.

Klingt für mich nach Netzwerkproblemen.

Kannst Du mal den Output von mii-tool -v eth0 und ifconfig -a für die beteiligten Systeme posten?

Danke, -MN
Netzwerkprobleme hatte ich auch schon vermutet, darum habe ich geschaut, dass kein Wlan "dazwischen" hängt.
Alles hängt an einem Switch der VLAN kann, da das Device in einem VLAN hängt.
Auch wenn der Testrechner im gleichen Netz hängt, hatte ich das Problem.
mii-tool kann ich nicht ausführen, da kommt ein Fehlermeldung am Raspberry Pi3 (Buster)
Beteiligte Systeme sind nur der Raspberry und der ESERA Controller.
pi@testfhem:~ $ ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.17  netmask 255.0.0.0  broadcast 10.255.255.255
        inet6 fe80::ba27:ebff:fead:d95d  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:ad:d9:5d  txqueuelen 1000  (Ethernet)
        RX packets 613588  bytes 43022601 (41.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 240835  bytes 17568463 (16.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Lokale Schleife)
        RX packets 9  bytes 524 (524.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 524 (524.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Raspberry Pi3, UniPi Vers. 1.1 mit Raspberry Pi2, Netatmo Wetterstation + Regenmesser, Netatmo Thermostat, 1x ESP8266 1wire WLAN Bridge, HMLan, 2x HMLANGateway, Homematic, 2x owserver,

Offline pizmus

  • Developer
  • Jr. Member
  • ****
  • Beiträge: 54
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #63 am: 03 Oktober 2019, 09:07:51 »
Ich habe eine neue Version mit veränderten Log Outputs bereitgestellt. Nachdem ich mir das nochmal angesehen habe, erwarte ich aber keine wirklich neuen Erkenntnisse davon. Du hast Verbindungsprobleme, die wahrscheinlich nicht im FHEM Modul zu lösen sind. Dein Log File sieht so aus, als ob die Verbindung mal kurz da war, aber dann wieder weg.

Offline maci

  • Full Member
  • ***
  • Beiträge: 487
  • ... und sie leben doch!
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #64 am: 03 Oktober 2019, 10:23:57 »
Ich habe schon alles an einem Switch hängen. Ich kann gerne ein eigenes abgekoppeltes Netz dafür aufbauen.
Nur ist das nicht das, was im Echtbetrieb vorzufinden ist.
Es hängt wie jetzt alles an einem Switch nur gibt es dann am Bestimmungsort später noch einen Switch, an dem der ESERA Controller hängt und ein LANGateway für Homematic.
Ich habe mit keinem anderen Gerät Probleme, ausgenommen hin und wieder mit meinen beiden ESPs. Aber das ist eine eigene Geschichte.

Ich habe vor 2 Tagen den ESERA Controller zurückgesetzt und neu konfiguriert und auch meinen Fhem Testserver mit Buster neu installiert.
Das nur um evtl. Probleme hier auszuschliessen.

Was ich hier ehrlich vermisse, dass ich hier kein Interval einstellen kann. bei meinem 1wire USB Gateway mit 16 DS18B20, das ich über OWX abfrage habe ich 300 sec (5 min) einstellt.
Hier bei Esera sind es 10 sec Abfragen.
Raspberry Pi3, UniPi Vers. 1.1 mit Raspberry Pi2, Netatmo Wetterstation + Regenmesser, Netatmo Thermostat, 1x ESP8266 1wire WLAN Bridge, HMLan, 2x HMLANGateway, Homematic, 2x owserver,

Offline Morgennebel

  • Hero Member
  • *****
  • Beiträge: 1391
  • Proud systemd-free zone
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #65 am: 03 Oktober 2019, 12:01:32 »
Ich habe schon alles an einem Switch hängen. Ich kann gerne ein eigenes abgekoppeltes Netz dafür aufbauen.

Ich tippe auf sowas wie defekten Switchport, defektes Patchkabel, Cat5-Kabel am Cat6-Switchport (wenn zu lang), auto-negotiation-Settings im Konflikt (einer will fest, einer will auto), oder fehlerhafte auto-Verhandlung (Switch port denkt 1000, Gerät denkt 10) usw.

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Offline Morgennebel

  • Hero Member
  • *****
  • Beiträge: 1391
  • Proud systemd-free zone
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #66 am: 03 Oktober 2019, 12:03:06 »
Was ich hier ehrlich vermisse, dass ich hier kein Interval einstellen kann. bei meinem 1wire USB Gateway mit 16 DS18B20, das ich über OWX abfrage habe ich 300 sec (5 min) einstellt.

It's not a Bug, it's a Feature.

https://www.esera.de/produkte/1-wire-smart-home/1-wire-controller-1-wire-gateway-intelligente-schnittstellen/

Zitat: Bis zu 30 1-Wire Bausteine können im Parasitär-Betrieb und Standardmodus im 1-2 Sekundentakt ausgelesen werden

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Offline pizmus

  • Developer
  • Jr. Member
  • ****
  • Beiträge: 54
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #67 am: 07 Oktober 2019, 08:32:02 »
Der Esera Controller erlaubt im Zusammenhang mit den Auslese-Intervallen zwei verschiedene Einstellungen:

POLLTIME: Dies ist das Intervall mit dem der Controller die angeschlossenen Sensoren abfragt. Erlaubt sind Werte zwischen 1 und 240 Sekunden. Für iButton gibt es einen Spezialmodus um noch deutlich bessere Reaktionszeiten zu erreichen. Der Controller verwendet aber ansonsten das gleiche Interval für alle angeschlossen Sensortypen. Das FHEM Modul verwendet für diese Einstellung 5 Sekunden.

DATATIME: Dies ist das Interval mit dem der Controller eine Liste mit Werten für alle 1-wire Devices an den Client schickt, in unserem Fall an das FHEM Modul. Wertebereich: 10 bis 240 Sekunden. Das FHEM Modul verwendet für diese Einstellung 10 Sekunden.

Warum gibt es zwei verschiedene Einstellungen? Bei bestimmten Typen von 1-wire Devices schickt der Controller zwischen den periodischen Updates (siehe DATATIME) noch weitere Updates. Wenn zum Beispiel ein Digitaleingang seinen Wert ändert wird das mit einem Abtastintervall von POLLTIME festgestellt, und es wird sofort ein Update an den Client geschickt. Es wird nicht auf das nächste DATATIME Intervall gewartet.

In Deinem Fall (mit ausschließlich Temperatursensoren?) kann Dir vermutlich die POLLTIME Einstellung egal sein. Der FHEM Host bekommt nichts davon mit, wie oft der Controller den 1-wire Bus abfragt. DATATIME ist für Deine Anwendung unnötig kurz. Wenn Du seltener Readings haben möchtest musst Du das zurzeit mit den Mitteln von FHEM reduzieren.

Es sollte kein allzu großer Aufwand sein, beide Einstellungen über das FHEM Modul konfigurierbar zu machen. Die Begrenzung auf einen Wertebereich bis 240 Sekunden würde ich an den FHEM Benutzer weiterreichen. Ich schaue mir das demnächst mal genauer an.

 

decade-submarginal