Hi,
ich habe jetzt angefangen, die Versionen von honk und mir (bzw. gevoo) zusammenzubringen. Ich denke, dass das sehr sinnvoll ist, da wir beide interessante Sachen in unseren Versionen haben. Außerdem wird das ganze stabiler, wenn es mehr Leute benutzen und pflegen.
Ich habe dazu die bisherige "dev" Version (0.6.3) nach "master" kopiert. Die "dev"-Version (0.7.0)ist momentan nicht für den produktiven Einsatz geeignet. D.h. wer das ganze produktiv einsetzt oder einsetzen will, der sollte sich diese Version holen:
https://github.com/kc-GitHub/FHEM-HM485/tree/master (https://github.com/kc-GitHub/FHEM-HM485/tree/master)
Wer ein Testsystem hat, der kann natürlich auch die "stabile" Version benutzen. Es wäre aber nett, wenn möglichst viele sich am Testen beteiligen könnten und die "dev" Version benutzen:
https://github.com/kc-GitHub/FHEM-HM485/tree/dev (https://github.com/kc-GitHub/FHEM-HM485/tree/dev).
Hier ist eine Auflistung der bisherigen Änderungen. Rein syntaktische Änderungen und Tippfehler-Korrekturen sind nicht aufgelistet.
1. Internes Löschen der "hidden" Parameter korrigiert. Ich weiß nicht genau, wie es bei honks Version aussieht, aber in "meiner" Version werden "hidden" Parameter, wie z.B. die Adresse der Zentrale, nicht angezeigt.
2. In den <device>.pm-Dateien sind Options ("option" Tag) keine Hashes mehr, sondern Arrays. Deshalb haben sich auch praktisch alle <device>.pm-Dateien geändert. Für Homebrew-Devices müssen ggf. noch die <device>.pm-Dateien geändert werden, aber ich habe keine mit "option".
(xmlHelper.pl ist auch entsprechend geändert.)
3. Einiges in ConfigurationManager.pm ist jetzt "sauberer". Möglicherweise macht das keinen Unterschied, es könnte aber auch sein, dass ein paar Fehlerchen damit verschwinden.
4. Die XML-Dateien sind jetzt Teil der "Auslieferung".
Es gibt momentan auch ein bekanntes Problem: Der HMW-SEN-SC-12-DR funktioniert nicht. Das werde ich als nächstes angehen.
Es wäre nett, wenn jemand als Tester unterstützen könnte.
Gruß,
Thorsten
Hallo Thorsten,
da warst Du aber schon recht fleissig, Du hast aber wahrscheinlich noch einiges an Arbeit vor Dir bis das alles funktioniert.
Ich habe mir die ConfigurationManager.pm mal angeschaut
https://github.com/kc-GitHub/FHEM-HM485/blob/dev/FHEM/lib/HM485/ConfigurationManager.pm
die hatte ich schon getestet, diese funktioniert nur mit einzelnen Bits.
In meiner Version habe ich die "sub convertSettingsToEepromData" von honk übernommen, damit funktioniert bei mir alles.
Es gibt aber noch einige Abhängigkeiten in der Device.pm. Dort habe ich auch noch einiges von honk übernommen.
In der Anlage sind die Device.pm und ConfigurationManager.pm mit denen es bei mir funktioniert. Es muß noch mit dem "hmw_io12_sw14_dr" getestet werden.
Evtl muß Du in der Device.pm ab Zeile 632 - 638 die # entfernen.
In der Device.pm habe ich gegenüber Deiner und honks Version in beim der 'door_sensor.state' was geändert. Betrifft nur den HMW-SEN-SC-12-DR.
0 ist closed und > 0 ist open. Damit ist das Verhalten wie bei den Funkmodulen.
} elsif ($control eq 'door_sensor.state') { # hmw_sen_sc_12_dr
if ( isNumber($value)) {
$retVal = ($value == 0) ? 'closed' : 'open';
}
Nachtrag:
Als Ausgangsversion für meine Testversion habe ich die 0.6.2 von Thorsten genommen.
Gruß Ralf
Hi,
mit Version 0.7.1 sollte jetzt auch der HMW-SEN-SC-12-DR funktionieren.
@Ralf9: Eins nach dem Anderen. Jetzt versuche ich erst einmal "honk" und "thorsten" zusammenzubringen. Danach kann ich dann nach Deinen Änderungen sehen. Ich hoffe auch, dass wir in Zukunft mit (möglichst kleinen) Pull-Requests arbeiten können. Dateien vergleichen ist echt mühsam.
Zitat von: Ralf9 am 02 August 2015, 12:49:57In der Device.pm habe ich gegenüber Deiner und honks Version in beim der 'door_sensor.state' was geändert. Betrifft nur den HMW-SEN-SC-12-DR.
0 ist closed und > 0 ist open. Damit ist das Verhalten wie bei den Funkmodulen.
Wie ist das Verhalten denn in einer CCU? Ich denke, dass das synchronisiert sein sollte. Die Funkmodule interessieren eigentlich nicht. Blöderweise sagt das XML dazu nichts.
Gruß,
Thorsten
Hallo Thorsten
Danke, daß Du nun meine Version eingepflegt hast.
Zitat1. Internes Löschen der "hidden" Parameter korrigiert. Ich weiß nicht genau, wie es bei honks Version aussieht, aber in "meiner" Version werden "hidden" Parameter, wie z.B. die Adresse der Zentrale, nicht angezeigt.
Dies Parameter habe ich nur zu Debuggingzwecken auskommentiert. Es ist also richtig, daß die hidden Parameter augeblendet werden sollten. Mölicherweise wird allerdings die central_address irgendwann mal interessant. Ich weiß nicht ob neue Devices "FFFFFFF" als als central_address gespeichert haben oder "00000001". Das wollte ich sehen und habs daher auskommentiert. beim "pairen" (Device anlegen), könnte man überlegen, ob man hier nicht die "hmwid" des HMLAN hineinschreiben sollte.
lg Harald
Zitat von: honk am 02 August 2015, 13:48:05Danke, daß Du nun meine Version eingepflegt hast.
Naja, noch lange nicht alles.
ZitatDies Parameter habe ich nur zu Debuggingzwecken auskommentiert. Es ist also richtig, daß die hidden Parameter augeblendet werden sollten. Mölicherweise wird allerdings die central_address irgendwann mal interessant. Ich weiß nicht ob neue Devices "FFFFFFF" als als central_address gespeichert haben oder "00000001". Das wollte ich sehen und habs daher auskommentiert. beim "pairen" (Device anlegen), könnte man überlegen, ob man hier nicht die "hmwid" des HMLAN hineinschreiben sollte.
Neue Devices haben dort FFFFFFFF stehen. Eine CCU schreibt beim Pairing 00000001 rein. Theoretisch gehen zwar auch andere Werte, das wurde aber glaube ich noch nie beobachtet.
Wenn wir was reinschreiben, dann sollten wir 00000001 reinschreiben.
...aber jetzt will ich erstmal versuchen, Deine Änderungen zu übernehmen. Das Blöde ist, dass Deine Ursprungsversion nicht gerade die aktuellste war und die beiden Versionen schon ziemlich auseinander gelaufen sind.
Gruß,
Thorsten
Hallo Thorsten
Ja tut mir leid. es ist die letzte Version die Dirk gemacht hatte, Und die hab ich ein bisschen "aufgebohrt" :-) Nächste Woche versuche ich, Dich ein wenig zu unterstützen.
lg Harald.
Hi,
die aktuelle Version in dev (https://github.com/kc-GitHub/FHEM-HM485/tree/dev (https://github.com/kc-GitHub/FHEM-HM485/tree/dev)) ist jetzt mit dem Stand von honks Version abgeglichen, den ich habe.
Das ganze funktioniert bei mir soweit, aber ich habe das noch nicht mit vielen Devices getested. Insbesondere der behaviour-Kram funktioniert möglicherweise nicht, aber das kann ich nicht testen.
@honk: Könntest Du mir nochmal den Link zu Deinem Git-Repository schicken? Wenn es in den letzten zwei Wochen oder so Änderungen gegeben hat, dann sind die bei mir noch nicht drin.
Details, was ich übernommen habe und was nicht kommen noch. Das meiste habe ich aber übernommen.
Gruß,
Thorsten
Hallo Thorsten
sehr schön :-) . Der link ist https://github.com/hresalg/FHEM-HM485 (https://github.com/hresalg/FHEM-HM485)
lg Harald
Zitat von: Ralf9 am 02 August 2015, 12:49:57
In meiner Version habe ich die "sub convertSettingsToEepromData" von honk übernommen, damit funktioniert bei mir alles.
Das ist jetzt auch drin. Deine Version hat erstmal nicht funktioniert, aber ich denke, dass ich's hinbekommen habe.
ZitatIn der Device.pm habe ich gegenüber Deiner und honks Version in beim der 'door_sensor.state' was geändert. Betrifft nur den HMW-SEN-SC-12-DR.
0 ist closed und > 0 ist open. Damit ist das Verhalten wie bei den Funkmodulen.
Das ist jetzt auch geändert.
Gruß,
Thorsten
Zitat von: honk am 02 August 2015, 21:28:35sehr schön :-) . Der link ist https://github.com/hresalg/FHEM-HM485 (https://github.com/hresalg/FHEM-HM485)
Ok, jetzt habe ich auch die restlichen Änderungen übernommen, soweit sinnvoll. Zwei Sachen habe ich nicht übernommen:
1. Alles rund um's Autocreate, da das bei mir eh schon gut funktioniert.
2. Die Vereinfachung von optionsToList. Da fehlt mir die Behandlung des Default-Werts. Braucht man das nicht mehr?
Ich habe übrigens auch das Ping-Pong nicht übernommen, da das mit meinem Queue-Konzept überflüssig wird. Genauso die ganzen Änderungen bezüglich waitForConfig, das automatische Anlegen der Channels etc. Das hat eh schon funktioniert.
Alles andere ist glaube ich drin, inklusive Peering.
Gruß,
Thorsten
So, eine letzte kleine Änderung für heute. STATE und state wird jetzt hoffentlich ordentlich dargestellt.
STATE wird gar nicht mehr direkt geändert. state erhält den folgenden Wert:
- Falls das Device sowieso das Reading "state" liefert, dann dessen Wert (was sonst...)
- Ansonsten den Name des zuletzt gesetzten Readings, verkettet mit dessen Wert, getrennt durch "_". Also z.B. "level_25", falls das letzte Reading level war mit dem Wert 25.
- Bei einem set-Befehl hat state (kurzzeitig) den Wert, der gesetzt wird mit "set_" als Präfix. Also z.B. "set ... on" erzeugt state "set_on". "set ... level 25" ergibt "set_25".
Das reicht jetzt für heute.
Ich hoffe, dass es jetzt langsam vorbei ist mit den verschiedenen Versionen für HM485.
Gruß,
Thorsten
Hallo Thorsten,
mir ist beim programmieren und testen meines hbw_io Moduls aufgefallen, das wenn bei einem Kommando an das Modul ein ResponseTimeout auftritt, automatisch ein getconfig ausgelöst wird. Das getconfig wurde ausgelöst obwohl das Modul vollständig geladen war.
Wenn es am Anfang beim Laden der Config zu Response Timeout kommt, wäre es schön, wenn nach 3 erfolglosen Versuchen aufgehört wird und die erfolglosen Befehle aus der Queue gelöscht werden.
Eine Möglichkeit dies zu realisieren wäre an jedem Eintrag in der waitForConfig Queue einen Eintrag mit einem Zähler hinzufügen.
Und dann bei jedem Response Timeout bei dem entsprechenden Queue Eintrag den Zähler um eins zu erhöhen.
Wenn dann der Zähler bei 3 ist, den entsprechenden Queue Eintrag löschen.
Du kannst es ja mit z.B. einer Konstanten am Anfang der 10_HM485.pm konfigurierbar machen.
Nachtrag:
Ist diese Frage hier ok, oder soll ich dies nach "Homematic wired" verschieben?
Nachtrag2:
Wenn per Configvariable festgelegt wurde, daß nach 3 erfolglosen Versuchen das getconfig eines Moduls abgebrochen wird, stelle mir das Verhalten beim Start wie folgt vor.
- Am Anfang wird bei allen Modulen der Status auf "wait for config" gesetzt
- Wenn bei einem Modul der "Ping" erfolgreich war, wird der Status des Moduls auf "get config" gesetzt
- wenn das getconfig erfolgreich war, wird der Status des Moduls auf "ack" gesetzt
- wenn das getconfig eines Moduls nach 3 Versuchen abgebrochen wird, dann wird der Status des Moduls auf "Response Timeout" gesetzt.
- wenn bei allen Modulen "ack" oder "Response Timeout" steht, dann sollte das waitforconfig deaktiviert werden und auf nachfolgende "Response Timeout" sollte nicht mehr reagiert werden.
Der Status "wait for config" muß nicht unbedingt sein, ist nur "nice to have".
Wenn nach ein paar Minuten nicht bei allen Modulen "ack" oder "Response Timeout" steht, sehe ich dann, das es bei der Queue Abarbeitung probleme gibt und ich eingreifen muß. z.B. durch ein Neustart von fhem
Gruß Ralf
Nachtrag3: da es nun doch recht umfangreich geworden ist, habe ich nun doch ein neues Thema erstellt.
Hallo Thorsten,
ich habe mir dann auch mal meine Testumgebung zusammengestrickt. Aktuell nur ein HBW aktuell mit HBW-Sen-EP Code angeschaltet.
Bisher sieht alles ruhig aus ;-)
Viele Grüße
Stephan
Hi,
ich bin nicht ganz Deiner Meinung, aber ich denke, dass das Thema tatsächlich noch etwas Aufmerksamkeit verdient. Mal sehen, ob wir zu einer Lösung kommen können, die für alle gut ist.
Zitat von: Ralf9 am 02 August 2015, 23:50:31mir ist beim programmieren und testen meines hbw_io Moduls aufgefallen, das wenn bei einem Kommando an das Modul ein ResponseTimeout auftritt, automatisch ein getconfig ausgelöst wird. Das getconfig wurde ausgelöst obwohl das Modul vollständig geladen war.
Ja, das hat gevoo irgend wann einmal eingebaut. Ich finde es prinzipiell auch ganz praktisch, zumindest während man ein System aufsetzt bzw. daran herumbastelt. So lange das Modul nicht am Bus ist sollte das auch nur eine einzige Message absetzen und dann gleich wieder aufgeben. Das passiert so in etwa alle 10 Sekunden. Über die 10 Sekunden könnte man diskutieren, aber prinzipiell finde ich das gar nicht so schlecht.
ZitatWenn es am Anfang beim Laden der Config zu Response Timeout kommt, wäre es schön, wenn nach 3 erfolglosen Versuchen aufgehört wird und die erfolglosen Befehle aus der Queue gelöscht werden.
Die Queue wird sowieso gelöscht, wenn es Probleme gibt.
Allerdings halte ich die Lösung, nach drei Versuchen aufzugeben, nicht für so elegant. Hier ist, was ich mir dabei gedacht habe: Zu Response Timeouts kommt es in der Regel aus folgenden Gründen:
1. Das Device ist vom Bus. Wenn man es nicht mehr anschließen will, dann sollte man es aus FHEM löschen. Ansonsten ist es ganz praktisch, wenn es automatisch wieder eingelesen wird, sobald man es anschließt.
2. Der Bus hat starke Störungen. (Bei "leichten" Störungen sollte es gar nicht soweit kommen, da ein Response Timeout bedeutet, dass die letzte Nachricht schon drei mal wiederholt wurde.) In dem Fall sollte man die Störungen beseitigen. Die Software anzupassen ist da nicht ganz so sinnvoll.
3. Ein Fehler in der Software (FHEM). In dem Fall sollten wir den Fehler beheben. Kannst Du das Problem sicher reproduzieren? Wenn ja, dann würde ich es gerne analysieren.
ZitatUnd dann bei jedem Response Timeout bei dem entsprechenden Queue Eintrag den Zähler um eins zu erhöhen.
Wenn dann der Zähler bei 3 ist, den entsprechenden Queue Eintrag löschen.
Wie gesagt, die Queue wird bei einem NACK (Response Timeout) sowieso gelöscht.
ZitatIst diese Frage hier ok, oder soll ich dies nach "Homematic wired" verschieben?
Ist schon ok, das ist sozusagen momentan der "dev" Thread.
Zitat
Wenn per Configvariable festgelegt wurde, daß nach 3 erfolglosen Versuchen das getconfig eines Moduls abgebrochen wird, stelle mir das Verhalten beim Start wie folgt vor.
- Am Anfang wird bei allen Modulen der Status auf "wait for config" gesetzt
Das ist momentan im CONFIG_STATUS und heißt "PENDING".
Zitat- Wenn bei einem Modul der "Ping" erfolgreich war, wird der Status des Moduls auf "get config" gesetzt
Es gibt keinen Ping. Das ist mit den Queues nicht mehr nötig. Ich halte es nicht für sonderlich sinnvoll, exra etwas einzubauen, was den Bus belastet, um auf Störungen auf dem Bus zu reagieren. Den gewünschten Status siehst Du in CONFIG_STATUS und er heißt READING.
Zitat- wenn das getconfig erfolgreich war, wird der Status des Moduls auf "ack" gesetzt
Für den Config-Kram ist der CONFIG_STATUS verantwortlich. (In dem Fall "OK".)Ich würde das ungern vermischen. Das "Response Timeout" verschwindet nämlich nach der nächsten erfolgreichen Nachricht wieder. Dann würdest Du nicht mehr sehen, dass mit der Konfig was nicht stimmt.
Zitat- wenn das getconfig eines Moduls nach 3 Versuchen abgebrochen wird, dann wird der Status des Moduls auf "Response Timeout" gesetzt.
Momentan solltest Du bei CONFIG_STATUS "FAILED" sehen, wenn das getConfig zu einem NACK (Response Timeout) geführt hat. Der normale Status steht dann sowieso auf "Response Timeout".
Ich denke mal, dass die meisten Deiner Wünsche zumindest sinngemäß umgesetzt sind, nur halt in CONFIG_STATUS statt dem normalen Gerätestatus.
Trotz meiner Ausführungen weiter oben will ich zusätzlich etwas einbauen, um das automatische getConfig nach einem NACK abzuschalten. Das ist vor Allem für Geräte, die planmäßig zeitweise komplett abgeschaltet werden. (Man könnte es natürlich auch verwenden, wenn es öfters zu NACKs kommt und man den zu Grunde liegenden Fehler nicht analysieren kann oder will.) Meine Idee dabei ist in etwa folgende:
Per Default ist alles wie gehabt.
Für Geräte, die fertig eingerichtet sind, kann man ein Attribut für das automatische getConfig setzen (etwa autoGetConfigBehaviour oder so). Das Teil könnte folgende Werte haben:
0 - NEVER, d.h. es wird nie ein automatisches getConfig gemacht, nicht einmal beim Startup. Natürlich kann man manuell immer noch get config machen.
1 - ATSTARTUP, d.h. nur beim Start von FHEM. Wenn es einmal erfolgreich war, dann nie wieder. Das ist für Geräte, die planmäßig nicht immer am Bus sind.
2 - ALWAYS, d.h. so wie jetzt (default)
Ich überlege mir noch, ob es eine Einstellung geben sollte, um nur die Kanäle neu einzulesen, wenn das Device vom Bus war. (Also das Einlesen der Config von den Kanälen trennen.) Die Idee dabei ist, dass sich bei einem fertig eingerichteten Device die Konfig nicht mehr ändert. Es kann aber sein, dass der Bus irgendwo unterbrochen ist, aber Direktverknüpfungen z.T. noch funktionieren. Dann ist der Zustand in FHEM nicht mehr synchron mit dem wirklichen Zustand. Vielleicht ist das aber auch nur eine theoretische Möglichkeit.
Gruß,
Thorsten
Hallo Thorsten
Ich habe gerade ein HBW Device aktiviert und natürlich vergessen die dazugehörige device.pm ins Devices Verzeichniß zu kopieren. (ich würde vorschlagen, Deine HBW_device.pms aus dem github zu löschen).
Nun legt FHEM ein "HMW_Generic_HBW4073471" an. Das gefällt mir :-). Das Problem ist, daß nun scheinbar auf irgendetwas gewartet wird.
2015.08.03 19:08:50 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:08:55 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:00 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:05 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:10 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:15 3: HM485: Warte auf Initialisierung Gateway
......
Ich musste das "HMW_Generic_HBW4073471" löschen und neu starten. Dann war Ruhe.
Was hat es denn mit diesem Generic Device auf sich? Was könnte ich den damit anstellen wenn es geht ?
lg Harald
Zitat von: honk am 03 August 2015, 19:16:31Ich habe gerade ein HBW Device aktiviert und natürlich vergessen die dazugehörige device.pm ins Devices Verzeichniß zu kopieren. (ich würde vorschlagen, Deine HBW_device.pms aus dem github zu löschen).
Das war ein Versehen, ich habe sie inzwischen gelöscht.
Zitat
Nun legt FHEM ein "HMW_Generic_HBW4073471" an. Das gefällt mir :-). Das Problem ist, daß nun scheinbar auf irgendetwas gewartet wird.
2015.08.03 19:08:50 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:08:55 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:00 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:05 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:10 3: HM485: Warte auf Initialisierung Gateway
2015.08.03 19:09:15 3: HM485: Warte auf Initialisierung Gateway
......
Ich musste das "HMW_Generic_HBW4073471" löschen und neu starten. Dann war Ruhe.
Ich habe das gerade mal selbst ausprobiert und konnte das Problem nicht nachvollziehen. Bei mir wird sauber ein "generic" Device angelegt und es erscheint nichts verdächtiges im Log. Kannst Du das reproduzieren?
ZitatWas hat es denn mit diesem Generic Device auf sich? Was könnte ich den damit anstellen wenn es geht ?
Du kannst im Wesentlichen raw-Kommandos schicken. Das ist ganz nützlich, wenn man ein Homebrew-Device entwickelt und sich erstmal nicht mit dem XML/device.pm befassen will. Man kann damit sogar Devices steuern, die sich als HMW-Devices ausgeben, aber sich nicht an die normale Semantik halten.
Man kann inzwischen übrigens auch raw-Kommandos vom Device aus schicken. Also sowas wie
set HMW_Generic_HBW4073471 raw 7802A0
...würde Kanal 03 (in FHEM-Zählung) auf 0xA0 setzen.
Ich habe das eingebaut, weil der bisher existierende RAW-Befehl etwas unhandlich war. Insbesondere kennt man ja die Sende-/Empfangsfolgenummer nicht.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 03 August 2015, 10:34:41
Hi,
ich bin nicht ganz Deiner Meinung, aber ich denke, dass das Thema tatsächlich noch etwas Aufmerksamkeit verdient. Mal sehen, ob wir zu einer Lösung kommen können, die für alle gut ist.
Ja, das wird wahrscheinlich nicht einfach eine Lösung zu finden, die für alle passt. Dies wird nur durch einstell möglichkeiten bei der getconfig und Response timeout Behandlung möglich sein.
Zitat
1 - ATSTARTUP, d.h. nur beim Start von FHEM. Wenn es einmal erfolgreich war, dann nie wieder. Das ist für Geräte, die planmäßig nicht immer am Bus sind.
Diese Option würde mir erst mal reichen. Es muß nicht pro Modul einstellbar sein, allgemein für alle Module reicht auch. Dies bedeuted dann, dass nach einem erfolgreichen Start auf Response Timeout nicht mehr reagiert wird.
Wie kann ich erkennen, daß beim Start alle Module erfolgreich geladen wurden?
Zitat
3. Ein Fehler in der Software (FHEM). In dem Fall sollten wir den Fehler beheben. Kannst Du das Problem sicher reproduzieren? Wenn ja, dann würde ich es gerne analysieren.
Das Response timeout ist durch einen Programmierfehler in meinem Modul enstanden. Bei einem Kommando wurde kein Response zurückgeschickt.
Gruß Ralf
Hallo Ralf,
ZitatWie kann ich erkennen, daß beim Start alle Module erfolgreich geladen wurden?
Durch einen Blick aufs Device:
CONFIG_STATUS OKViele Grüße
Stephan
mir ist aufgefallen, daß durch die übernahme der "sub getFrameInfos" von der Version von honk, meine änderung der sub getFrameInfos nicht mehr drin ist
http://forum.fhem.de/index.php/topic,39235.msg316164.html#msg316164
Gruß Ralf
Zitat von: Ralf9 am 03 August 2015, 23:35:50
mir ist aufgefallen, daß durch die übernahme der "sub getFrameInfos" von der Version von honk, meine änderung der sub getFrameInfos nicht mehr drin ist
http://forum.fhem.de/index.php/topic,39235.msg316164.html#msg316164
Hi,
ich habe mir das gerade angeschaut. Soweit ich das Coding verstehe, ist das auch nicht mehr nötig. Das Coding sucht sich den Frame Type, der zum gesendeten Frame passt. Hast Du es ausprobiert?
(Möglicherweise fehlt da etwas bezüglich const_value, aber das ist eine andere Geschichte.)
Gruß,
Thorsten
Hi,
nach einem Peering musste man get config all machen, um das Peering korrekt zu sehen bzw. es bearbeiten zu können. Das ist mit Version 0.7.7 korrigiert.
Möglicherweise gab es ähnliche Effekte auch bei anderen Konfigurationen, die damit auch gelöst werden.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 04 August 2015, 09:31:16
ich habe mir das gerade angeschaut. Soweit ich das Coding verstehe, ist das auch nicht mehr nötig. Das Coding sucht sich den Frame Type, der zum gesendeten Frame passt. Hast Du es ausprobiert?
Ich habe es ausprobiert, wie zu erwarten funktioniert es damit nicht, wenn es mehrere Info_level mit verschiedenen sizes gibt.
In meinem Fall gibt es einen normalen Info_level mit size = 1.0 und einen weiteren Info_level2 mit size = 2.0
Ich habe die "sub getFrameInfos" umgeschrieben, damit funktioniert es bei mir.
Info_level 0x69 und key 0x4b werden getrennt behandelt.
Ich habe es so erweitert, daß beim Info_level der "frameTypeName" ermittelt und dann mit $frames verglichen wird.
Mir ist dabei nicht klar zu was diese beiden Codeteile gut sind:
# Todo we rewrite the new configuration to the old one
my $replace = convertFrameIndexToHash( $frames->{$frame}{'parameter'});
delete ($frames->{$frame}{'parameter'});
$frames->{$frame}{'parameter'} = $replace;
foreach my $pindex (keys %{$parameter}) { #Daten umstrukturieren
my $replace = $parameter->{$pindex}{'param'};
if (defined($replace)) {
$parameter->{$replace} = delete $parameter->{$pindex};
delete $parameter->{$replace}{'param'};
}
}
}Die Änderung der state Behandlung in der "sub HM485_ChannelDoUpdate" hat bei mir nicht funktioniert. Ich habe die Änderung wieder zurückgenommen. Nun funktioniert es wieder.
Gruß Ralf
Zitat von: Ralf9 am 05 August 2015, 23:14:30
Ich habe es ausprobiert, wie zu erwarten funktioniert es damit nicht, wenn es mehrere Info_level mit verschiedenen sizes gibt.
In meinem Fall gibt es einen normalen Info_level mit size = 1.0 und einen weiteren Info_level2 mit size = 2.0
Ok, das sollte nicht sein.
ZitatIch habe die "sub getFrameInfos" umgeschrieben, damit funktioniert es bei mir.
Ich wundere mich nur, warum das so ist. Worin unterscheiden sich denn die beiden Frames? Ich meine damit: Woran erkennt das System, welches der richtige ist? Könntest Du mal das zugehörige <device>.pm schicken, damit ich mir mal ein Bild machen kann?
Zitat
Info_level 0x69 und key 0x4b werden getrennt behandelt.
Warum?
Zitat
Ich habe es so erweitert, daß beim Info_level der "frameTypeName" ermittelt und dann mit $frames verglichen wird.
Es sieht mir aber so aus, als ob der frameTypeName nur aus dem Devicefile ermittelt wird und nicht wirklich aus den Daten des Frames. Funktioniert das wirklich auch für short press, long press und so?
Zitat
Mir ist dabei nicht klar zu was diese beiden Codeteile gut sind:
Das ist zum Umwandeln der "alten" <device>.pm-Struktur in die neue. Wahrscheinlich könnte man das inzwischen weglassen.
ZitatDie Änderung der state Behandlung in der "sub HM485_ChannelDoUpdate" hat bei mir nicht funktioniert. Ich habe die Änderung wieder zurückgenommen. Nun funktioniert es wieder.
Seltsam. Bei honk und mir funktioniert das. Könntest Du mal genauer sagen, was nicht funktioniert?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 06 August 2015, 09:35:17
Worin unterscheiden sich denn die beiden Frames? Ich meine damit: Woran erkennt das System, welches der richtige ist?
Hier ist ein Auszug meines devicefiles
'frames' => {
"info_level" => {
"channel_field" => 10,
"direction" => "from_device",
"event" => true,
"parameter" => {
"11.0" => {
"param" => "state",
"size" => 1.0,
"type" => "integer"
},
"12.4" => {
"param" => "state_flags",
"size" => 0.3,
"type" => "integer"
}
},
"type" => 0x69
},
"info_level2" => {
"channel_field" => 10,
"direction" => "from_device",
"event" => true,
"parameter" => {
"index" => 11.0,
"param" => "state",
"size" => 2.0,
"type" => "integer"
},
"type" => 0x69
},In meinem Fall wird über den ermittelten $chTyp=analog unter "response" der "info_level2" ermittelt.
Die Info ob es sich um info_level oder info_level2 handelt, steckt nur im devicefile.
"analog" => {
"count" => 4,
"index" => 21,
"paramset" => {
"link" => {},
"master" => {
"address_start" => 0x3B,
"address_step" => 2,
"parameter" => {
...
},
"type" => "master"
},
"values" => {
"parameter" => {
"value" => {
"conversion" => {
"factor" => 10,
"type" => "float_integer_scale"
},
"id" => "value",
"logical" => {
"max" => "200.0",
"min" => "0.0",
"type" => "float",
},
"operations" => "read,event",
"physical" => {
"event" => {
"frame" => "info_level2"
},
"get" => {
"request" => "level_get",
"response" => "info_level2"
},
"interface" => "command",
"type" => "integer",
"value_id" => "state"
}
}
},
"type" => "values"ZitatEs sieht mir aber so aus, als ob der frameTypeName nur aus dem Devicefile ermittelt wird und nicht wirklich aus den Daten des Frames. Funktioniert das wirklich auch für short press, long press und so?
Die Info_level 0x69 und key 0x4b werden getrennt behandelt damit es auch mit dem short press, long press und so funktioniert.
ZitatSeltsam. Bei honk und mir funktioniert das. Könntest Du mal genauer sagen, was nicht funktioniert?
Im Event monitor wurden die short press, long press doppelt angezeigt und bei dem 'door_sensor.state' wurde der state nicht aktualisiert.
Gruß Ralf
Zitat von: Ralf9 am 06 August 2015, 10:09:26
In meinem Fall wird über den ermittelten $chTyp=analog unter "response" der "info_level2" ermittelt.
Die Info ob es sich um info_level oder info_level2 handelt, steckt nur im devicefile.
Jetzt habe ich's kapiert. Du hast einfach verschiedene Kanäle. Manche liefern info_level, andere liefern info_level2.
Ich würde das einbauen, habe aber dazu noch Fragen:
1. Warum benutzt Du physical/get/Response und nicht physical/event/Frame ? Du weißt ja nicht, ob das Device die 0x69-Nachricht als Antwort schickt oder einfach so. Müsste man da nicht unterscheiden?
2. Bei einigen Devices stehen unter channels/<channeltype>/paramset/values/parameter/ mehrere Einträge. Theoretisch könnte man das auch für Kanäle machen, die kein 0x4B, sodern 0x69 liefern. Dann müsste man wieder nach const_value unterscheiden. Hast Du das absichtlich ignoriert?
3. Das mit dem behaviour könnte auch noch dazwischen funken. Beim HMW_IO12_SW14_DR steht für manche Kanäle als Frame Type "infi_frequency". Je nach "behaviour" scheint aber trotzdem info_level gesendet zu werden. Deine Version beachtet das nicht, oder?
Zitat
Im Event monitor wurden die short press, long press doppelt angezeigt
Ich nehme mal an, dass Du so etwas siehst:
2015-08-06 22:15:39 HM485 HMW_LC_Sw2_DR_KEQ1056682_01 press_short: 56
2015-08-06 22:15:39 HM485 HMW_LC_Sw2_DR_KEQ1056682_01 press_short_56
Wenn Du genau hinsiehst, dann sollte Dir auffallen, dass die Zeilen unterschiedlich sind. Die erste Zeile ist das Event, das vom Reading "press_short" ausgelöst wird. Die zweite Zeile ist das Event, das vom Reading "state" ausgelöst wird.
Ich dachte auch erst, dass "state" keine Events auslösen sollte, aber ich glaube, dass das andere Module auch so machen.
Zitatund bei dem 'door_sensor.state' wurde der state nicht aktualisiert.
Das ist seltsam. Ich kann das selbst nicht testen, da ich kein solches Device habe. Wenn ich mir das ganze im Coding betrachte, dann scheint das aber sehr ähnlich zu switch.state zu sein und da funktioniert es bei mir.
...oder meinst Du vielleicht STATE (und nicht state) auf dem Frontend?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 06 August 2015, 22:35:04
1. Warum benutzt Du physical/get/Response und nicht physical/event/Frame ? Du weißt ja nicht, ob das Device die 0x69-Nachricht als Antwort schickt oder einfach so. Müsste man da nicht unterscheiden?
das mit dem response habe ich aus der Routine von gevoo übernommen und habe es verallgemeinert. event und response haben normalerweise immer den selben info_level, oder ist Dir ein Modul bekannt wo dies nicht der Fall ist.
my $frameTypeName = getValueFromDefinitions( $deviceKey . '/channels/' . $chTyp . '/paramset/values/parameter/frequency/physical/get/response');
Zitat2. Bei einigen Devices stehen unter channels/<channeltype>/paramset/values/parameter/ mehrere Einträge. Theoretisch könnte man das auch für Kanäle machen, die kein 0x4B, sodern 0x69 liefern. Dann müsste man wieder nach const_value unterscheiden. Hast Du das absichtlich ignoriert?
Mir ist nicht ganz klar was Du damit meinst?
Zitat3. Das mit dem behaviour könnte auch noch dazwischen funken. Beim HMW_IO12_SW14_DR steht für manche Kanäle als Frame Type "infi_frequency". Je nach "behaviour" scheint aber trotzdem info_level gesendet zu werden. Deine Version beachtet das nicht, oder?
Bei HMW_IO12_SW14_DR gibt es eine Ausnahme wo es nicht passt, dafür gibt es die folgende Abfrage.
if ( $frameTypeName eq "info_frequency" && $behaviour eq "digital_input") {
$frameTypeName = "info_level";
}Zitat
Ich nehme mal an, dass Du so etwas siehst:
2015-08-06 22:15:39 HM485 HMW_LC_Sw2_DR_KEQ1056682_01 press_short: 56
2015-08-06 22:15:39 HM485 HMW_LC_Sw2_DR_KEQ1056682_01 press_short_56
Wenn Du genau hinsiehst, dann sollte Dir auffallen, dass die Zeilen unterschiedlich sind. Die erste Zeile ist das Event, das vom Reading "press_short" ausgelöst wird. Die zweite Zeile ist das Event, das vom Reading "state" ausgelöst wird.
Wozu wird beim "press_short/long" ein state benötigt, hat dies irgendwelche Vorteile?
Gruß Ralf
In der sub HM485_ProcessEepromData gibt es ein "{'.helper'}{'firsttime'}" ich habe Probleme mit dem Nachvollziehen wie dies funktionieren soll. Ich habe das {'.helper'}{'firsttime'} sonst nirgends gefunden.
sub HM485_ProcessEepromData($$$) {
my ($hash, $requestData, $eepromData) = @_;
my $name = $hash->{NAME};
my $adr = substr($requestData, 0, 4);
if (ref $hash->{'.helper'}{'firsttime'} eq 'HASH') {
if (keys %{$hash->{'.helper'}{'firsttime'}} == 0) {
Log3 ($name, 3, "Request Eeprom data finished");
delete $hash->{'.helper'}{'firsttime'};
} else {
delete $hash->{'.helper'}{'firsttime'}{$adr};
}
}
Gruß Ralf
Ich habe auch mal kurz mein HMW_IO_12_FM getestet, dabei ist mir aufgefallen, daß bei den Kanälen die Config Option "logging" fehlt.
Kann es sein, daß bei der "sub getConfigSettings" dieser Spezialfall nicht berücksichtigt ist?
"subconfig" => {
"link_roles" => {
"target" => {
"name" => "switch"
}
},
"paramset" => {
"hmw_io_ch_master" => {
"address_start" => 33,
"address_step" => 2,
"parameter" => {
"behaviour" => {
"logical" => {
"option" => [
{
"default" => true,
"id" => "input"
},
{
"id" => "output"
}
],
"type" => "option"
},
"physical" => {
"interface" => "internal",
"type" => "integer",
"value_id" => "behaviour"
},
"ui_flags" => "transform"
},
"logging" => {
"logical" => {
"option" => [
{
"id" => "off"
},
{
"default" => true,
"id" => "on"
}
],
"type" => "option"
},
"physical" => {
"address" => {
"index" => 0
},
"interface" => "eeprom",
"size" => 0.1,
"type" => "integer"
}
}
},
"type" => "master"
},
"hmw_switch_ch_link" => {
"address_start" => 0x39,
"address_step" => 28,
Gruß Ralf
Hallo Ralf
ZitatIch habe auch mal kurz mein HMW_IO_12_FM getestet, dabei ist mir aufgefallen, daß bei den Kanälen die Config Option "logging" fehlt.
Ich habe auch einen HMW_IO_12_FM. logging gibts tatsächlich nicht. Habe ich glatt übersehen. Jetzt wird mir auch klar warum ich manchmal eine Rückmeldung bekomme und manchmal nicht. Wenn ih es richtig verstehe, gibts dieses logging nur, wenn der Kanal auf output gesetzt ist.
lg Harald
Hi,
Zitat von: Ralf9 am 06 August 2015, 10:09:26
In meinem Fall wird über den ermittelten $chTyp=analog unter "response" der "info_level2" ermittelt.
Die Info ob es sich um info_level oder info_level2 handelt, steckt nur im devicefile.
Das ist mit der aktuellen Version (0.7.9) unterstützt. Ich habe es allerdings etwas anders implementiert, in der Hoffnung damit noch ein paar weitere Eventualitäten abgedeckt zu haben. Kannst Du es mal ausprobieren?
Zitat von: Ralf9 am 06 August 2015, 23:29:26
Wozu wird beim "press_short/long" ein state benötigt, hat dies irgendwelche Vorteile?
Ich dachte, dass es "FHEM-Standard" ist, dass jeder Kanal ein Reading "state" hat.
Zitat von: Ralf9 am 07 August 2015, 10:20:44
In der sub HM485_ProcessEepromData gibt es ein "{'.helper'}{'firsttime'}" ich habe Probleme mit dem Nachvollziehen wie dies funktionieren soll. Ich habe das {'.helper'}{'firsttime'} sonst nirgends gefunden.
Das ist wohl ein Artefakt aus der Zeit vor meinen Queues. Ich hab's gelöscht (Version 0.7.10).
Zitat von: honk am 08 August 2015, 06:11:39Ich habe auch einen HMW_IO_12_FM. logging gibts tatsächlich nicht. Habe ich glatt übersehen. Jetzt wird mir auch klar warum ich manchmal eine Rückmeldung bekomme und manchmal nicht. Wenn ih es richtig verstehe, gibts dieses logging nur, wenn der Kanal auf output gesetzt ist.
@honk: Könntest Du Dich damit befassen? Ich habe kein solches Device und mir ist nicht ganz klar, wie das mit dem behaviour zusammenhängt.
Noch was @Ralf9: Hat sich das mit dem 'door_sensor.state' erledigt?
Gruß,
Thorsten
Hi honk,
mir ist da noch etwas eingefallen: Wenn man ein Sensor-Device vom Bus nimmt, welches gepeert ist, dann kann man das Peering vom Aktor-Device nicht mehr löschen. Planst Du da was?
Gruß,
Thorsten
Hallo
Zitat@honk: Könntest Du Dich damit befassen? Ich habe kein solches Device und mir ist nicht ganz klar, wie das mit dem behaviour zusammenhängt.
Ja ich schaus mir an, obwohl ich auch noch nicht so recht weiß an welcher Stelle ich das einbauen soll. Es ist irgendwie eine blöde Stelle im Device.pm. Darum ist es mir wohl auch nie aufgefallen.
Zitatmir ist da noch etwas eingefallen: Wenn man ein Sensor-Device vom Bus nimmt, welches gepeert ist, dann kann man das Peering vom Aktor-Device nicht mehr löschen. Planst Du da was?
Eigentlich nicht. Ein Löschen der eeprom Einträge nur im Aktor habe ich eigentlich nicht vorgesehen. Ein "set unpeer unknown" oder so ähnlich könnte man aber wohl in einen Aktorkanal einbauen.
lg Harald.
Zitat von: Thorsten Pferdekaemper am 08 August 2015, 21:01:41
Hi,Das ist mit der aktuellen Version (0.7.9) unterstützt. Ich habe es allerdings etwas anders implementiert, in der Hoffnung damit noch ein paar weitere Eventualitäten abgedeckt zu haben. Kannst Du es mal ausprobieren?
Deine Version gefällt mir nicht so richtig. Ich werde meine Version behalten. Ich werde es trotzdem mal testen.
Mir ist aufgefallen, daß Du recht verschwenderisch mit der Rechenleistung umgehst. Es haben auch noch einige recht schwächliche Rechner wie die Fritzbox oder der Raspi1. Oder ist der aspekt mit der Rechenleistung vernachlässigbar?
Du hast 3 foreach-Schleifen ineinander verschachtelt. Bei dem config Teil dürfte es egal sein, aber ich denke man sollte bei der Verarbeitung der Response und Events einwenig darauf achten, daß man nicht so sehr verschwenderisch mit der Rechenleistung umgeht.
Beim HMW_IO12_SW14_DR reicht für die "info_frequency" folgende Abfrage:
if ( $frameTypeName eq "info_frequency" && $behaviour eq "digital_input") {
$frameTypeName = "info_level";
}ZitatNoch was @Ralf9: Hat sich das mit dem 'door_sensor.state' erledigt?
Kann es sein, das es mit dem hinzufügen von "state" zusammenhängt? Ohne state funktioniert es.
Ich habe mir mal das mit der Queue Geschichte beim Get Config angeschaut. Dies ist sehr komplex.
Ich habe es bei mir mal so erweitert, daß ich es produktiv auf meinem cubietruck einsetzen kann.
Zum Testen habe ich fhem auf dem cubietruck beendet und den HM485d.pl manuel gestartet.
Nun habe ich einfach im fhem auf meinem PC in der fhem.cfg folgendes eingetragen. Das "x" ist die IP des cubietruck.
define HM485_LAN HM485_LAN 192.168.0.x:2000
attr HM485_LAN hmwId 00000001
attr HM485_LAN room HM485Da auf dem cubietruck der Patch mit dem Fehler bei MsgId 252/253 noch nicht drin war, konnte ich sehr schön eine hängende Queue herbeiführen.
Eine hängende Queue dürfte zwar nur selten vorkommen, aber man sollte bei einem Problem mit dem Bus oder der Queue die Möglichkeit haben den Fehler einzugrenzen und die Queue abzubrechen ohne fhem neustarten zu müssen.
Ich habe nun die "sub HM485_SetConfigStatus" so erweitert, daß der configstatus auch im state eingetragen ist.
Damit ist es bei Busproblemen und einer hängenden Queue möglich, festzustellen welches Device probleme macht.
Es gibt jetzt die folgenden configstatus: Get Infos - Reading - Reading Start - Reading ok - Get State - OK
Mit dem set "'abort_getConfig' kann bei einem Device die Queue abgebrochen werden. Danach kann dann mit "get config all" das Device nochmals geladen werden.
Außerdem habe ich noch die Konstante RESPONSE_TIMEOUT_FLAG hinzugefügt. Bei 0 wird bei einem "response timeout" die config nicht mehr neu geladen.
Mit diesen Anpassungen ist die Version für mich auf dem cubietruck produktiv einsetzbar.
Ich habe u.a. folgendes geändert, siehe auch in der Anlage:
in der "sub HM485_Parse($$)" und "sub HM485_SetStateNack($$) "habe ich die folgende Abfrage eingefügt:
if (RESPONSE_TIMEOUT_FLAG == 1) { # die Config wird nur neu gelesen, wenn FLAG = 1In der "sub HM485_SetStateAck($$$)" habe ich eine Abfrage eingefügt, daß der state nur beim CONFIG_STATUS = 'OK' verändert wird.
In der "sub HM485_QueueProcessStep()" und "sub HM485_QueueStepSuccess($)" habe ich Abfragen zum Setzen des ConfigStatus eingefügt.
Ich hoffe ich habe nichts vergessen. Die Änderungen sind leider nur als Datei, die ich nicht mit dem GitHub arbeite.
Gruß Ralf
Zitat von: Ralf9 am 09 August 2015, 12:21:38
Du hast 3 foreach-Schleifen ineinander verschachtelt. Bei dem config Teil dürfte es egal sein, aber ich denke man sollte bei der Verarbeitung der Response und Events einwenig darauf achten, daß man nicht so sehr verschwenderisch mit der Rechenleistung umgeht.
Ich habe immer nur zwei Ebenen gezählt. Außerdem kommt ja normalerweise nach der ersten Abfrage (mit event, frame type, direction) kaum noch was in Frage. D.h. die Schleifen haben nachher maximal noch zwei Durchläufe. Außerdem dürften da nur Referenzen rumgeschaufelt werden, das dürfte nicht so weh tun.
Ich habe halt versucht, alle Eventualitäten zu unterstützen, auch wenn sich jemand mal ein Homebrew-Device mit nicht ganz so perfektem Device-File baut. Außerdem könnten ja auch noch neue Devices von HM kommen. (Theoretisch...)
Zitat
Beim HMW_IO12_SW14_DR reicht für die "info_frequency" folgende Abfrage:
if ( $frameTypeName eq "info_frequency" && $behaviour eq "digital_input") {
$frameTypeName = "info_level";
}
@honk: Die kompliziertere Abfrage in "meinem" Coding habe ich von Dir übernommen. Könntest Du mal nachsehen, ob das wirklich auch einfacher geht?
Zitat
Kann es sein, das es mit dem hinzufügen von "state" zusammenhängt? Ohne state funktioniert es.
Hier geht's um den Türsensor. Theoretisch kann das sein. Dann müsste aber im Reading "state" irgend was anderes erscheinen. Mit 0.7.11 habe ich da nochmal was geändert, es kann gut sein, dass das jetzt besser funktioniert.
Zitat
Ich habe mir mal das mit der Queue Geschichte beim Get Config angeschaut. Dies ist sehr komplex.
Naja, nicht gerade Rocket Science.
ZitatEine hängende Queue dürfte zwar nur selten vorkommen, aber man sollte bei einem Problem mit dem Bus oder der Queue die Möglichkeit haben den Fehler einzugrenzen und die Queue abzubrechen ohne fhem neustarten zu müssen.
Du hättest auch einfach "reload 10_HM485.pm" machen können.
Außerdem darf das wirklich nicht passieren. Das bedeutet nämlich auch, dass kein NACK erzeugt wird und das ist schon ziemlich zentral.
ZitatIch habe nun die "sub HM485_SetConfigStatus" so erweitert, daß der configstatus auch im state eingetragen ist.
Damit ist es bei Busproblemen und einer hängenden Queue möglich, festzustellen welches Device probleme macht.
Es gibt jetzt die folgenden configstatus: Get Infos - Reading - Reading Start - Reading ok - Get State - OK
Normalerweise könnte man das vielleicht auch mit "stateFormat" machen. Ich denke aber auch, dass man im Device state etwas mehr als nur ACK und NACK anzeigen könnte. Vielleicht übernehme ich das mal.
ZitatAußerdem habe ich noch die Konstante RESPONSE_TIMEOUT_FLAG hinzugefügt. Bei 0 wird bei einem "response timeout" die config nicht mehr neu geladen.
Ja, so etwas ähnliches hatten wir mal diskutiert. Ich würde das zwar als Attribut machen, aber im Prinzip sinnvoll.
ZitatMit diesen Anpassungen ist die Version für mich auf dem cubietruck produktiv einsetzbar.
Wieso erwähnst Du, dass es ein Cubietruck ist? Ist das Teil besonders problematisch?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 09 August 2015, 20:29:25
Hier geht's um den Türsensor. Theoretisch kann das sein. Dann müsste aber im Reading "state" irgend was anderes erscheinen.
Ich habe es nicht weiter untersucht warum der Türsensor nicht funktioniert hat. Ich habe es jetzt umgeschrieben, siehe unten. Es müsste jetzt alle Fälle abdecken.
ZitatAußerdem darf das wirklich nicht passieren. Das bedeutet nämlich auch, dass kein NACK erzeugt wird und das ist schon ziemlich zentral.
Das wirst Du nie ganz ausschließen können, das es bei der Queue Abarbeitung zu Problemen kommen kann. Eine Ursache könnte auch ein nicht ganz sauber programmiertes Homebrew Modul sein.
ZitatWieso erwähnst Du, dass es ein Cubietruck ist? Ist das Teil besonders problematisch?
Nein es hat keinen besonderen Grund, warum ich den Cubietruck erwähnt habe. Er läuft vollkommen problemlos.
Ich habe die "sub HM485_ChannelDoUpdate($)" so umgeschrieben, daß damit alle Fälle abgedeckt sein müssten.
Ich habe es mit zwei Konstanten konfigurierbar gemacht. Ich habe die Konstanten an den Anfang der 10_HM485.pm geschrieben, ist dies so ok, oder gibt es dafür einen besseren Platz?
use constant CHANNEL_UPDATE_STATE_FLAG => 0; # 1 = state readings auch bei keys und sensors
use constant CHANNEL_UPDATE_WORKING_FLAG => 1; # 0 = keine working readings, 1 = ondelay und on_time readings, 2 = working readings
Mit dem CHANNEL_UPDATE_STATE_FLAG kann das zusätzliche state in den readings deaktiviert werden. Es gibt hier einige die recht viele Notifys haben. Evtl funktionieren mit diesem zusätzlichen state die Notify nicht mehr richtig.
Mit dem CHANNEL_UPDATE_WORKING_FLAG=1 wird aus der kombination von state und working die neuen state ondelay und on_time erzeugt. Die passenden Icons sind in der Anlage.
sub HM485_ChannelDoUpdate($) {
my ($params) = @_;
my $chHash = $params->{chHash};
my $valueHash = $params->{valueHash};
my $name = $chHash->{NAME};
my $doTrigger = $params->{doTrigger} ? 1 : 0;
my $state = undef;
my $working = undef;
my $otherState = undef;
#print Dumper ($valueHash);
readingsBeginUpdate($chHash);
my $valueKey;
foreach $valueKey (keys %{$valueHash}) {
my $value = $valueHash->{$valueKey};
if (defined($value)) {
HM485::Util::logger( 'HM485_ChannelDoUpdate', 4, 'name = ' . $name . ' valueKey = ' . $valueKey . ' value = ' . $value . ' Alter Wert = ' . $chHash->{READINGS}{$valueKey}{VAL});
if ($valueKey eq 'working') {
if (CHANNEL_UPDATE_WORKING_FLAG > 0) {
$working = $value;
}
if (CHANNEL_UPDATE_WORKING_FLAG == 2) { # working ins readings
readingsBulkUpdate( $chHash, $valueKey, $value);
$working = undef;
}
} elsif ($valueKey eq 'state') {
$state = $value;
} else {
if (substr($valueKey,0 ,5) eq 'press') {
$chHash->{STATE} = $valueKey . '_' . $value;
} else {
$chHash->{STATE} = $value;
}
if (CHANNEL_UPDATE_STATE_FLAG == 1) {
$otherState = $chHash->{STATE};
}
readingsBulkUpdate( $chHash, $valueKey, $value);
}
}
}
if (defined($otherState)) {
readingsBulkUpdate( $chHash, 'state', $otherState);
}
if (defined($state)) {
if (defined($working) && $working eq 'on') {
HM485::Util::logger( 'HM485_ChannelDoUpdate', 4, 'working = on, state = ' . $state);
if ($state eq 'off') {
$chHash->{STATE} = 'ondelay';
} else {
$chHash->{STATE} = 'on_time';
}
} else {
$chHash->{STATE} = $state;
}
readingsBulkUpdate( $chHash, 'state', $chHash->{STATE});
}
readingsEndUpdate($chHash, $doTrigger);
}
Nachtrag:
Zitat von: Thorsten Pferdekaemper am 08 August 2015, 21:01:41
Hi,Das ist mit der aktuellen Version (0.7.9) unterstützt. Ich habe es allerdings etwas anders implementiert, in der Hoffnung damit noch ein paar weitere Eventualitäten abgedeckt zu haben. Kannst Du es mal ausprobieren?
Ich habe es inzwischen getestet, es funktioniert bei mir.
Gruß Ralf
ZitatBeim HMW_IO12_SW14_DR reicht für die "info_frequency" folgende Abfrage:
Code: [Auswählen]
if ( $frameTypeName eq "info_frequency" && $behaviour eq "digital_input") {
$frameTypeName = "info_level";
}
@honk: Die kompliziertere Abfrage in "meinem" Coding habe ich von Dir übernommen. Könntest Du mal nachsehen, ob das wirklich auch einfacher geht?
Hallo
Das Problem dabei ist, daß "$frameTypeName" (wo kommt das denn nun wieder her? bei mir heißt es "$frame"), einmal zuerst als "info_frequency" dann wieder einmal als erstes "info_level" daher kommt. Es wechselt also, da es im hash nicht sortiert ist. In dieser Version wird es also mal funktionieren und mal nicht.
Mein Vorschlag wäre
$ioHash->{'.waitForResponse'}{$requestId}{requestType}
zusätzlich um ein
$ioHash->{'.waitForResponse'}{$requestId}{requestTypeName}
zu erweitern. Dann ginge das parsen leichter.
Das gleiche auch bei .waitForAck, wenn das richtig funktioniert.
lg Harald
Zitat von: honk am 10 August 2015, 01:12:25Das Problem dabei ist, daß "$frameTypeName" (wo kommt das denn nun wieder her? bei mir heißt es "$frame"),
Das ist aus Ralfs Coding, ist im Prinzip dasselbe wie $frame.
Zitat
einmal zuerst als "info_frequency" dann wieder einmal als erstes "info_level" daher kommt. Es wechselt also, da es im hash nicht sortiert ist. In dieser Version wird es also mal funktionieren und mal nicht.
Ah ja, sowas habe ich mir fast gedacht. In meiner Version ist es sogar so, dass immer alle Frame-Definitionen durchgegangen werden, da ist es dann sogar egal, wie die Reihenfolge ist. Es würde nie funktionieren. Also lassen wir das mal besser so.
Zitat
Mein Vorschlag wäre
$ioHash->{'.waitForResponse'}{$requestId}{requestType}
zusätzlich um ein
$ioHash->{'.waitForResponse'}{$requestId}{requestTypeName}
zu erweitern. Dann ginge das parsen leichter.
Das gleiche auch bei .waitForAck, wenn das richtig funktioniert.
Wie schon per Mail: Meiner Meinung nach darf das Verarbeiten eines empfangenen Frames nicht davon abhängen, was man vorher gesendet hat. Ich habe es aber sowieso inzwischen so umgebaut, dass es immer funktionieren sollte. Im Prinzip werden immer alle Frame-Definition getestet. Wenn es mehrere gibt, dann wird in der Definition des Channel nachgesehen, welche die richtige ist.
Zitat von: Ralf9 am 10 August 2015, 00:15:42
Ich habe die "sub HM485_ChannelDoUpdate($)" so umgeschrieben, daß damit alle Fälle abgedeckt sein müssten.
Ich habe es mit zwei Konstanten konfigurierbar gemacht. Ich habe die Konstanten an den Anfang der 10_HM485.pm geschrieben, ist dies so ok, oder gibt es dafür einen besseren Platz?
Naja, Konstanten sind nie ein guter Weg, um irgendwas konfigurierbar zu machen. Dann müsste man das ja nach jedem Upgrade nachziehen.
ZitatMit dem CHANNEL_UPDATE_STATE_FLAG kann das zusätzliche state in den readings deaktiviert werden. Es gibt hier einige die recht viele Notifys haben. Evtl funktionieren mit diesem zusätzlichen state die Notify nicht mehr richtig.
Warum sollte das so sein?
ZitatMit dem CHANNEL_UPDATE_WORKING_FLAG=1 wird aus der kombination von state und working die neuen state ondelay und on_time erzeugt. Die passenden Icons sind in der Anlage.
Naja...
1. Das dürfte für Rolloaktoren nicht so ganz richtig aussehen
2. Bei Devices, die ihr Haupt-Reading im state haben, sollte man das nicht machen. Da gehört einfach on oder off rein, sonst funktionieren die notifies tatsächlich nicht mehr. (Ich habe den state-Update inzwischen so geändert, dass working oder direction nicht mehr dort landet.)
3. Ich denke, dass STATE nicht direkt geändert werden soll. Das macht FHEM zentral aus state und stateFormat.
3. Das mit den Icons müsste man doch auch mit FHEM-Bordmitteln hinbekommen. Gibt's da nicht ein Attribut, mit dem man das regeln kann?
Zitat
Nachtrag:Ich habe es inzwischen getestet, es funktioniert bei mir.
Danke für's Testen.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 10 August 2015, 09:39:10
Warum sollte das so sein?
Einige Notify mit sehr einfachen Bedingungen, werden durch das zusätzliche state wahrscheinlich doppelt ausgeführt.
Hätte ich bei mir das zusätzliche state aktiviert, müsste ich einige Notify umschreiben, damit sie nicht doppelt ausgeführt werden.
Zitat
Naja...
1. Das dürfte für Rolloaktoren nicht so ganz richtig aussehen
3. Das mit den Icons müsste man doch auch mit FHEM-Bordmitteln hinbekommen. Gibt's da nicht ein Attribut, mit dem man das regeln kann?
Bei den Modulen wie den Rolloaktoren, die keine state haben, wird das working ignoriert.
Die Info für ondelay und on_time kann nur aus der Kombination von state und working geholt werden.
Ralf
ZitatWie schon per Mail: Meiner Meinung nach darf das Verarbeiten eines empfangenen Frames nicht davon abhängen, was man vorher gesendet hat. Ich habe es aber sowieso inzwischen so umgebaut, dass es immer funktionieren sollte. Im Prinzip werden immer alle Frame-Definition getestet. Wenn es mehrere gibt, dann wird in der Definition des Channel nachgesehen, welche die richtige ist.
Ja danke sehr, das ist natürlich schöner und gefällt mir auch viel besser.
lg Harald
kann sich mal jemand in der "00_HM485_LAN.pm" die KeepAlive Geschichte anschauen. Da mir aufgefallen ist, daß es nicht funktioniert, habe ich es mir mal angeschaut. Dabei ist mir aufgefallen, daß "$hash->{keepalive}{ok}" nirgends auf "0" gesetzt wird.
Wenn ich in der "sub HM485_LAN_KeepAlive($)" bei "$hash->{keepalive}{ok} = 1;" aus der 1 eine 0 mache, funktioniert es.
Es passt aber noch nicht ganz. Wenn ich vom LAN-Gateway das LAN abziehe zählt zwar der "keepalive retry" von 0 auf 3 hoch, dies aber innerhalb von 3 Sekunden. Es sollte aber genauso wie beim keepAlive ein Abstand von 20 Sekunden sein.
2015.08.17 17:21:49 3: SW: fd024d4b
2015.08.17 17:21:49 3: HM485_LAN: RX: fd024d6100
2015.08.17 17:22:09 3: SW: fd024e4b
2015.08.17 17:22:09 3: HM485_LAN: RX: fd024e6100
2015.08.17 17:22:29 3: SW: fd024f4b
2015.08.17 17:22:30 3: HM485_LAN: KeepAliveCheckRetry 0
2015.08.17 17:22:30 3: HM485_LAN: keepalive retry = 0
2015.08.17 17:22:30 3: SW: fd02504b
2015.08.17 17:22:31 3: HM485_LAN: KeepAliveCheckRetry 1
2015.08.17 17:22:31 3: HM485_LAN: keepalive retry = 1
2015.08.17 17:22:31 3: SW: fd02514b
2015.08.17 17:22:32 3: HM485_LAN: KeepAliveCheckRetry 2
2015.08.17 17:22:32 3: HM485_LAN: keepalive retry = 2
2015.08.17 17:22:32 3: SW: fd02524b
2015.08.17 17:22:33 3: HM485_LAN: KeepAliveCheckRetry 3
2015.08.17 17:22:33 3: HM485_LAN: keepalive retry count reached. Disonnect
2015.08.17 17:22:33 1: 192.168.0.94:1000 disconnected, waiting to reappear (HM485_LAN)
Gruß Ralf
Ich habe zusätzlich noch in der "sub HM485_LAN_KeepAlive($)" folgendes geändert. Nun müsste das keepalive funktionieren.
# start timeout for next keepalive check
InternalTimer(
gettimeofday() + KEEPALIVE_TIMEOUT ,'HM485_LAN_KeepAlive', KEEPALIVE_TIMER . $name, 1
);
2015.08.18 19:48:05 3: HM485_LAN: TX: fd024e4b
2015.08.18 19:48:05 3: HM485_LAN: RX: fd024e6100
2015.08.18 19:48:25 3: HM485_LAN: TX: fd024f4b
2015.08.18 19:48:25 3: HM485_LAN: RX: fd024f6100
2015.08.18 19:48:45 3: HM485_LAN: TX: fd02504b
2015.08.18 19:48:45 3: HM485_LAN: RX: fd02506100
2015.08.18 19:49:05 3: HM485_LAN: TX: fd02514b
2015.08.18 19:49:06 3: HM485_LAN: KeepAliveCheckRetry 0
2015.08.18 19:49:06 3: HM485_LAN: keepalive retry = 0
2015.08.18 19:49:26 3: HM485_LAN: TX: fd02524b
2015.08.18 19:49:27 3: HM485_LAN: KeepAliveCheckRetry 1
2015.08.18 19:49:27 3: HM485_LAN: keepalive retry = 1
2015.08.18 19:49:47 3: HM485_LAN: TX: fd02534b
2015.08.18 19:49:48 3: HM485_LAN: KeepAliveCheckRetry 2
2015.08.18 19:49:48 3: HM485_LAN: keepalive retry = 2
2015.08.18 19:50:08 3: HM485_LAN: TX: fd02544b
2015.08.18 19:50:09 3: HM485_LAN: KeepAliveCheckRetry 3
2015.08.18 19:50:09 3: HM485_LAN: keepalive retry count reached. Disonnect
2015.08.18 19:50:09 1: 192.168.0.94:1000 disconnected, waiting to reappear (HM485_LAN)
2015.08.18 19:53:24 1: 192.168.0.94:1000 reappeared (HM485_LAN)
2015.08.18 19:53:24 3: HM485_LAN: connected to device 192.168.0.94:1000
Hier sind die geänderten "sub HM485_LAN_KeepAlive($)" und "sub HM485_LAN_KeepAliveCheck($)"
sub HM485_LAN_KeepAlive($) {
my($param) = @_;
my(undef,$name) = split(':',$param);
my $hash = $defs{$name};
my $msgCounter = $hash->{msgCounter};
$hash->{keepalive}{ok} = 0;
if ($hash->{FD}) {
HM485_LAN_Write($hash, HM485::CMD_KEEPALIVE);
# Remove timer to avoid duplicates
RemoveInternalTimer(KEEPALIVE_TIMER . $name);
# Timeout where foreign device must response keepalive commands
my $responseTime = AttrVal($name, 'respTime', 1);
# start timer to check keepalive response
InternalTimer(
gettimeofday() + $responseTime, 'HM485_LAN_KeepAliveCheck', KEEPALIVECK_TIMER . $name, 1
);
# start timeout for next keepalive check
InternalTimer(
gettimeofday() + KEEPALIVE_TIMEOUT ,'HM485_LAN_KeepAlive', KEEPALIVE_TIMER . $name, 1
);
}
}
=head2
Check keepalive response.
If keepalive response is missing, retry keepalive up to KEEPALIVE_MAXRETRY count.
@param string name of keepalive timer
=cut
sub HM485_LAN_KeepAliveCheck($) {
my($param) = @_;
my(undef,$name) = split(':', $param);
my $hash = $defs{$name};
if (!$hash->{keepalive}{ok}) {
# we got no keepalive answer
HM485::Util::logger($name, 3, 'KeepAliveCheckRetry ' . $hash->{keepalive}{retry});
if ($hash->{keepalive}{retry} >= KEEPALIVE_MAXRETRY) {
HM485::Util::logger($name, 3, 'keepalive retry count reached. Disonnect');
# keepalive retry count reached. Disonnect.
DevIo_Disconnected($hash);
} else {
HM485::Util::logger($name, 3, 'keepalive retry = ' . $hash->{keepalive}{retry});
$hash->{keepalive}{retry} ++;
# Remove timer to avoid duplicates
RemoveInternalTimer(KEEPALIVE_TIMER . $name);
# start timeout for repeated keepalive check
InternalTimer(
gettimeofday() + KEEPALIVE_TIMEOUT, 'HM485_LAN_KeepAlive', KEEPALIVE_TIMER . $name, 1
);
}
} else {
$hash->{keepalive}{retry} = 0;
}
}
Gruß Ralf