Busch Jäger Taster für Homematic

Begonnen von T.ihmann, 13 April 2013, 14:15:17

Vorheriges Thema - Nächstes Thema

selfarian

Hi Martin,

ok, das klingt gut ;)
Ich wollte an sich nur mal die Verkabelung "ohne Wand" mit den 2 neuen Tastern testen und durchspielen ;)
Erhält der PBI auch peers an, wenn ich nur mit ihm und der Zentrale und dummys spiele?
Die Peers sind ja dann auf die einzelnen Channels, von denen der PBI ja 4 haben müsste. Woher weiß der PBI bzw. PBU eigentlich dann, welcher Channel gepeert werden soll?...

Gruß,
Alex
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

martinp876

Alex,

ein PBI ist, wie fast alle Sensoren bei HM ziemlich dumm.
Peeren kann man nach beiliegender Anleitung, ohne FHEM. Da ist beschrieben, wie man den Channel auswaehlt.
Ich habe das noch nie gemacht, interessiert mich nicht.
HM Grundsatz: Wenn das Device einer Zentrale zugeordnet ist (gepairt ist) kann es sich nicht mehr selbst peeren, das manch dann die Zentrale.

Ich empfehle und verwende nur das peeren mit Zentrale - also erst pairen (das Device, einmal) dann peeren/unpeeren der channels nach belieben.
Schau die einmal peerChan an, baue die einen virtuellen Aktor und peere den. Lese die Config aus dem PBI aus. Im Kommando ist das Festlegen des Channels offensichtlich - siehe commandref.

Ja, der PBI hat 4 Channels. Jeder channel kann mit mehreren Aktor-channels gepeert werden.

Ein Sensor hat die Aufgaben trigger/events zu senden. Wenn er gepeert willer von jeden seiner Peers ein ACK zurueck. Der PBI kann eigentlich nur 2 trigger je Kanal: short press und Long Press. FHEM erkennt auch das loslassen eines long-press, aber nur wenn du den channel gepeert hast.

Wird sicher alles klarer wenn du am Wochenende damit spielst.

Gruss
Martin

Matzek83

Hallo zusammen,
tolle Übersicht hier - jetzt hab ich's auch verstanden! :-)
Ich habe eben mal meine Schalter gezählt und mit 40 Euro multipliziert - sehr abschreckend, ganz zu schweigen vom Installationsaufwand (und vom Vermieter!!!).

Ich möchte das neue hue-Modul in die Diskussion mit einbringen, das ich hoffentlich bald integrieren kann :-). Es könnte eine gute Alternative für einige Anwendungsfälle sein. Z.B. mein Wohnzimmer: Standard-E27-Lampe und 4 Standardschalter. Vorteile hue: günstiger(60 Euro bei vorhandener Bridge), kein Installationsaufwand, tolle weitere Möglichkeiten mit Farben usw. (WAF), günstige Zwischenstecker erhältlich, UMZUGSTAUGLICH. Nachteile: Bridge nur im Paket mit 3 Lampen für 200 Euro erhältlich, nur mit einer E27-Lampe, die Lampe wird stromlos geschalten beim Betätigen der Schalter und sollte sich mit fhem nicht einschalten lassen (evtl. lässt sich ein zusätzlicher HM-Aktor integrieren).
Diese Auflistung stützt sich nur auf Internetrecherche - ich habe weder die von euch genannten HM-Devices noch die hue's testen können.

Was haltet ihr davon? Gibt es einen Glücklichen, der beides hat und vergleichen konnte?

MfG
Matzek

selfarian

Hallo zusammen,

ich wollte mal einen kurzen Zwischenstand berichten und habe noch 2 Fragen :-)
Also insgesamt hat es bisher (habe nur die PBU eingebaut) relativ gut geklappt. Die einzigen Hürden waren, das sich der L-Leiter leider nicht - wie gedacht - im EG befindet, sondern im OG, somit musste ich die PBU leider im EG setzen, wo ich eigentlich einen Serientaster (für Licht+Alarmanlage) vorgesehen hatte. Jetzt muss ich mal sehen, wie ich das umsetze, wahrscheinlich muss ich dann asap die Schalter der Außenbeleuchtung noch ersetzen, so dass ich hier einen Serientaster einsetzen kann. Allgemein ist mir dann aufgefallen, das ich leider etwas kleine UP-Dosen habe, so dass die PBU vom Durchmesser her milimeter-genau in die Dose passt. Ich musste lediglich noch ein paar Putzreste vom Rand abkratzen. So kann ich mir fast die Schrauben sparen ;)

Meine Fragen zu dem Thema wären:
- Kann ich die PBU so "umprogrammieren", das die Tasterbelegung "oben" und "unten" anders belegt wird?
  Also das entweder z.B. Taster unten drücken z.B. einen Toggle auslöst und Schalter oben eine andere Aktion. Oder eben, das ich einfach "on" (derzeit oben) und "off" vertausche (ja... man könnte
  auch die PBU umdrehen, aber das ist bei der UP-Dosengröße etwas schwierig.
- Ich habe im Wiki gesehen, das man die Treppenbeleuchtung ungefähr so definieren kann:
define Beleuchtung_an notify Beleuchtung:on* define Beleuchtung_aus at +00:10:00 set Beleuchtung off
  Nach dem Beispiel würde er ja von FHEM nach 10 Minuten das off-Signal senden. Gibt es hier keine Möglichkeit, das die PBU das selbst tut, ohne das ein Funk-Signal gesendet wird?
  Ich hab jetzt zwar noch keine Probleme mit dem Funkverkehr, aber ich würde immer versuchen, das von Anfang an zu optimieren :). Allerdings, wenn die PBU das selber könnte, würde es ja
  vermutlich FHEM wieder nicht mitbekommen, das das Licht ja jetzt aus ist.
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

martinp876

Hi Alex,

ZitatKann ich die PBU so "umprogrammieren",
ja, geht. Die "eingebauten" Tasten sind SW-technisch nichts anderes als gepeerte Sensoren, die aber normal nicht sichtbar sind. Also erst einmal sichtbar machen und lesen:
set <pbu> setReg intKeyVisib visib
set <pbu> getConfig
attr <pbu> expert 2


Jetzt kannst du sehen (und aendern) was die internen Schalter machen sollen. Einer sollte self1 und der 2. self2 heissen. Drehen kannst du durch umprogrammieren der Register oder setzen der gesamten "registerbank". Hier das mit der Registerbank:
erste einmal speichern
get <pbu> saveConfig <myFile>
legt ein file an, in dem die Register gespeichert sind in der Form
"set <pbu> regBulk "
Es gibt 2 Listen mit RegL_03:Self01..... und Self02. Diese nimmst du, vertauscht 01 mit 02 und fuehrst sie aus. Dann sollte alles getauscht sein.


ZitatGibt es hier keine Möglichkeit, das die PBU das selbst tut
klar. Das kannst/musst du pro 'peer' setzen. Wenn du also einen Treppenhausschalter willst kannst du die ganze Arbeit davor vergessen - willst du ja eh nicht.

Schalter die internen schalter sichtbar. Dann setze die onTime in sekunden, wie lange du es haben willst. Du kannst als setzen
shOnTime  #short press
lgOnTime  #long press
und zwar jeweils fuer self01 und self02

ZitatIch hab jetzt zwar noch keine Probleme mit dem Funkverkehr
So etwas wuerde ich immer im HM device machen. Ich will auch Licht ohne Zentrale - und HM kann das.
ZitatAllerdings, wenn die PBU das selber könnte, würde es ja vermutlich FHEM wieder nicht mitbekommen, das das Licht ja jetzt aus ist.
Ein HM Aktor sendet evtl nicht jeden transienten Zustand an die Zentrale, aber den letzten, stabilen sollte es in jeden Fall melden.
Gruss Martin

selfarian

Hi Martin,

ich scheitere leider am "set fl_licht regSet intKeyVisib visib".
Er sagt mir hier immer:
cannot calculate value. Please issue set fl_licht getConfig first

Ich habe setConfig dann auch ausgeführt, auch soweit mit Erfolg, aber die Fehlermeldung kommt immernoch. Er zeigt mir auch den Register an:
R-intKeyVisib invisib

Gruß,
Alex
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

martinp876

Hi Alex,

muss noch testen, werde es korrigieren. Wenn du es versuchen willst kannst du die Zeile 2046

                if (!$curVal ||$curVal eq "invalid");
ersetzen mit
                if ($curVal eq "invalid");


Gruss
Martin

selfarian

Hallo Martin,

ich habe es in der FHEM/10_CUL_HM.pm ausgetauscht und es kommt leider immernoch die selbe Fehlermeldung.

Gruß,
Alex
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

martinp876

war doch etwas komplexer - update kommt

Gruss
Martin

selfarian

das ging ja flott!
Herzlichen Dank!

Was mir allerdings leider noch nicht ganz einleuchtet: Wie kann ich die Werte verändern?
Intuitiv hätte ich gesagt mit
set <PBU> regSet self02-shOnTime 120
Allerdings mag er das nicht:
self02-shOnTime failed: supported register are intKeyVisib lgActionType lgCtDlyOff lgCtDlyOn lgCtOff lgCtOn lgCtValHi lgCtValLo lgMultiExec lgOffDly lgOffTime lgOffTimeMode lgOnDly lgOnTime lgOnTimeMode lgSwJtDlyOff lgSwJtDlyOn lgSwJtOff lgSwJtOn pairCentral shActionType shCtDlyOff shCtDlyOn shCtOff shCtOn shCtValHi shCtValLo shOffDly shOffTime shOffTimeMode shOnDly shOnTime shOnTimeMode shSwJtDlyOff shSwJtDlyOn shSwJtOff shSwJtOn sign

Oder muss ich das über die Registerbank machen?

Gruß,
Alex
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

martinp876

Hi Alex,

set <PBU> regSet shOnTime 120 self02

siehe
http://fhem.de/commandref.html#CUL_HMregSet

der Peer steht am ende, da er nicht immer genoetigt wird und man ihn ggf weglassen kann.

self02 ist quasi der peer in diesem Fall

Gruss Martin

selfarian

Ahhh ok ;) ... ja, wer lesen kann und so ;)
Geht gleiches dann eigentlich auch für die Taster am PBI-4?
Oder müsste ich dann allgemein am PBU den Wert shOnTime auf 120 setzen?

Gruss, Alex
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

martinp876

Hi Alex,
du hast einen PBU 'aktor' und einen pbi 'sensor'?

Mir ist nicht ganz klar, wo ich dich abholen muss, also:
Wenn der pbu auf den pbi hoeren soll musst du die beiden peeren. Natuerlich immer einen channel. Wenn du willst 1 bis 4 channel des PBI an den channel des PBU.
Nun kannst du jeder Taste eine Aktion zuweisen. Exakt formuliert musst du definieren welche Aktion der PBU ausfuehren soll, wenn der entsprechende Trigger kommt. Trigger hast du
PBI-chan01 short
PBI-chan01 long
PBI-chan02 short
...
PBI-chan04 long

Nach dem Peeren erzeugt der PBU jeweils EINEN Registersatz fuer JEDEN Peer.
Du kannst/musst jeden separat festlegen, beispielsweise
Button 1 short = ontime 120
Button 1 long = toggle dauer-an/dauer-aus
Button 2 short = onTime 500

Neben der ontime musst du auch die Aktion beachten - soll er ueberhaupt nach 'on' springen? Was steht in ActionType?

Gruss Martin



selfarian

Hallo Martin,

sorry, ich hab mich etwas ungünstig ausgedrückt.
Der PBI ist mit dem PBU gepeert.
Ich muss dazu noch gestehen, das ich die Registersätze des PBI gerade übersehen habe, bzw. dachte es wären die des PBU :/

Was bedeutet denn der ActionType?
Bei mir steht da (sowohl die Taster der PBU als auch der PBI) jmpToTarget

Viele Grüße,
Alex
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

martinp876

Hi Alex,

also der PBI hat nur wenig Register. Da kannst du festlegen, ob ein entsprechender Peer burst braucht oder AES nutzt. Sonst nur wenig.

Der Registersatz des PBI besteht aus (schematisch)
- list 0: device register (ID der Zentrale, Internal Keys visible)
- List 1: (einmal je Channel) Kanal Info (evtl leer beim PBU, bei einem Blind sind hier die Rollo-Fahrzeiten untergebracht)
- List3: einmal je Kanal UND peer - also
   Channel1<->peer7
   Channel1<->peer3....

Die Nummer der Liste ist nicht im User-Interface sichtbar, kannst du ueber
get <name> regList
sehen.

Setzen musst du also, wenn gepeert ist:
set <PBU-channel> shOnTime 120 <PBI-Button>
Das ganze steht im PBU.

ActionType legt die eigentliche Aktion fest. Wei du sicher gesehen hast (get regList zeigt alles) kannst du waelen aus
off=>trigger wird ignoriert
jmpToTarget=>nutze anweisungen in der jumptable JT
toggleToCnt=>toggle zwischen on/off. Der Count den der trigger, also der PBI-button liefert wird zum toggeln genutzt. Ungerade = on, gerade=off (oder umgekehrt)
toggleToCntInv=>wie toggleToCnt, aber eben ungekehrt

Je Button (peer-channel) gibt es einen kompletten registersatz fuer long (lg) und short (sh). Du kannst also long oder short ausschalten, oder beides nutzen oder beides ausschalten oder....

JumpToTarget ist das umpfangreiche und eigentlich flexible Element, mit dem man die Statemachine beeinflussen kann (siehe auch das EinsteigerDoc, da habe ich versucht es zu erklaeren)
Der Kanal ist immer ein einem Zustand, der sein kann (je nach Device koennen es mehr sein) on->dlyOff->off->dlyon
Wenn jetzt dein Trigger kommt und actiontype = jumpToTarget ist wird nachgesehen, in welchen Zustand der Kanal gerade ist. Und dann wird in den Zustand verzweigt, der definiert ist. Ist der Kanal in "off", es kommt ein short trigger von Btn1 dann wird im Register
Btn1-shSwJtOff
nachgesehen. Dort koennte "dlyOn" stehen, also geht der Kanal in den Zustand dlyOn.
in dlyOn wird also noch etwas for dem Einschalten gewartet, eben so lange wie in
Btn1-shOnDly
definiert ist. Wenn die Zeit abgelaufen ist (koennte auch '0' sein) geht es automatisch in den default-folgezustand, 'on'. In diesem Zustand bleibt der Kanal nun wieder bis dessen Zeit abgelaufen ist
Btn1-shOnTime
Falls 111600 angegeben ist heist dies 'fuer immer', der Zustand wird also automatisch nicht verlassen.
Falls du eine andere Zeit eingibst geht es nach deren Ablauf in den Folgezustand "dlyOff".
In dlyOff (ausschaltverzoegerung) ist also das Licht noch an und nach der programmierten Zeit
Btn1-shOffDly
geht es ein Haeuschen weiter nach 'off'.
In 'Off' bleibt der Kanal, bis dessen Zeit abgelaufen ist
Btn1-shOffTime
wobei auch hier (nicht wie bei dly...) die 111600 forever bedeutet.

Du kannst also einfach ein Blinklicht bauen.

Wenn jetzt ein neuer gueltiger Trigger fuer diesen Kanal kommt wird der Registersatz des neuen Triggers genommen, also ein 'long' oder ein anderen Button, oder der eingebaute Button 'selfxx' Alle Parameter/Register werden umgeschaltet. eben von
Btn1-sh...
nach
Btn2-lg...

Dimmer und Rolloaktoren haben noch mehr Zustaende.
Long-Press haben ein wichtiges register multi-execution - ob ein Trigger mehrfach ausgefuehrt werden soll (noetig zum dimmen...).

Wie du sehen kannst, kann der gleich trigger den Vorgang noch einmal beeinflussen. Wenn du also in 'dlyOff' bist, dort 120sec warten programmiert hast und noch einmal 'short-press' schickst kommt es darauf an, was in
Btn1-shSwJtDlyOff
steht. Du koenntest dann sofort nach 'off' oder zurueck nach 'on',....

Hoffentlich hat die Verwirrung nicht zugenommen...

Gruss Martin