HM_LC_Sw1PBU_FM Taster geht nicht

[Columbus]

Hallo zusammen,

ich habe ein Verständnisproblem mit meinem HM_LC_Sw1PBU_FM.
Er ist mit FHEM gepaired und ich kann erfolgreich mein Licht per Weboberfläche schalten.
Jedoch kann ich den Taster am Schalter selber nicht mehr nutzen. Da Frage ich mich aber schon warum? Wenn das normal wäre, hätte ich mir ja auch direkt den HM-LC-SW1-FM kaufen können.
Im Wiki ist ein Workaround beschrieben, der bei mir leider nicht funktioniert (regSet unbekannt)

Bitte klärt mich auf

Liebe Grüße

Columbus

[martinp876]

Hi Columbus.

sowohl bei PBU alsauch bei SW1-FM kann man die lokalen taster/eingänge nach dem pairen noch nutzen. Warum dies bei dir nicht klappt ist mir ohne infos unklar.

das Kommando
set <entity> regSet <register> <wert> [<peer>]
geht eigentlich bei jedem Device.

die internen Taster sind selbst unsichtbar - aber sie sind gepeert mir dem/einem Kanal. Die Register dieses peerings sind per default unsichtbar und müssen über das Register intKeyVisib sichtbar geschaltet werden.
Und hier kannst du dann festlegen, was passieren soll. Ggf noch einmal die Register lesen (sollte bei FHEM default settings automatisch funktionieren)

Gruss Martin

[Columbus]

OK, danke!
Dann wird es wohl irgendwie funktionieren und ich weiß wo ich weiter machen muß.

Danke!

[jab]

Das habe ich beim Workaround im Wiki in der Tat vergessen zu erwähnen. Ich erweitere das mal entsprechend. Nach dem regSet braucht man dann vermutlich ein getConfig. Bitte teste mal ob das so geht wie es im Wiki steht. Ich habe aktuell leider keinen HM_LC_Sw1PBU_FM mit Originalfirmware da.

Gruß,
Jan

[Columbus]

Hi Jab,

wenn ich

Code Auswählen Erweitern

set  HM-LC-Sw1PBU-FM regSet prep shSwJtOff off self01 ausführe erhalte ich:

Code Auswählen Erweitern


prep failed: supported register are intKeyVisib lgActionType lgCtDlyOff lgCtDlyOn lgCtOff lgCtOn lgCtValHi lgCtValLo lgMultiExec lgOffDly lgOffTime lgOffTimeMode lgOnDly lgOnTime lgOnTimeMode lgSwJtDlyOff lgSwJtDlyOn lgSwJtOff lgSwJtOn localResDis pairCentral shActionType shCtDlyOff shCtDlyOn shCtOff shCtOn shCtValHi shCtValLo shOffDly shOffTime shOffTimeMode shOnDly shOnTime shOnTimeMode shSwJtDlyOff shSwJtDlyOn shSwJtOff shSwJtOn sign statusInfoMinDly statusInfoRandom transmitTryMax

Kannst du damit etwas anfangen?

VG
Andreas

[martinp876]

Hi Andreas,

wie alt ist deine Version? bitte updaten!

Gruss Martin

[Columbus]

Hmm, vor etwa 10 Tagen von der HP runtergeladen. Ist also die aktuelle 5.5.

Und wenn ich manuell update wechsle ich doch automatisch auf die Entwicklerversion, oder? Ehrlichgesagt bin ich für eine Entwicklerversion nicht gut geeignet 

[martinp876]

Hi Andreas,

du solltest einen update machen.
keine Ahnung, was in 5.5 drin ist. FHEM hat keine richtigen Releases mit final Test und so weiter, wie das professionelle Systeme machen. Dann müsste FHEM ja fixes für Releases anbieten...

Ein Update ist - nicht immer - aber doch meist sehr stabil  (mene Meinung..)
Nur Mut - man muss kein Entwickler sein, um es zu nutzen - und die test-abdeckung ist auch nicht besser.

Gruss Martin

[Rohan]

Hallo Andreas, hallo Martin,

... keine Ahnung, was in 5.5 drin ist. ...

Ist (Zitat): "Last released version: (as of 2013-09-29)"
und da gab es den "prep"/"exec" noch nicht.

@Andreas: Nur keine Scheu, du verpasst sonst einiges! Das Risiko ist minimal, zumal vor einem Update immer ein Backup gemacht wird (außer man hat es bewusst abgeschaltet).

... wie das professionelle Systeme machen.

Hmmm .... was ist Fhem denn dann?  Das Gegenteil von professionell ist? ... SCNR

Gruß
Thomas

[martinp876]

Hi Thomas,

ob Professionell besser ist  ist eine andere Frage.
In FHEM dürfen viele mitmachen - und machenm.E. einen gute Job

Von einer Professionellen (und kommerziellen) SW erwarte ich, dass es Releases gibt. Diese werden gemaintainet, es muss also fixes dafür geben. Releases werden in ihrer Gesamtheit vor einer Freigabe getestet. Es müssen deutlich striktere Regeln vorhanden sein und eingefordert werden.

In FHEM gibt es keine Freigabeprozeduren, Prozesse, architekturdokumente, interne interfaces incl dokumente ... alles das, was einen professionellen Angang - insbesondere bei mehr als 2 Entwicklern die nicht kontinuierlich in Kontakt sind notwendig ist, die Sache nach aussen so langsam machen,....
Dokumentation und deren Freigabe allein kostet schon erheblichen Aufwand (der sich normal irgendwann auszahlt - nach einiger Zeit)

Das ist übrigens ein Grund, warum FHEM so schnell ist! man muss eben nicht auf die Processe warten. 

Ich unterscheide professionell von kommerziell, da manche kommerziellen Produkte gebastelt sind und diesem Standard nicht genügen.

Das ganze ist - wie oben erwähnt - keine Wertung der Qualität der Module sondern des Frameworks.

FHEM ist ein Freizeitprodukt (lunch-hour-project) - zumindest für einige der Entwickler.

Alles nur meine private sicht der Dinge!!!

Gruss Martin

[Rohan]

Ups,

sorry, ich hoffe, ich bin jetzt *niemandem* mit meinem als Auflockerung gedachten (aber wohl mistverständlichem) Einschub zu nahe getreten. Falls dem so ist, bitte ich ausdrücklich um Entschuldigung. Ich wollte solch eine Reaktion sicher nicht provozieren, da ich erahnen kann, was für ein Aufwand und persönliches Engagement dahinter steckt.

Und "schlecht reden" wollte ich Fhem damit in keinster Weise.

In diesem Sinne.

Man liest sich.

Gruß
Thomas

[Columbus]

OK, danke für die Erklärung der Updatepolitik von FHEM!
Update ist gemacht und set  HM-LC-Sw1PBU-FM regSet prep shSwJtOff off self01 läuft auch durch.

Für mehr hatte ich jetzt noch keine Zeit.

Danke an Alle!

LG
Andreas