[HM-Wired] Vereinigung der Versionen "honk" und "gevoo/thorsten"

[Thorsten Pferdekaemper]

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
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.

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

[Ralf9]

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.

Code Auswählen Erweitern


} 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

[Thorsten Pferdekaemper]

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.

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.

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

[hglaser]

Hallo Thorsten

Danke, daß Du nun meine Version eingepflegt hast.

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.

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

[Thorsten Pferdekaemper]

Danke, daß Du nun meine Version eingepflegt hast.

Naja, noch lange nicht alles.

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.

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

[hglaser]

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.

[Thorsten Pferdekaemper]

Hi,
die aktuelle Version in 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

[hglaser]

Hallo Thorsten

sehr schön . Der link ist https://github.com/hresalg/FHEM-HM485

lg Harald

[Thorsten Pferdekaemper]

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.

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.

Das ist jetzt auch geändert.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

sehr schön . Der link ist 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

[Thorsten Pferdekaemper]

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

[Ralf9]

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.

[stephan-221]

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

[Thorsten Pferdekaemper]

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.

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.

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.

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.

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.

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.

Wie gesagt, die Queue wird bei einem NACK (Response Timeout) sowieso gelöscht. 

Ist diese Frage hier ok, oder soll ich dies nach "Homematic wired" verschieben?

Ist schon ok, das ist sozusagen momentan der "dev" Thread.

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".

- 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.

- 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.

- 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   
   

[hglaser]

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.

Code Auswählen Erweitern

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