Updates für Module in contrib (hier: 58_GPIO4)

[Adimarantis]

Hallo,

Als Nutzer des GPIO4 Moduls aus contrib hat mich eine gelegentliche Fehlermeldung gestört (die nur bei stacktrace=1 auftaucht).
Beim fixen des Fehlers komme ich gerade von einem zum nächsten da das Modul sehr häufig auf FHEM internals zugreift oder wahrscheinlich obsolete APIs sowie die alte Log Methode verwendet. Manche Dinge die der Autor wohl vorgesehen hatte, funktionieren nicht einmal mehr oder sind ohne Funktion. Naja das Copyright ist von 2012.
Den Autor hatte ich schon von 1-2 Wochen angeschrieben (Email Adresse war im header), aber keine Antwort erhalten.

Fragen:
- Ist unter den Umständen ein update in Contrib ok? Oder sollte das ggf. sogar nach FHEM wenn es soweit auf Vordermann gebracht wurde (Temperatur Sensoren am 1Wire Bus sind schon irgendwie eine Standardfunktionalität)
- Oder macht es Sinn das Modul dann auch gleich umzubenennen (GPIO4 ist ja durchaus richtig, aber RPI_1WIRE fände ich deutlich sprechender - analog zu RPI_GPIO)

Danke schon mal fürs Feedback,
Jörg

[rudolfkoenig]

Contrib ist nicht so streng geregelt wie FHEM/*, das ist auch Sinn dieses Ordners.
Wenn der Autor nicht reagiert, dann sehe ich keinen Grund, warum man die Datei nicht aendern (und/oder Umbenennen) sollte.

[KölnSolar]

Hi Jörg,

da kann ich Dir nur beipflichten.

Du solltest diese Version als Basis nehmen, da gegenüber der contrib-Version eine Menge Änderungen über die Jahre zusammengekommen sind.

Modulnamenänderung fänd ich nicht so gut, weil von vielen seit Jahren genutzt. Wenn Du an Dinge wie z.B. Umstellung auf Log3 rangehst, sehe ich keinen Grund das Modul nicht offiziell per update zu verteilen. 

Grüße Markus

[Adimarantis]

Hi Markus,

ok. ich kenne jetzt nur das contrib Modul.
Die Änderungen habe ich mir mal angesehen und da sind devices dazu gekommen die ich nicht habe/kenne (und wozu braucht man ein Memory/Counter Modul in FHEM?) - den Switch verstehe ich ja noch.

Desweiteren dieser BlockingCall Mechanismus mit den konkurrierenden Devices - gabs da Probleme? Meine 10 Temperatursensoren frage ich ganz normal ab und hatte keine (offensichtlichen) Konflikte - aber ich frage auch nur alle 5 Minuten ab. Hier ständig zu forken gefällt mir nicht wirklich.

Jörg

[KölnSolar]

Hi Jörg,

Meine 10 Temperatursensoren frage ich ganz normal ab und hatte keine (offensichtlichen) Konflikte -

Es sind keine Konflikte, sondern die Messung dauert einfach um eine Sekunde(habs nicht genau im Kopf) herum u. solange ist FHEM blockiert.

Grüße Markus

[Adimarantis]

Ja stimmt. Etwa 900ms.
Das kann man allerdings deutlich beschleunigen indem man die precision von 12 auf 9 runterdreht (dann sind es 190ms).
So ungenau wie die ohnehin messen sollte das kein Problem sein - nur ist das device file standardmäßig nur für root schreibbar. Hab ein bisschen gegoogelt aber nichts dazu gefunden, wie man die default permissions des device files auf user-writable setzen kann (ein chmod geht, aber das dürfte keinen reboot überleben und für neue devices hilft es sowieso nichts).
Hab auch schon mit open/select loop/read rumgespielt, aber letztendlich wird immer das read blockiert.

Andere Ideen?

Jörg

[KölnSolar]

BlockingCall.  Funktioniert bestens. Ansonsten sub_process od. co_process. Mir fehlte aber bisher die Zeit das anzusehen/umzusetzen.

Das kann man allerdings deutlich beschleunigen indem man die precision von 12 auf 9 runterdreht (dann sind es 190ms).

Deshalb hab ich die Funktionalität eingebaut. Mit 9(10)wird es aber schon arg ungenau(je nach Anwendung).

Bedenke: Du misst alle 5'. Bei meinen ca. 15 Sensoren messe ich tw.(Heizungssteuerung) mit Abstand 5".

Grüße Markus

[Beta-User]

@Arduino kenne ich das so: Man setzt den Befehl zum messen ab (geht afair "one shot" an alle DS18x20 auf dem Bus), läßt die loop non-blocking weiterlaufen und schaut dann mit millis, ob die conversion-time abgelaufen ist (je nach gesetzter Auflösung bis zu 750ms). Dann kann man das scratchpad auslesen.
Klingt für mich nach einem einfachen InternalTimer-Aufruf. Aber vermutlich übersehe ich mal wieder was...?

Wenn das klappt, könnte man das vermutlich sogar so machen, dass man zwischen den einzelnen Busteilnehmern auch FHEM nochmal zu Wort kommen läßt (müßte dann halt entsprechend weitere Timer setzen, bis alles durch ist)...

[KölnSolar]

Aber vermutlich übersehe ich mal wieder was...?

Yes. Das open oder read file lösen die Messung aus und dann ist halt bis Messende alles blockiert.Da gibt es keinen Weg....

[rudolfkoenig]

Koenntest Du das uns bitte mit einem "strace -tt" zeigen?

[KölnSolar]

Das war die Diskussion vor einem Jahr

Parallel die Diskussion zum Thema "Prozess-Auslagerung".

Brauchst Du noch strace(wie auch immer ich das anstelle  ) oder hat sich das damit erledigt ?

Grüße Markus

[Beta-User]

Sorry für die Frage, das ist ja echt übel, was das OS (?) da treibt...
[OT]Hatte ich schon erwähnt, das PI-GPIO gruselig sind...?[/OT]

[rudolfkoenig]

Das war die Diskussion vor einem Jahr

Das habe ich jetzt wieder durchgelesen, aber da steht weder, dass open blockiert, oder dass select nicht funktioniert.
Ich gehe davon aus, das open nicht blockiert (was uns wiederum strace erspart), und dass select funktioniert, mit oder ohne timer. D.h. wenn das Modul von vielen verwendet wird, dann lohnt sich ein Umbau, weg von BlockingCall/etc zu select.

Off-Topic: strace unter Linux hilft, wenn man nicht so recht weiss, warum ein Programm nicht funktioniert (z.Bsp. Fehlermeldung daemlich, Programm haengt, etc). Wenn man oefters solche Probleme hat, dann lohnt sich die Einarbeitung.

[Adimarantis]

Hi,

ich habe das mal durchprobiert.
Das Open blockiert nicht, stösst aber leider die Conversion nicht an. Ein select kommt trotzdem gleich zurück, aber wenn ich dann den read mache, ensteht dort die Wartezeit.
Dachte noch, dass ich vielleicht zu schnell bin, und hab an mehreren Stellen sleep(1) eingebaut, aber es bleibt dabei: das read() braucht 900ms

Eine option gibt es noch:
Wenn man

Code: [Auswählen]

echo trigger >therm_bulk_read im busmaster macht, dann werden die conversions bei ALLEN slaves gleichzeigt angestossen. (das ist eine recht neue Funktion, gibt es seit ca. Mitte 2020)
Man kann das in therm_bulk_read auch abfragen ob alle fertig sind und dann ohne Verzögerung die Resultate aus den einzelnen Devices holen.

Leider ist auch diese Property standardmässig "-rw-r--r-- root root" - kann man das beinflussen? Ein chmod hilft zwar kurzfristig, nach einem reboot ist das ja wieder weg.

Edit: Außerdem ist es wie gesagt recht neu - auf "buster" gibt es das - mein alter "stretch" Raspberry hat die property hingegen noch nicht.
Edit2: Hab es auch mit einem sysopen .. O_NONBLOCK probiert und dann ein dummy sysread von 0 Bytes angestossen - auch hier bleibt es dabei. Selbst der 0 Byte read blockiert.

Jörg