Zustandsabfrage nach FHEM Start

[waldo]

Hallo zusammen

Hier erstmald die Anlagenbeschreibung:
- Der KNX-Bus ist ganzzeitig im Betrieb.
- FHEM ist in der Nacht abgeschaltet.

Problem:
- nach dem Start von FHEM soll von allen geräten der IST Status abgefragt werden und im Dashboard entsprechend gesetzt werden.
  (es ist der Fall das ein Gerät EIN ist aber von Fhem nach dem Start nicht so angezeigt wird.)

Mir ist nicht klar wie ich FHEM dazu bewegen kann nach dem Start die Abfrage zu machen.

Gruss

[betateilchen]

Wie Du die Abfrage an die devices machen musst, weiß ich nicht, ich kenne KNX nicht.
Hast Du mal ein Beispiel, wie Du das an einem einzelnen KNX-device machen würdest?

Das "nach dem Start..." kann ich Dir beantworten.

Code Auswählen Erweitern

define get_all_knx notify global:INITIALIZED <hier kommt der Teil mit der Abfrage hin>

[waldo]

Mit nachfolgendem habe ich festgestellt es geht nicht

Code Auswählen Erweitern

define get_all_knx notify global:INITIALIZED <hier kommt der Teil mit der Abfrage hin>[/quote]
Ist schon belegt mit

Code Auswählen Erweitern

define NetzwerkEin notify global:INITIALIZED {fhem("sleep 30.0;;sleep 30.0;;set SteckdosePC on")}Habe es darin mit dem Aufruf des folgenden Sub versucht

Code Auswählen Erweitern

sub CheckSetStatus(){
  fhem(setreading Arbeitslicht {ReadingsVal("Arbeitslicht","state"," ")});
}

[erwin]

Hi Waldo,
mein Vorschlag: siehe:  cmd-ref - "Atttribut enableKNXscan 1" - das Attribut wurde exakt für diesen Zweck gebaut!

das notify global:INITIALIZED wird nicht funktionieren, weil da die Verbindung zum Bus noch nicht fertig aufgebaut ist!
l.g. erwin

[Nobbynews]

Mal am Rande eine OT Frage

- FHEM ist in der Nacht abgeschaltet.

Was ist hierfür der Hintergrund?

[betateilchen]

Ist schon belegt mit

Das ist doch Quatsch. Es ist völlig egal, wieviele notify Du anlegst, die auf global:INITIALIZED triggern sollen. Die werden ALLE ausgeführt.

das notify global:INITIALIZED wird nicht funktionieren, weil da die Verbindung zum Bus noch nicht fertig aufgebaut ist!

Das ist eine sehr kühne Behauptung. Wenn man das notify richtig aufbaut, WIRD es funktionieren. Es spricht beispielsweise nichts dagegen, innerhalb des Ausführungsteil des notify so lange zu verzögern, bis der Bus bereit ist. Hilfreich wäre es, (keine Ahnung, ob es so ist) wenn es zu diesem Zeitpunkt ein event vom Bus gäbe, das man in sleep verwenden könnte.

mein Vorschlag: siehe:  cmd-ref - "Atttribut enableKNXscan 1"

Das ist natürlich die eleganteste Lösung 

[passibe]

wenn es zu diesem Zeitpunkt ein event vom Bus gäbe, das man in sleep verwenden könnte

Ist jetzt offtopic, aber wie baut man sowas effizient und non-blocking? Gibt es da irgendeinen coolen Trick "nur" in perl/ohne Zusatzdevice bzw. -modul wie DOIF oder so?

[TomLee]

sleep
[EN DE]
sleep <sec|timespec|suchmuster> [<id>] [quiet]

sleep gefolgt von weiteren Befehlen ist vergleichbar mit einem namenlosen at oder notify Kommando, es führt die nachfolgenden Befehle aus, nachdem es die spezifizierte Zeitspanne gewartet hat bzw. ein Event welches dem <suchmuster> entspricht aufgetreten ist. Die verzögerung kann
in Sekunden (Millisekunden genau, da man Nachkommastellen spezifizieren kann)
als timespec (HH:MM or HH:MM:SS oder {perlfunc})
oder als suchmuster (Gerätename oder Gerätename:Event)
angegeben werden.
Ein sleep mit einer <id> ersetzt ein sleep mit der gleichen <id> and can mit cancel entfernt werden. Falls sleep in at/notify/etc aufgerufen wurde, und die nachfolgenden Kommandos einen nicht leeren Text zurückgeliefert haben, dann wird dieser Text mit loglevel 2 protokolliert.
quiet vermeidet diese Protokollierung.

Beispiele:
sleep 0.5
define n3 notify btn3.* set lamp toggle;;sleep 0.5;;set lamp toggle
define a3 at +*00:05 set Windsensor 1w_measure;; sleep 2 quiet;; get Windsensor 1w_temp

Bemerkung: falls sleep von keinem Befehl gefolgt wird, dann wird FHEM blockiert. Das ist unerwünscht, und im FHEM-Log wird eine Warnung protokolliert.

https://forum.fhem.de/index.php/topic,100306

Das Suchmuster ist analog das Suchmuster welches man im Eventmonitor bspw. beim erstellen eines notify erhält.

[passibe]

No way, oh man. Jetzt fühle mich mich doof

Hätte nie im Leben gedacht, dass sleep mehr als die Sekundenangabe nimmt, weil, naja, es ist halt sleep. Deshalb auch nie gebothert das nachzulesen.
Danke fürs Augenöffnen.

[betateilchen]

Hätte nie im Leben gedacht, dass sleep mehr als die Sekundenangabe nimmt, weil, naja, es ist halt sleep.

Du hast offenbar noch nicht verinnerlicht, dass sleep in diesem Kontext ein FHEM Befehl ist und nicht die gleichnamige perl Funktion.

Diese Namensgleichheit finde ich schon sehr lange extrem unglücklich gewählt, aber es ist halt nunmal so.

[erwin]

...wenn es zu diesem Zeitpunkt ein event vom Bus gäbe, das man in sleep verwenden könnte.

Ja, das gibts natürlich:

Code Auswählen Erweitern

sleep <KNXIODEVICE>:INITIALIZED quiet;<cmd> aber dann kann man besser ein notify schreiben, das mit <KNXIODEVICE>:INITIALIZED getriggert wird.
..aber wie schon geschrieben, das Attr enableKNXscan erledigt das im Hintergrund, ganz ohne notify / sleep...

Ein sleep <delay-seconds> ist zwar möglich, aber nicht determinisisch! Ich hatte vor kurzem ein delay von 90 Sekunden!!! in der global:INITIALZED notify loop, verursacht durch ein Modul, das blockierend ein http-request verwendet hat.
Auch hier nachzulesen: KNX_Utility-Functions
l.g. erwin

[passibe]

Du hast offenbar noch nicht verinnerlicht, dass sleep in diesem Kontext ein FHEM Befehl ist und nicht die gleichnamige perl Funktion

Doch das war mir klar. Perl-Sleep ist ja sowieso nutzlos, weil es blockiert; ich habe bisher nur das FHEM-Befehl-sleep eingesetzt (und deshalb logischerweise auch nur im FHEM-Kontext, wo es ja nichts anderes gibt, als FHEM-Befehle ...).

Wie gesagt, ich habe mir einfach nicht die Mühe gemacht weiter nachzulesen, weil mir im Traum nicht eingefallen wäre, dass sich jemand die Mühe gemacht hat, mehr als das "virtuelle at" einzubauen und sleep diese Zusatzfunktionalität zu verpassen. Ich dachte, wenn es sowas gibt, dann mit einem anderen Befehlsnamen o.ä. und nicht versteckt hinter dem unschuldigen sleep.

Insofern bin ich da was die Namensgleichheit angeht voll auf deiner Seite.

[waldo]

Guten Tag zusammen

Zwischenzeitlich hatte ich die Gelegenheit meine Programmierung anzupassen und zu testen - es funktioniert wie es soll.

Warum ich FHEM, resp. die Anlage, abschalte ist:
- die wird in der Nacht nicht benötigt
- wenn ich abwesend bin wird die Anlage auch nicht benötigt.

Beim Start muss FHEM 60 Sekunden im "sleep" sein, FHEM muss warten bis der RasPi die korrekte Zeit gesetzt hat. Gelöst wie folgt:

Code Auswählen Erweitern

define NetzwerkEin notify global:INITIALIZED {fhem("sleep 30.0;;sleep 30.0;;set SteckdosePC on")}(Es geht nur mit 2-mal sleep, mit 1-mal und 60 Sekunden geht nicht.)

Damit nun alle Stati richtig gesetzt werden habe ich es wie folgt gelöst:

Code Auswählen Erweitern

defmod initializedKNXIO_nf notify KNXGW:INITIALIZED KNX_scan;; sleep 30.0;; set SteckdosePC on;;
Leider wird von einem 6-Kanal Schalt-Aktor beim scan nichts eingelesen.
Bei den Rollos wird die Endlageposition nicht bei allen richtig angezeigt.

An beiden Punkten werde ich wohl noch etwas Zeit verbringen müssen

Soweit mal dank für die Unterstützung.

[erwin]

Hi Waldo,
ich würde den FHEM start via systemd verzögern, Beispiele siehe: wiki
Ich glaube zwar nicht, dass es an der system-time liegt, da würde der fhem-start "hangen", mit msg im Log, aber es kann ja auch ein anderes timing problem beim hochfahren sein...

Leider wird von einem 6-Kanal Schalt-Aktor beim scan nichts eingelesen.
Bei den Rollos wird die Endlageposition nicht bei allen richtig angezeigt.

hints zum debuggen:
funktioniert ein get-cmd auf die betreffenden gruppenadressen?
Damit ein get-cmd (und auch KNX_scan) ein resultat bringt, braucht es 2 Voraussetzungen:
1) die definition darf keine set-option enthalten
2) der KNX Aktor muss auf den get-cmd eine Antwort senden. Evtl. konfigurierbar via ETS
l.g. erwin

[waldo]

Hallo Erwin

So wie ich schon fündig geworden bin startet der RasPi immer mit der zuletzt gespeicherten Zeit, wenn er vom Netz ist und keine Uhr eingebaut hat (was bei mir der Fall ist).
Bei mir ist die Zeitschaltuhr aufgesteckt und von der muss erst die aktuelle Zeit auf den RasPi geladen werden, was halt seine Zeit dauert.
Die entsprechenden systemd-Dateien habe ich so weit wie möglich angepasst. Trotzdem muss FHEM noch ein wenig warten, dies sind die 30Sek und der scan der ja auch 30sek wartet danach wird der Strom eingeschaltet.

Danke für die beiden hints:
1) das define hat kein set
2) es handelt sich um einen Hager TXA606B, würde meinen da ist keine Konfig möglich, werde aber noch einiges in 2 Wochen ausprobieren.

Dank und Gruss
Walter