Kann LEDs im Modul nicht setzten

[amiga4ever]

Nachdem mein lcn seit Jahre vor sich hin funktioniert habe ich angefangen ein paar Sachen im Haus über den ioBroker zu verknüpfen. Da mein Garagentor nicht am lcn hängt habe ich einen Shelly dran um es zu fahren. Da ich verstanden habe, dass der LCN den Tastendruck nicht auf den Buis gibt habe ich im lcn pro jetzt gesagt, dass er auf einen Tastendruck eine LED im Modul setzen soll, damit ich diese nachher im ioBroker abfragen kann. Leider wird die LED nur gesetzt wenn ich den LCN pro offen habe und dann auch nur, wenn ich mir den Status anzeigen lasse. Lässt sich reproduzieren. Habe ich den Pro und die Statusanzeige für das Modul offen fährt das Garagentor auf und zu. Habe ich die Statusanzeige geschlossen funktioniert es nicht und zwar so lange bis ich die Statusanzeige für das Modul öffne (auch noch Minuten nach dem Tastendruck). Zum Habt Ihr eine Idee was ich falsch mache? Habt Ihr eine andere Idee, wie ich den Status, dass die Taste Gedrückt wurde für eine spätere Abfrage speichern könnte? Ich wolle halt kein Licht oder andere Relais schalten. Auf die Schnelle habe ich zu dem Problem auch nichts Forum oder im Netzt nicht gefunden.

[Uwe]

Moin Bernd,
die Möglichkeit einen Tastendruck aiszuwerten gibt es schon: SKH (Sende Kommando an Host - das lässt sich aber nur mit Administrator-Rechten in der Pro eintragen. Ob der IObroker das dann ausgewertet bekommt kann ich leider nicht sagen. PCK und mein Visu-Favorit IP-Symcon kann das.
Aber am Ende muss/sollte auch eine LED "sauber" über PCK gemeldet und geschaltet werden - es sei denn da ist gerade so viel los, dass Statusmeldungen etc. ggf. untergehen.
Wenn alles nicht funktionieren will bleibt eigentlich nur der 'Workaround' über einen virtuellen Ausgang oder Relais ...
PCK hat leider den Nachteil, dass nicht wie bei einem Kommando von einem Modul eine Kollisionserkennung zu laufenden Kommandos im Bus genutzt wird (egal welche Schnittstelle, auch das PKE kann das nicht!). Die Chance, dass hier also auch mal ein Schaltkommando 'kaputt' geht ist also durchaus gegeben. Du kannst (wenn der IObroker das kann) mal versuchen zeitliche Verzögerungen zu anderen Vorgängen zu schaffen.

Grüße, Uwe

[amiga4ever]

Hallo Uwe, danke für die Info aber das scheint nicht das Problem zu sein. Der Tastendruck geht nicht verloren. Ich versuche es mal anders zu beschreiben. Ich hoffe es wird nicht zu kompliziert. Ich setze die LED 1 im Modul 16 durch den Tastendruck. Das Garagentor bleibt zu. Öffne ich mit der rechten Maustaste im Kontextmenü von Modul 16 den Status (im lcn pro) öffnet sich das Garagentor. Es sieht so aus, als ob die LED erst mit dem öffnen des Status gesetzt wird. Hast Du eine Idee, wie ich das anders überprüfen kann? Zum Testen lass ich durch den Taster einfach das Licht bei mir im Arbeitszimmer Anschalten. Und siehe da es funktioniert (mit dem selben Script im ioBroker nur eben mit der Abfrage auf Licht Arbeitszimmer). Es muss also irgendetwas mit der LED zu tun. Prinzipiell wird der Status der LED also auch an den ioBroker übertragen aber komischer Weise erst, wenn ich lcn pro öffne und dann auch erst wenn ich den Status des Moduls in dem ich die LED setzte abrufe. Auch das dauert dann solange, bis der Status der LED abgerufen wird. Die Status der anderen Felder, die vorher zur Anzeige abgerufen werden reichen nicht. Erst wenn LED1 im Status angezeigt wird öffnet das Garagentor. Ich kann natürlich auch ein nicht belegtes Relais (nicht virtuell) schalten lassen und das abfragen. Aber als Ingenieur würde ich schon gerne wissen, warum das mit der LED nicht klapp. Grundsätzlich funktioniert die Lösung ja nur die Aktualisierung der LED scheint erst auf Abruf des Status zu gekoppelt zu sein. Wie könnte ich das rein LCN seitig überprüfen ohne den Status der LED abzurufen?

[amiga4ever]

Moin Bernd,
die Möglichkeit einen Tastendruck aiszuwerten gibt es schon: SKH (Sende Kommando an Host - das lässt sich aber nur mit Administrator-Rechten in der Pro eintragen. Ob der IObroker das dann ausgewertet bekommt kann ich leider nicht sagen. PCK und mein Visu-Favorit IP-Symcon kann das.

Würde ich gerne mal versuchen. Wie mach ich das denn? Vielleicht ist das ja sogar der einfachste Weg.

[Uwe]

Moin Bernd,
ich habe mal deine Mail beantwortet ...

Grüße, Uwe

[amiga4ever]

Hallo Uwe, vielen Dank. Die Mail ist angekommen. Zu dem Problem, dass das mit der LED1 auf an setzten nicht funktioniert. Ich hab eimal den Bus Monitor angeschmissen und dabei folgendes gesehen (s. Anlage). Wenn ich den Taster drücke geht der Befehl die LED 1 zu setzen raus (11:44:21:837). Aber erst wenn ich den Status des Modul in der pro öffne kommt die Quittung (11:46:40:172). Jetzt an Modul 4 (meine LinHK, die der Pro ja den Zugang gewährt. Anscheinend wird die LED vorher nicht wirklich gesetzt. Bin ich da auf der richtigen Spur? Wie kann das sein und warum gibt es überhaupt noch eine Quittung? Wenn ich mit dem Taster mein Licht im Arbeitszimmer schalten gibt es auch keine. Es gibt nur die Meldung, dass der Ausgang geschaltet ist.

[Uwe]

Moin Bernd,
ob die LinHK da etwas "anders" macht als die PCHK kann ich dir leider nicht sagen - ich bin da seit über 5 Jahren "raus" ...
Die wirklichen 'Quittungen' siehst du in der Pro auch nur mit Administrator Kennwort (da hat der Monitor dann ein Häkchen mehr zu setzen), so siehst du nur die 'Meldungen' vom gesetzten Staus.
Versuch doch mal die LED mit einer in einem Modul programmierten Taste zu schalten. Über die LinHK müsste ja auch ein 'sende Taste' das Kommando dann auslösen können.

Grüße, Uwe

[Niko]

Hallo Bernd,

Wenn ich den Taster drücke geht der Befehl die LED 1 zu setzen raus (11:44:21:837).

Ja, und in dem Moment setzt das Modul intern auch die LED (z.B. zu sehen an einem angeschlossenen Tastsensor mit LEDs).

Aber erst wenn ich den Status des Modul in der pro öffne kommt die Quittung (11:46:40:172). Jetzt an Modul 4 (meine LinHK, die der Pro ja den Zugang gewährt.

Das ist technisch eine Quittungsmeldung von Modul 16 an Modul 4. Wer da warum eine Quittung angefordert hat, ist im Screenshot leider nicht ersichtlich, vermutlich filterst Du zu gut. Ich hoffe auch inständig, dass Du der LCN-PRO nicht die Modul-ID 4 gegeben hast, die dann entstehenden Bus-Protokolle möchte ich mir nicht antun wollen.

Mit dem Kommando "LED 1: ein" hat es definitiv nichts zu tun, denn die Module verschicken untereinander keine Quittungen, da sie sie gar nicht auswerten wollen (sie sehen ja direkt auf dem Bus, was passiert) und somit auch gar nicht anfordern.

Wenn du über LCN-PRO ein "Handkommando" ausführst, wird dabei i.d.R. eine Quittung angefordert. Auch einige Visualisierungssysteme fordern diese an (m.E. unnötigerweise, das müllt nur den Bus zu). Und Koppelsoftware wie PCHK und LinHK senden solch eine Quittung regelmäßig an sich selbst, um die Verfügbarkeit des Bus zu überprüfen.

Eine positive Quittung sagt nur aus, dass ein Telegramm empfangen und erfolgreich verarbeitet wurde. Interessant sind eher negative Quittungen, die bei Problemen weiterhelfen (Sicherung defekt, Widerspruch zur Modulparametrierung u.ä.). Wichtig dabei: Auch eine negative Quittung wird nur vom Modul zurückgeschickt, wenn zuvor aktiv eine Quittung angefordert wurde.

Quittungen werden direkt in LCN-PRO angezeigt, ein Administrator-Kennwort ist dafür nicht erforderlich.

Anscheinend wird die LED vorher nicht wirklich gesetzt.

Doch, sie wird sofort gesetzt (sofern das Telegramm heile am Modul angekommen ist.

Bin ich da auf der richtigen Spur? Wie kann das sein und warum gibt es überhaupt noch eine Quittung? Wenn ich mit dem Taster mein Licht im Arbeitszimmer schalten gibt es auch keine. Es gibt nur die Meldung, dass der Ausgang geschaltet ist.

Du näherst Dich schon selbst der Erklärung: Du erhältst hier keine Quittung, sondern eine (Status-)Meldung.

Zu den Quittungen hatte ich oben bereits etwas geschrieben, für Deinen Einsatzzweck sind sie schlicht ungeeignet.

Interessanter für Dich sind die Statusmeldungen. Diese werden für bestimmte Modulressourcen (z.B. Ausgänge, Relais, Binäreingänge) automatisch bei einer Änderung verschickt (sofern nicht deaktiviert oder das Modul oder der Bus zu beschäftigt sind).

Und da haben wir es schon: Bei Änderungen von LEDs in Modulen gibt es keine solche Statusmeldung. Die LED wird intern verändert, Du siehst es aber von außen nur, wenn ein Tastsensor mit LEDs angeschlossen ist.

Man kann aber den Zustand der LEDs abfragen (teilweise immer noch als "Tableaulämpchen" bezeichnet), dafür gibt es extra ein PCK-Kommando. Ist in LCN-PRO der Modulstatus zu einem Modul geöffnet, macht LCN-PRO genau das alle paar Sekunden. Und die Antwort des Moduls auf diese Abfrage scheint auch ioBroker auszuwerten.

Nun könntest Du ja auf die Idee kommen, dieses PCK-Kommando zur Abfrage regelmäßig zu senden. Das kann man machen, es müllt aber auch den Bus zu, man sollte es daher nur in größeren Zeitabständen machen, etwa zur Anzeige von Statusinformationen in einer Visualisierung, wenn es nicht schlimm ist, dass der Zustand ggf. erst ein paar Minuten später aktualisiert wird.

In Deinem konkreten Anwendungsfall (Tastendruck soll sofort was in ioBroker auslösen) scheinen mir LEDs daher gänzlich ungeeignet, zudem noch aus einem zweiten Grund: Wenn die Taste losgelassen wurde, muss die LED ja auch irgendwann wieder mal zurückgesetzt werden.

Einem LinHK-Nutzer ohne ioBroker würde ich hier die Nutzung von LinHK-Makros empfehlen, die können problemlos per Tastendruck aufgerufen werden.

Wenn aber ioBroker reagieren soll, empfehle ich, ein virtuelles Relais in einem UPP mittels Relais-Kurzzeittimer zu schalten. Dann gibt es die normale, zeitnahe Relais-Statusmeldung für ioBroker und das Relais wird automatisch für den nächsten Tastendruck zurückgesetzt.


Schöne Grüße
Niko

[amiga4ever]

Hallo Niko,

vielen Dank schon mal.

Ich hoffe auch inständig, dass Du der LCN-PRO nicht die Modul-ID 4 gegeben hast, die dann entstehenden Bus-Protokolle möchte ich mir nicht antun wollen.

Keine Sorge ID4 ist von mir nicht vergeben. Wen ich es richtig verstanden habe ist das ja die ID des Kopplers

Interessanter für Dich sind die Statusmeldungen. Diese werden für bestimmte Modulressourcen (z.B. Ausgänge, Relais, Binäreingänge) automatisch bei einer Änderung verschickt (sofern nicht deaktiviert oder das Modul oder der Bus zu beschäftigt sind).

Man kann aber den Zustand der LEDs abfragen (teilweise immer noch als "Tableaulämpchen" bezeichnet), dafür gibt es extra ein PCK-Kommando. Ist in LCN-PRO der Modulstatus zu einem Modul geöffnet, macht LCN-PRO genau das alle paar Sekunden. Und die Antwort des Moduls auf diese Abfrage scheint auch ioBroker auszuwerten.
Und da haben wir es schon: Bei Änderungen von LEDs in Modulen gibt es keine solche Statusmeldung. Die LED wird intern verändert, Du siehst es aber von außen nur, wenn ein Tastsensor mit LEDs angeschlossen ist.

Das scheint mir dann das Problem zu sein. Allerdings verstehe ich dann noch nicht warum der ioBroker die LED 1 ein mitbekommt, wenn die Pro dieses Kommando zu Statusabfrage an das Modul sendet. Aber sei's drum Ich habe verstanden die LED taugen dafür nicht und mir den Bus zumüllen habe ich auch nicht vor.

In Deinem konkreten Anwendungsfall (Tastendruck soll sofort was in ioBroker auslösen) scheinen mir LEDs daher gänzlich ungeeignet, zudem noch aus einem zweiten Grund: Wenn die Taste losgelassen wurde, muss die LED ja auch irgendwann wieder mal zurückgesetzt werden.

Das Löschen der LED habe ich durch den ioBroker nach dem Öffenen des Tors erledigt. Ist für mich das sicherere Kriterium. Der ioBroker weiß am Besten wann er das Tor geöffnet oder geschlossen hat.

Wenn aber ioBroker reagieren soll, empfehle ich, ein virtuelles Relais in einem UPP mittels Relais-Kurzzeittimer zu schalten. Dann gibt es die normale, zeitnahe Relais-Statusmeldung für ioBroker und das Relais wird automatisch für den nächsten Tastendruck zurückgesetzt.

Das werde ich morgen mal versuchen. Klingt vielversprechend. Nur den Time brauche ich ja nicht, da ich den Status vom ioBroker zurücksetzen lasse. Ich werde berichten.

CU
Bernd

[amiga4ever]

Nur kurze Info,

der weg über ein virtuelles Relais in einem UPP Modul war/ist erfolgreich. Also schon male besten Dank für Eure Unterstützung. Ich habe jetzt beide Wege in einem umgesetzt. DAs Relais wird in der Regel vom ioBroker wieder auf 0 gesetzt. Zur Sicherheit habe ich das Relais wie von Niko vorgeschlagen über einen Kurzzeittimer setzten lassen. Damit geht es auch auf null wenn der ioBroker mal nicht erreichbar ist. Nicht das plötzlich das Garagentor unbeabsichtigt geöffnet wird, wenn der ioBroker wieder verfügbar ist.

CU
Bernd