Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter

jab · 15 Januar 2014, 22:17:55

Moin Martin,

hast du einen Vorschlag wie man das allgemeiner lösen kann? Teilweise gibt es in der 10_CUL_HM.pm ja eh redundanz. Z.b. ist das Handling für 02:01 ACK und 10:06 Info_Status für den SubType powerMeter fast gleich wie bei switch. Man müsste den Channel früher extrahieren. Das ist aber gar nicht so einfach, weil es den ja nicht in allen Messages überhaupt gibt. Steht der Channel wenigstens immer an der gleichen Stelle?

Ich stehe jetzt vor der Entscheidung wie ich den Stromsensor implementiere. Den AD anzusprechen klappt ohne Probleme. Man bekommst 10bit also 0-1023 als Wert raus. Die genaue Skala kann man später ausrechnen. Die Frage für mich ist jetzt wie ich es an FHEM übertrage. Im Code habe ich den HM-ES-PMSw1-Pl gefunden. Er hat pro Messwert einen eigenen Channel mit ein paar Registern zum schalten und nutzt mTp 5E + 5F zum übertragen der Werte.
1. Soll ich den MessageType recyceln? Oder einen neuen erfinden? Ich habe jetzt erstmal 5E benutzt und alle anderen Werte 0 gesetzt.
2. Wie implementiere ich mein Gerät am besten? Eigenes elsif in der 10_CUL_HM? Ich habe einen quick and dirty patch gebaut (angehängt).
3. Wie oft schick ich den Wert am besten? Ich habe jetzt erstmal alle 30s gebaut.

Gruß,
Jan

martinp876 · 16 Januar 2014, 09:45:48

Hi Jan,

ich habe einmal grob durchgesehen - es gibt noch ein paar messages die man als "common" parsen könnte, aber nicht viele. Es gibt immer wieder unterschiede.

Es gibt die möglichkeit das Parsen je kanal einzubauen... für messages die einen Kanal mitliefern. Oft definiert HM bei messages einen fixen Kanal... das gibt es in FHEM nicht konfigrierbar.
Etwas besser würde mir gefallen eine Funktion auszulagern. Hat den Vorteil, dass der User Dinge realisieren kann, die HM devices nicht bieten. Der aktuelle Fall, dass kanäle 'wild gemischt' werden ist ein sonderfall der eigenbau-FW.
Die Schwierigkeit ist, welche Daten alle an die Prozedur übertragen werden müssen, damit nicht alles gesondert errechnet werden muss.

zu 1)
mTp 53 finde ich elegant. Man überträgt 1 byte adresse und 2 Byte daten. Es können mehrere daten in einer message übertragen werden
aber du kannst auch 5E/5F nutzen.
Die Auswertung muss dann in einer ausgelagerten Funktion erfolgen - siehe oben
zu 2) ich denke an eine Prozedur wenn subType = myNewSubtype ist dann in einem eigenen File ein CUL_HM_myNewSubtype(@) definieren. Ich halte es nicht für sinnvoll das File 10_CUL_HM zu editieren - da schneidet man sich von updates ab
zu 3)
gute Frage - 30sec ist recht oft. Sollte man es einstellbar/abschaltbar machen? machen trigger sinn? Wie willst du es verwenden? Wenn du mehrere Devices hast,die alle 30 sec senden wollen kann es eng werden.

Gruss Martin

martinp876 · 16 Januar 2014, 10:41:26

Hi Jan,

ich habe eine Version eingecheckt, mit der der User eigene parser einhängen kann. Aktuell ist dies nachrangig - man kann also vorhandenen parser nicht überschreiben.

Wenn du nun einen subType "myRemoteSwitch" nutzt kannst du in einem separaten File folgende Funktion definieren

Code Auswählen

sub CUL_HM_ParsemyRemoteSwitch($$$$$) {
  my($mFlg,$mTp,$src,$dst,$p) = @_;
  Log 1,"General  entering with $mFlg,$mTp,$src,$dst,$p";
  my @entities;
  push @entities,CUL_HM_UpdtReadBulk($defs{"FB2"},1,
                                             ,"trigger70:"."external");
  return @entities;
}

Readings setzen würde ich übe rCUL_HM_UpdtReadBulk.
Alle entities die geändert wurden müssen in @entities zurückgegeben werden.

Ist das so ok? Du kannst dann den Code aus Remote und switch reinkopieren - oder andere wilde sachen machen

Gruss Martin

jab · 16 Januar 2014, 11:50:01

Hi Martin,

1. 53 gucke ich mir an. Ich wollte nur zu den bestehenden Typen kompatibel bleiben damit es andere noch verstehen.
2. das klingt super. Dann kann ich einfach ein neues File mitliefern (99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm) das auch die Device Definition an sich enthält. Ich probiere das später aus. Muss ich die Funktion noch registrieren? Oder wird die automatisch aufgerufen?
3. Das ist sicher die beste Idee das konfigurierbar zu machen. Default dann alle 2,5 Min oder so.

Gruß,
Jan

martinp876 · 16 Januar 2014, 12:43:12

ZitatMuss ich die Funktion noch registrieren? Oder wird die automatisch aufgerufen?

wenn keine passende gefunden wird (also aktuell 'nachrangig') wird sie automatisch aufgerufen. Du solltest vorhandenen funktionen aus CUL_HM nutzen können - so z.B. das setzen von Readings im block: CUL_HM_UpdtReadBulk. Sollten Beispiele in CULHM zu finden sein.

Samsi · 16 Januar 2014, 13:25:19

Hallo Jan,

ZitatIch stehe jetzt vor der Entscheidung wie ich den Stromsensor implementiere. Den AD anzusprechen klappt ohne Probleme. Man bekommst 10bit also 0-1023 als Wert raus

Kann man damit tatsächlich den Strom der angeschlossenen Lampen messen? Ich dachte bisher man kann damit nur messen ob Spannung anliegt und somit den Status des anderen Wechselschalters bestimmen.

Grüße

jab · 16 Januar 2014, 15:01:52

Moin,

@Samsi: Ich hab mir das noch mal genauer angeschaut bzw eingebaut getestet. Wenn ich den Schaltplan genauer anschaue hast du vermutlich recht. Der zweite OpAmp wirkt als Vergleicher. Referenz sollte ca 1,5V sein. Er verstärkt dann an -V_DD (0) bzw V_DD (3,3V). Ich werde es die Tage mal eingebaut testen.

@martin: Habe es probiert aber aktuell noch verschiedene Probleme:
1. Wenn ich das Device in meinem File (FHEM/99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm) anlegen will dann funktioniert das nur für Aktoren die ich neu anlerne. Aktoren die aus der Config geladen werden funktionieren nicht. Das funktioniert nur wenn ich den Code in die FHEM/10_CUL_HM.pm kopiere. Was mache ich falsch?

Code Auswählen


{$HMConfig::culHmModel{"F0A9"} = {name=>"HM-LC-Sw1PBU-FM-CustomFW",st=>'remoteAndSwitch',cyc=>'',rxt=>'',lst=>'1,3:3p,4:1p.2p',chn=>"Btn:1:2,Sw:3:3"}}
{$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW01"} = $HMConfig::culHmSubTypeSets{"THSensor"}};
{$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW02"} = $HMConfig::culHmSubTypeSets{"THSensor"}};
{$HMConfig::culHmChanSets{"HM-LC-Sw1PBU-FM-CustomFW03"} = $HMConfig::culHmSubTypeSets{"switch"}};
{$HMConfig::culHmRegChan{"HM-LC-Sw1PBU-FM-CustomFW01"}  = $HMConfig::culHmRegType{remote}};
{$HMConfig::culHmRegChan{"HM-LC-Sw1PBU-FM-CustomFW02"}  = $HMConfig::culHmRegType{remote}};
{$HMConfig::culHmRegChan{"HM-LC-Sw1PBU-FM-CustomFW03"}  = $HMConfig::culHmRegType{switch}};

2. Ich habe den Code geupdatet. Allerdings habe es nicht geschafft meinen eigenen Parser aufgerufen zu bekommen. Ich habe folgende Methode in FHEM/99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm und FHEM/10_CUL_HM.pm probiert aber leider keinerlei Logeinträge erzeugen können. Was mache ich falsch?

Code Auswählen


sub CUL_HM_ParseremoteAndSwitch($$$$$) {
  my($mFlg,$mTp,$src,$dst,$p) = @_;
  Log 1,"General  entering with $mFlg,$mTp,$src,$dst,$p";
  my @entities;
  push @entities,CUL_HM_UpdtReadBulk($defs{"FB2"},1,
                                             ,"trigger70:"."external");
  return @entities;
}

Gruß,
Jan

Samsi · 16 Januar 2014, 16:55:27

@Jan
Dann wird es vermutlich auch ausreichen das nur bei Änderung zu übertragen. Eigentlich bräuchte man es dann vermutlich gar nicht, weil in Kombination mit einem Wechselschalter sollte ja dann das Licht getoggelt werden und danach der status des Lichts übertragen werden.

Allerdings hätte ich da wieder eine nette Idee. Wenn man keinen Wechselschalter hat, könnte man das evtl. als Input nehmen. Also das man die FW so konfigurieren kann, das das licht nicht getoggelt wird, sondern als weiterer Channel agiert mit dem an dann etwas anderes steuern könnte

Vorausgesetzt der Aktor ist so konzipiert, das es nichts ausmacht, wenn die Phase gleichzeitig an den Ausgängen 1 und 2 anliegt.

Grüße

martinp876 · 16 Januar 2014, 20:21:27

Hi Jan,

zu 1)
ich vermute, es ist ein Problem des zeitlichen ablaufs bei Systemstart.

zu 2)
dein Device hat subType "remoteAndSwitch"
und der 'alte' eintrag für diesen Subtype existiert nicht mehr?
das Device sendet eine Massage - und die sollte dann hier enden.
Hast du das so konfiguriert?

Gruss Martin

jab · 16 Januar 2014, 22:45:44

Hi Martin,

zu 1) Ja das vermute ich auch. Kann ich daran irgendwie was ändern? Ich würde gerne ein separates File haben in dem ich alle Definitionen habe
zu 2) Beides ja. Ich habe verifiziert, dass der Code in der 10_CUL_HM.pm in den else Branch läuft und $st eq "remoteAndSwitch" ist:

Code Auswählen


  else{########################################################################
    ; # no one wants the message
  }

Trotzdem wird meine Methode nicht aufgerufen. Die 10_CUL_HM.pm habe ich heute morgen geupdatet.

EDIT: Scheinbar war der Commit erst gegen 19 Uhr im SVN (http://sourceforge.net/p/fhem/code/4668/). Ich teste jetzt noch mal damit.

Gruß,
Jan

jab · 17 Januar 2014, 01:21:49

Hi,

@martin: Sieht schon sehr gut aus. Danke dir! Ich habe das noch etwas erweitert:

Code Auswählen


  elsif (eval "defined(&CUL_HM_Parse$st)"){####################################
    no strict "refs";
    my @ret = &{"CUL_HM_Parse$st"}($mFlg,$mTp,$src,$dst,$p,$target);
    use strict "refs";
    push @entities,@ret;
    push @event,"" if (@ret);
  }

Ansonsten funktioniert es gut. Wenn wir jetzt noch eine Lösung für 1 finden dann ist alles in meinem File abstrahiert.

Gruß,
Jan

martinp876 · 17 Januar 2014, 11:30:20

Hi Jan,
ja, war noch ein Fehler drin... schlecht eingecheckt gestern...

target habe ich addiert - leider kann man nicht alles mitsenden... IO device,...

zu 1)
du kannst $init_done abfragen. Wenn es korrekt implementiert ist sollte es erst '1' sein, wenn alles wieder gelesen ist.
Alternativ kannst du es verzögert starten. Wenn du aufgerufen wirst kannst du einen timer starten der dann die Änderungen/Erweiterungen durchführt.
Wasserdicht ist die Kombination aus beiden - verzögeren bis init_done....

sub aufruf (){
InternalTimer(getimeofday()+10,"myChConfFktn","parameterNotNecessary", 0);
}
sub myChConfFktn(){
$HMConfig::culHmModel{"F0A9"} = {name=>"HM-LC-Sw1PBU-FM-CustomFW",st=>'remoteAndSwitch',cyc=>'',rxt=>'',lst=>'1,3:3p,4:1p.2p',chn=>"Btn:1:2,Sw:3:3"};
.......
}

strauch · 17 Januar 2014, 12:17:56

Als Bewohner von 2 Kreuz und 3 Wechselschaltung und ohne Keller und damit auch ohne entsprechendem Duaktenesel in selbigem, bin ich sehr Interessiert an der Alternativen Firmware. Einen Unterputz-HM-Aktor habe ich davon auch zu hause. Falls ihr mal einen dummen Tester braucht, bin ich wohl dafür zu haben.

Danke schonmal für die ganze Arbeit.

jab · 17 Januar 2014, 13:43:42

Hi,

@strauch: Testen kann du sehr gerne. Hast du einen ISP Programmer oder alternativ einen Raspberry PI? Das flashen ist nicht schwer allerdings muss man vorher 6 Leitungen anlöten.

@Samsi: Ich habe mir die Schaltung heute mal mit dem E-Techniker meines Vertrauens näher angeschaut. Erkennung ob es an oder aus ist geht auf jeden Fall. Ich habe die ganze Schaltung mal simuliert (siehe Bild Anhang). Zusätzlich kann man aber auch eine Aussage über den Strom der fließt machen. Wobei das nur für symetrische Lasten (also Geräte den positive und negativen Durchgang gleich belasten) richtig funktioniert. Bei Ohmschen Lasten also kein Problem. Welche Zeit welchem Strom entspricht wäre zu klären. Kann man berechnen, simulieren oder ausprobieren. Es ist auch kein Problem an beide Ausgänge was anzuschließen. Der Relais schaltet einfach zwischen beiden um.

Ich werde zwei Dinge einbauen:
- Ich werde einen weiteren Kanal anlegen der den Status des Verbrauchers angibt. Dazu nutze ich die gleiche Message 10-06. Da kann man dann auch zusätzlich schalten (ggf halt nur toggle).
- Den Strom liefere ich periodisch zurück. Dabei messe ich die Dauer des Impulses und wir müssen das später mal interpretieren. Message 5E aktuell. Stelle ich vielleicht noch auf 53 um wir Martin vorgeschlagen hat.

@Martin: Funktioniert so hervorragend. Danke dir! Das File sieht jetzt so aus: https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM/blob/master/fhem/99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm

Gruß,
Jan

strauch · 17 Januar 2014, 14:52:04

Zitat von: jab am 17 Januar 2014, 13:43:42
@strauch: Testen kann du sehr gerne. Hast du einen ISP Programmer oder alternativ einen Raspberry PI? Das flashen ist nicht schwer allerdings muss man vorher 6 Leitungen anlöten.

Hi Jan,

ich hab nen RasbPi(da läuft FHEM drauf), ich auch diverse Arduino Teile und einen ISP Programmer kaufe ich wohl. Geht der weiter vorne im Thread verlinkte http://www.ebay.de/itm/USBasp-ASP-USBISP-3-3V-5V-AVR-Download-Programmer-Connector-USB-ATMEGA8-ATMEGA8-/300963812987?pt=LH_DefaultDomain_15&hash=item4612d7567b . Und zum Löten hab ich Verwandtschaft

. Ich brauch nur ne Anleitung wo was dran muss, falls es hier schon stand hab ich es überlesen und such noch mal. Edit: Ok steht ja hier alles: https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM

Danke

Grüße

strauch