OWServer blockiert FHEM trotz nonblocking 1

Begonnen von hugomckinley, 20 September 2020, 21:09:33

Vorheriges Thema - Nächstes Thema

hugomckinley

Guten Abend,
nach ewigen Zeiten habe ich meinen ow-server-enet-2 wieder in Betrieb genommen.
Daran hängen 14 Devices (Zähler und Temperatursensoren).
Auf einer Debian VM läuft der OWServer(3.2p3) und dieser wird per OWServer-Modul von FHEM ausgelesen.
Leider blockiert FHEM trotz des Attributes nonblocking 1.
Ich komme trotz intensiver Recherche auf keinen grünen Zweig.
Hat wer einen Tipp für mich, wie ich dieses Problem lösen kann?

Im schlimmsten Fall tausche ich auch den ow-server-enet-2 gegen andere Hardware, wenn es sein muss, aber ich wüsste nicht was das bringen sollte.
Kann mir jemand auf die Sprünge helfen?

Verzweifelte Grüße,
Hugo

----------------------------------------------------
FHEM in TrueNAS-Jail
HMLGW + HM-Komponenten, alexa-fhem, Modbus/TCP, Modbus/RS485, LG-WebOS, Firmata, 1wire, ESP-RGBWW, DaikinAC per WLAN, Shellys, Denon AVR, Fronius WR, Helios Wohnraumlüftung, ...

synaps-o-dan

Hallo Hugo,
ich kann Dein Problem nicht direkt lösen, da ich selbst keinen OW-SERVER-ENET-2 im Betrieb habe (bei mir laufen 10 Devices über einen LinkUSB vom Fuchs-Shop. Ich hatte den eine Zeitlang auch über OWServer in fhem eingebunden mit der gleichen Erfahrung: trotz nonblocking stürzt fhem ab, wenn es eine Störung im OWServer gibt. Trotz viel Mühe konnte ich die Quelle der Störungen nicht beseitigen. Ich bin dann auf die OWX-Familie umgestiegen, und das hat meine Probleme nachhaltig gelöst. Falls die mit den OW-SERVER-ENET-2 unterstützen, könnte das die Lösung sein.
Aber mal was anderes: der OW-SERVER-ENET-2 bietet doch auch weitere Schnittstellen an, z.B. SNMP oder http. Darüber könntest Du ihn doch auch einbinden (mit den entsprechenden Modulen, die in fhem bereits zur Verfügung stehen). Dann könntest Du den OWServer ebenfalls umgehen.
Viele Grüße, Daniel
fhem auf Raspberry Pi 3
5 x Set aus jew. 1x FHT80B + 1xFHT8V + 1x FHT80TF-2
HM: 1 x HM-ES-PMSw1-Pl, 2 x HM-LC-Sw1-FM, 2 x HM-LC-Sw1PBU-FM, 3 x HM-Sec-SD, 2 x HM-PB-2-WM55, 2 x HM-Sec-MDIR-2
3 x EM-1000 EM
Onewire: insgesamt 11 Onewire-Sensoren an einem LinkUSB Adapter

hugomckinley

#2
Danke für den Hinweis mit SNMP, aber das war mir dann zu viel "Action" und zu wenig nativ 1wire ;-)
Darum habe ich mich noch etwas damit beschäftigt und ich glaube ich verstehe das Problem jetzt.

  • Alle/viele meiner 1wire Geräte haben den selben Intervall. Möchte ich auch beibehalten
  • Nonblocking führt zwar dazu, dass jeder Wert in einem eigenen Prozess gelesen wird, aber es werden alle Lesevorgänge durch das gleiche Intervall zur selben Zeit gestartet und somit blockiert FHEM für 14 x 1 Sekunde und nicht für einmal 14 Sekunden. Da diese Vorgänge unmittelbar nacheinander in der Queue von FHEM sind, ist der Effekt nahezu der selbe.
Da ich nicht (gut genug) programmieren kann sind meine Lösungsansätze evtl. etwas naiv:

1. Variante: Löst das Problem zwar nicht, aber verringert die Auswirkungen massiv: Ich habe den Intervall für alle Sensoren gleich gesetzt, jedoch mit etwas Abstand. Das führt dazu, dass jeder Sensor zwar im gleichen Abstand, aber versetzt zu den anderen gelesen wird und somit blockiert FHEM ca. 1-2 sec und dann können andere Vorgänge stattfinden, bis zum nächsten Sensor. Leider führt ein Neustart von FHEM dazu, dass wieder alle Sensoren gleichzeitig in die Queue kommen.
Hier würde schon ein Attribut wie alignTime bei at genügen.
2. Variante: Asynchrones Auslesen der Sensoren, vergleichbar mit nonPrioritizedSet bei ModbusAttr.

Ich weiß nicht wie naiv meine Überlegungen sind, aber wäre das denkbar, bzw. kann ich hier selbst etwas beeinflussen?

Grüße
Hugo
----------------------------------------------------
FHEM in TrueNAS-Jail
HMLGW + HM-Komponenten, alexa-fhem, Modbus/TCP, Modbus/RS485, LG-WebOS, Firmata, 1wire, ESP-RGBWW, DaikinAC per WLAN, Shellys, Denon AVR, Fronius WR, Helios Wohnraumlüftung, ...

synaps-o-dan

OK ich würde es eher so einschätzen, dass eine Überarbeitung von fhem-Modulen eine ziemlich heftige "Action" darstellt...
Kannst Du Deine Lösung hier kurz darstellen (wenn Du so weit bist), damit andere User davon lernen können?
Grüße, Daniel
fhem auf Raspberry Pi 3
5 x Set aus jew. 1x FHT80B + 1xFHT8V + 1x FHT80TF-2
HM: 1 x HM-ES-PMSw1-Pl, 2 x HM-LC-Sw1-FM, 2 x HM-LC-Sw1PBU-FM, 3 x HM-Sec-SD, 2 x HM-PB-2-WM55, 2 x HM-Sec-MDIR-2
3 x EM-1000 EM
Onewire: insgesamt 11 Onewire-Sensoren an einem LinkUSB Adapter

hugomckinley

Eine ursächliche Lösung des Problems habe ich nicht. Meine "Lösung" ist der Umstieg auf einen Arduino mit Ethernetshield und FirmataConfigurable.
Leider habe ich diese Lösung vor 5 Jahren als ich den OW-Server gekauft habe noch nicht gekannt und somit ist der OW-Server im Nachhinein als Fehlkauf zu beurteilen.
Denn die Arduino-Lösung ist deutlich günstiger, hat weitere Funktionen, die ich gut brauchen kann (ADC, I/O-Pins, mehr 1wire Kanäle) und lässt sich bis auf ein lösbares Problem(https://forum.fhem.de/index.php/topic,114710.0.html) gut asynchron betreiben.
1wire-Devices, die asynchron gelesen werden, benötigen laut apptime ca. 180ms, die vier parasitären Sensoren leider noch immer ca. 1,2 sec.
Das führt manchmal (bei unglücklichem Zusammentreffen mehrerer Lesevorgänge) leider dazu, dass sich mein HM-LGW neu verbindet und somit kurz ausfällt.
Von der stockenden Bedienung von FHEM mal abgesehen. Wenn es nicht ein Problem mit der Versorgungsspannung ist, muss ich im schlimmsten Fall diese 4 Temperatursensoren gegen Spannungsversorgte tauschen, denn dann kann ich diese auch asynchron betreiben und habe wieder etwas Luft.

Gruß,
Hugo

P.S.: Ich habe das mit SNMP kurz versucht, habe dann aber mit dem Auslesen der OIDs Schwierigkeiten gehabt und bin dann auf Firmata gestoßen.
----------------------------------------------------
FHEM in TrueNAS-Jail
HMLGW + HM-Komponenten, alexa-fhem, Modbus/TCP, Modbus/RS485, LG-WebOS, Firmata, 1wire, ESP-RGBWW, DaikinAC per WLAN, Shellys, Denon AVR, Fronius WR, Helios Wohnraumlüftung, ...

synaps-o-dan

Zwei Fragen (leicht OT):

  • Hast Du irgendwo ein Tutorial oder eine Anleitung (für Laien), die erklären, wie man so einen Arduino mit Ethernetshield und Firmata aufbauen kann?
  • Wärest Du interessiert, den OW-Server zu verkaufen?

Grüße, Daniel
fhem auf Raspberry Pi 3
5 x Set aus jew. 1x FHT80B + 1xFHT8V + 1x FHT80TF-2
HM: 1 x HM-ES-PMSw1-Pl, 2 x HM-LC-Sw1-FM, 2 x HM-LC-Sw1PBU-FM, 3 x HM-Sec-SD, 2 x HM-PB-2-WM55, 2 x HM-Sec-MDIR-2
3 x EM-1000 EM
Onewire: insgesamt 11 Onewire-Sensoren an einem LinkUSB Adapter

hugomckinley

Ich habe mir ein paar Arduino Nanos bestellt und passende Ethernet-Shields. Sobald die da sind kann ich die in Betrieb nehmen und eine Doku schreiben. Ich werde das dann im Wiki hinzufügen. Jetzt ist es ein Arduino Uno mit einem Ethernet Shield 2.

Bezüglich OW-Server: Ja, den kannst du gerne haben. Schreib mir eine PM.

Grüße,
Hugo
----------------------------------------------------
FHEM in TrueNAS-Jail
HMLGW + HM-Komponenten, alexa-fhem, Modbus/TCP, Modbus/RS485, LG-WebOS, Firmata, 1wire, ESP-RGBWW, DaikinAC per WLAN, Shellys, Denon AVR, Fronius WR, Helios Wohnraumlüftung, ...

Prof. Dr. Peter Henning

Achtung: 1-Wire via Firmata steht vor massiven Änderungen. Einerseits nötig wegen des Firmata-Devices, anderseits muss das in der OWX-Anbindung noch nachgezogen werden. Tipp: Wenn es vor dem nächsten Wochenende läuft, alles mit exclude_from_update erst einmal schützen.

LG

pah

hugomckinley

----------------------------------------------------
FHEM in TrueNAS-Jail
HMLGW + HM-Komponenten, alexa-fhem, Modbus/TCP, Modbus/RS485, LG-WebOS, Firmata, 1wire, ESP-RGBWW, DaikinAC per WLAN, Shellys, Denon AVR, Fronius WR, Helios Wohnraumlüftung, ...


Guybrush

Auch wenn der Thread schon etwas älter ist - ich hatte auch das Problem, dass die Einbindung meiner 17 1-Wire Sensoren, die an einem OW-Server ENET V2 hängen, dazu führte, dass FHEM unerträglich langsam wurde. Das Nonblocking 1 half etwas, aber FHEM war trotzdem noch träge. Da mir das Forum hier oft schon alleine durchs lesen half, teile ich gerne einmal meinen Lösungsansatz:

Das Problem hierbei ist zunächst, dass das FHEM Modul nicht auf nonblocking I/O ausgelegt ist. Das eigentliche Problem ist aber, dass die Abfrage der Sensorwerte auch über die Shell mittels "owread <pfad>/<wert>" selbst teilweise Sekunden dauert. 1-Wire ist zwar sehr günstig, aber eben nicht performant... In Verbindung mit dem fehlenden nonblocking I/O hängt dann FHEM jedenfalls. Das liegt daran, dass Default nur sehr niedrige Cache Werte gesetzt sind, so dass Abfragen dann faktisch immer auf den unperformanten 1-Wire Bus warten müssen. Da ich aber keine Lust/Zeit habe selbst eine Nonblocking Abfrage für OWServer zu entwickeln und dies auch das eigentliche Problem nicht wirklich lösen würde, habe ich mir das wie folgt gelöst.

fiktive Annahme:
FHEM läuft auf 192.168.1.1
OW-Server Enet2 auf 192.168.1.2


1. OWServer lokal installiert und dort den OW-Server Enet2 (oder alternativ die jeweils genutzte Schnittstelle) eingebunden
apt-get install owserver ow-shell

/etc/owfs.conf anpassen

! server: server = localhost:4304
server: enet = 192.168.1.2:8080 #Ersetzen durch eigene IP:Port oder entsprechend andere Sources
http: port = 2121
ftp: port = 2120
server: port = localhost:4304

# Default sind 15-60 Sekunden, was viel zu wenig ist.
timeout_ha7 = 600
timeout_server = 600
timeout_volatile = 600


2. OWServer in FHEM konfiguieren

defmod OWServer OWServer localhost:4304
attr OWServer nonblocking 1


dann noch die 1-Wire Sensoren anlegen, die aber normal per autocreate schon angelegt werden. Ich hab hier folgende Attribute jeweils gesetzt:

defmod Heizung.WWS.Ruecklauf.Temperatur OWDevice 28.1111111111 60
attr Heizung.WWS.Ruecklauf.Temperatur DbLogInclude temperature
attr Heizung.WWS.Ruecklauf.Temperatur event-min-interval .*:300
attr Heizung.WWS.Ruecklauf.Temperatur event-on-change-reading .*:0.5
attr Heizung.WWS.Ruecklauf.Temperatur model DS18B20
attr Heizung.WWS.Ruecklauf.Temperatur room Heizung
attr Heizung.WWS.Ruecklauf.Temperatur stateFormat [$name:temperature:r1] °C


3. Aktualisierung des Caches erzwingen
OWServer cached alle empfangenen Values für die über timeout_*** angegebenen Werte. Die Defaultwerte sind zu niedrig. Dadurch bringt das Caching für FHEM faktisch nichts. Setzt man die Timeouts aber einfach nur hoch, erhält man keine aktuellen Values mehr. Ich hab mir das aber zu Nutze gemacht, dass man beim OWServer 1-Wire Values gecached und uncached abfragen kann. FHEM liest ausschließlich die cached Values aus. Das schöne an einer Abfrage der uncached Values ist, dass diese das Result direkt cachen. Also habe ich die Blocking I/O von FHEM in ein einfaches Shellskript verlagert:


#!/bin/bash

PIDFILE=/tmp/owread.pid

if [ -f $PIDFILE ]
then
  PID=$(cat $PIDFILE)
  ps -p $PID > /dev/null 2>&1
  if [ $? -eq 0 ]
  then
    echo "Process already running"
    exit 1
  else
    echo $$ > $PIDFILE
    if [ $? -ne 0 ]
    then
      echo "Could not create PID file"
      exit 1
    fi
  fi
else
  echo $$ > $PIDFILE
  if [ $? -ne 0 ]
  then
    echo "Could not create PID file"
    exit 1
  fi
fi

# hier editieren und Pfade durch Sensoradressen ersetzen
owread /uncached/28.111111111111/temperature
owread /uncached/28.222222222222/temperature
owread /uncached/28.333333333333/temperature
# /edit

rm $PIDFILE



Dieses Bash Skript wird dann über cron.d minütlich ausgeführt. Das führt dann dazu, dass FHEM fortan die 1-Wire Werte über OWServer ohne Verzögerung auslesen kann, da die Cached Values nun für 10 Minuten vorgehalten, die Werte aber dennoch minütlich aktualisiert werden. Das führt faktisch zu einem permanent Cache. Die Blocking I/O bleiben zwar auf dem Server. Allerdings blockieren diese nicht mehr FHEM, sondern nur noch das Bash Skript. Da das keine Systemlast erzeugt und das Skript nichts anderes als das macht, ist das aber zu verschmerzen.

Das ist sicherlich nicht die "schönste" Lösung, aber mutmaßlich die einfachste. Jedenfalls fand ich hier im Forum keine andere und außer dem fiel mir nichts anderes ein, ohne selbst was entwickeln zu müssen. Vielleicht hilfts ja jemandem :)


dieter114

Hallo Guybrush,

noch ein paar Fragen dazu:
Wie sieht die cron.d dazu aus und wo muss das bash.script reinkopiert werden.
Wie ist das mit DS2401 Modulen? Ich verwende die für Zustandserkennungen Fenster etc.
müssen die auch im Bash.scrit aufgeführt werden?

Entschuldige die "anfängerfragen" aber meine Linux Kenntnisse sind wirklich nicht weit entwickelt....

Gruß WDS
RPi II+III+IV,OWX,div.1W Module,HM Zisterne,div. CUL, sduino MAPLEMINI, div ESPEasy, div Tasmota, MQTT2Server,WU-Upload,TabletUI, Indego,Poolsteuerung mit fhem

Guybrush

In deinem Verzeichnis /etc/cron.d/ sollten Dateien vorhanden sein, an denen du dich orientieren kannst. Grundlegend legst du dort eine eigene an, die du beliebig benennen kannst und trägst da das bashscript ein. Zu dem Thema gibts aber wirklich tonnenweise Howtos. Grad mal schnell google benutzt und die Seite hier zb gefunden: https://geekflare.com/de/crontab-linux-with-real-time-examples-and-tools/

Welche 1Wire Sensoren du nutzt ist vollkommen egal, da es um die Funktionsweise des 1 Wire Bus als Ganzes geht. Du musst eben nur die richtige 1Wire Adresse eintragen. Grundsätzlich solltest du alle 1 Wire Adressen in das skript eintragen, da fhem bei jeder einzelnen Adresse geblockt werden kann, wenn die Abfrage auf Rückmeldung des 1 Wire Bus warten muss und nur so alles dauerhaft im Cache vorhanden ist. Wenn du die nicht kennst, dann nutz dafür tools wie owhttpd (apt-get install owhttpd). Die Adressen tauchen direkt im root auf.

Guybrush

Da mein hier vorgestellter Workaround die wait I/O nicht gänzlich verhinderte - beispielsweise wenn zeitgleich mit der Abfrage der uncached Values eine Abfrage auf das OW Device erfolgte - habe ich nun eine komplette Trennung vorgenommen. Ich habe jetzt die gesamte OWServer Implementation aus FHEM entfernt und alle OWDevices gelöscht und mit gleichen Namen als Dummy Device identisch neu angelegt. Die Aktualisierung der Werte erfolgt nun nur noch durch ein externes Perl Skript, welches über einen cronjob minütlich gestartet wird. Das Shellskript ruft dann FHEM über die Http Schnittstelle auf und aktualisiert so die Werte. Das mag nicht im Sinne der Erfindung sein, aber solang das OWServer Modul nicht auf Nonblocking ausgelegt ist, ist es meiner Meinung nach nur eingeschränkt für die Abfrage vieler 1Wire Sensoren geeignet.

Hier das Shell Skript für alle, die ähnliche Performance Probleme durch die 1Wire Einbindung in FHEM haben:

#!/usr/bin/perl -l
use strict;
use warnings;
use LWP::UserAgent;

my %devices = (
                "/28.AAAAAA040000/temperature", "Heizung.WWS.Temperatur",
                "/28.BBBBBB040000/temperature", "Heizung.WWS.Vorlauf.Temperatur",
                "/28.CCCCCCC40000/temperature", "Heizung.WWS.Ruecklauf.Temperatur"
                );

my $ua = new LWP::UserAgent;
my $hosturl = "http://localhost:8083/fhem?XHR=1";
my $result = $ua->get($hosturl);
$hosturl.= "&fwcsrf=$result->header("X-FHEM-CsrfToken")";

while ((my $address, my $device) = each(%devices))
{
        print "$address => $device";
        my $OWValue = `owread $address| sed -r 's/( )+//g'`;
        print "set $device $OWValue";
        $ua->get($hosturl."&cmd=set%20$device%20$OWValue");
}


Die OWDevices werden im Array %Devices in der Form OW Adresse -> FHEM Device konfiguiert. der aus der OW Adresse ausgelesene Wert wird dementsprechend in das entsprechende FHEM Device geschrieben. Ich hab das mal auf 3 Beispiele runtergebrochen. Bei mir sind mittlerweile ca 40 1-Wire Sensoren verbaut, was auf diese Weise gut funktioniert. $Hosturl auch prüfen, dass unter der dort angegebenen Adresse euer FHEM Server erreichbar ist.

Wenn jemand Verbesserungsvorschläge hat, gerne her damit!

Prof. Dr. Peter Henning

ZitatWenn jemand Verbesserungsvorschläge hat, gerne her damit!

Klar. OWX und OWTHERM verwenden.

LG

pah

Guybrush

ich habe beide nicht ausprobiert. Wie wird denn da die Abfrage gehandelt? Ist das echtes non blocking dort?

Weiß jetzt nicht, ob ich das jetzt nochmal anfass. Funktioniert ja so sehr gut, auch wenn ein single point of configuration wesentlich vorteilhafter wäre

Wernieman

Oder anstatt telnet mit MQTT versenden .... ;o)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Prof. Dr. Peter Henning

ZitatWie wird denn da die Abfrage gehandelt? Ist das echtes non blocking dort?
Direkt vom physikalischen Gerät.Ja.

pah