Moin,
soo, das hat etwas länger gedauert, ich habe viel gelesen, analysiert, getestet und war virtuell auf einigen Homematic-Usertreffen ...
Danke für den Tipp mit der Motion.h ! Ich habe dort mit meinen Bemühungen angefangen, bin dann schnell auf die HmConfig.pm gekommen (ich setze FHEM ein), habe den originalen Traffic eines HM-SEN-MDIR-O-2 per Sniffer mitgeschnitten und damit dann den Sketch angepasst.
Ein Auszug als Zwischenstand, muss noch "hübsch" gemacht werden, mit vielen Kommentaren, z.T. gesammelt aus dem Netz:
Code: Alles auswählen
class WeatherEventMsg : public Message {
public:
void init(uint8_t msgcnt, uint32_t brightness,
uint16_t batteryVoltage, bool batLow)
{
uint8_t t1 = 0x01;
uint8_t t2 = msgcnt;
//if (batLow == true) {
// t1 |= 0x80; // set bat low bit
//}
// als Standard wird BCAST gesendet um Energie zu sparen, siehe Beschreibung unten.
// Bei jeder 20. Nachricht senden wir stattdessen BIDI|WKMEUP, um eventuell anstehende Konfigurationsänderungen auch
// ohne Betätigung des Anlerntaster übernehmen zu können (mit Verzögerung, worst-case 20x Sendeintervall).
uint8_t flags = 0;
flags = AS_WAKEUP | AS_WAKE_ME_UP | AS_BROADCAST | AS_BURST | AS_MESSAGE_TO_MASTER;
//Byte 2: communication bit field -> see defines.h
//=> 0x97 WakeUp | WakeMeUp | BROADCAST | BURST | MESSAGE_TO_MASTER
//Error 0x87 wird gesendet !! BURST fehlt
//siehe modification in Device.h
#if verbose > 4
DPRINT(" flags = ");DPRINTLN(flags);
#endif
Message::init(13, msgcnt, AS_MESSAGE_SENSOR_EVENT, flags, t1, t2);
//Doc Message::init(length, msgcnt, message types, communication bit field, t1, t2); => see Defines.h
// Message Length (first byte param.): 11 + payload
// 1 Byte payload -> length 12
// 12 Byte payload -> length 23
// max. payload: 17 Bytes (https://www.youtube.com/watch?v=uAyzimU60jw)
// BIDI|WKMEUP: erwartet ACK vom Empfänger, ohne ACK wird das Senden wiederholt
// LazyConfig funktioniert, d.h. eine anstehende Conf.Änderung von der CCU wird nach dem nächsten Senden übernommen. Aber erhöhter
// Funkverkehr wegen ACK
//
// BCAST: ohne ACK zu Erwarten, Standard für HM Sensoren.
// LazyConfig funktioniert nicht, d.h. eine anstehende Conf.Änderung von der CCU muss durch den Config Button am Sensor übernommen
// werden!!
// papa:
// BIDI - fordert den Empfänger auf ein Ack zu schicken. Das wird auch zwingend für AES-Handling gebraucht. BCAST - signalisiert
// eine Broadcast-Message. Das wird z.B. verwendet, wenn mehrere Peers vor einen Sensor existieren. Es wird dann an einen Peer
// gesndet und zusätzlich das BCAST-Flag gesetzt. So dass sich alle die Nachrricht ansehen. Ein Ack macht dann natürlich keinen Sinn
// - es ist ja nicht klar, wer das senden soll.
//
// WKMEUP - wird für LazyConfig verwendet. Ist es in einer Message gesetzt, so weiss
// die Zentrale, dass das Geräte noch kurz auf weitere Nachrichten wartet. Die Lib setzt diese Flag für die StatusInfo-Message
// automatisch. Außerdem bleibt nach einer Kommunikation der Empfang grundsätzlich für 500ms angeschalten.
/*Doc aus HMConfig.pm
#my %culHmDevProps=(
# "01" => { st => "AlarmControl",
# "10" => { st => "switch",
# "12" => { st => "outputUnit",
# "20" => { st => "dimmer",
# "30" => { st => "blindActuator",
# "39" => { st => "ClimateControl",
# "40" => { st => "remote",
# "41" => { st => "sensor",
# "42" => { st => "swi",
# "43" => { st => "pushButton",
# "44" => { st => "singleButton",
# "51" => { st => "powerMeter",
# "58" => { st => "thermostat",
# "60" => { st => "KFM100",
# "70" => { st => "THSensor",
# "80" => { st => "threeStateSensor"
# "81" => { st => "motionDetector",
# "C0" => { st => "keyMatic",
# "C1" => { st => "winMatic",
# "C3" => { st => "tipTronic",
# "CD" => { st => "smokeDetector",
#);
*/
/* Doc Sniffer von HM-SEN-MDIR-O-2 auf Raspi-01 :
m:D9 A4 41 2EF1D9 495E15 01 1D 75 40 Motion
D9 lfd-Nr
A4 Steuerungsbits
Bit 0 WakeUp
Bit 1 WakeMeUp
Bit 2 Broadcast
Bit 3 Reserved from EQ-3
Bit 4 Burst
Bit 5 ACK requested
Bit 6 Repeated Message
Bit 7 Repeat Enable
41 Rahmentyp see Defines.h and %culHmDevProps
2EF1D9 ID Sender
495E15 ID Empfänger (000000 for broadcast)
01 Konstante (Liste ?)
1D trigger_cnt
75 brightness
40 Motion ? unknown
*/
#if verbose > 4
DPRINT ("raw brightness "); DPRINTLN (brightness);
#endif
brightness /=100;
if (brightness > 255) { //truncate brightness to max 255
brightness = 255;
};
#if verbose > 4
DPRINT ("calculated brightness "); DPRINTLN (brightness);
#endif
pload[0] = brightness; //brightness range 0-255
pload[1] = 0x40; //for compatibility with HM-SEN-MDIR-O-2
}
};
und ein Auzug aus der HMConfig_myown.pm:
Code: Alles auswählen
# parse the incomming messages
# device definition
$HMConfig::culHmModel{'F3E3'} = {name => 'HB-Beacon-B01', st => 'custom', cyc => '00:10', rxt => '', lst => 'p', chn => 'Sen:1:1'};
# definitions for register settings
# examples see HMConfig.pm line 350ff
# 'ledMode', a=> 5.6, s=>0.2, .. is already configured in HMConfig.pm
# see also franks explanations: https://forum.fhem.de/index.php/topic,20620.msg1148330.html#msg1148330
$HMConfig::culHmRegDefine{'lowBatLimitUS1'} = {a=>18.0,s=>1.0,l=>0,min=>1.0 ,max=>5 ,p=>'n',c=>'' ,f=>10,u=>'V' ,d=>0,t=>'Low batterie limit, step 0.1 V'};
$HMConfig::culHmRegModel{"HB-Beacon-B01"} = { sendInterval =>1,
lowBatLimitUS =>1,
transmDevTryMax =>1
};
$HMConfig::culHmChanSets{"HB-Beacon-B0101"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmRegChan {"HB-Beacon-B0101"} = { peerNeedsBurst =>1,
expectAES =>1
};
$customMsg{"HB-Beacon-B01"} = sub {
my ($msg,$target) = @_;
my @evtEt=();
my $lux;
$lux = $msg->payloadByte(2); # kommt von pload(0)
if( defined($channel) ) {
push @evtEt,[$channel,1,"brightness:".$lux];
push @evtEt,[$channel,1,"state:B: ".($lux)];
} else {
}
return @evtEt;
};
Da es nun kein UNI-Sensor mehr ist, hat das Teil den Namen HB-Beacon-B01 bekommen. Außerdem habe ich einen Sensorkanal ( HM_A5A601_Sen) definiert, um eindeutig von den Device-Definitionen zu trennen.
Ok, im Ergebnis sende ich jetzt zum HM-SEN-MDIR-O-2 kompatible Messages als Broadcast ohne Anforderung von ACK alle 5 Minuten. Die Anzahl der Aktoren, die darauf reagieren sollen, ist beliebig. Also ein minimaler Aufwand "on the Air" ohne Mitwirkung einer Zentralinstanz.
Die Aktoren, die auf diese Messages reagieren sollen, werden mit der HB-Beacon-B01 gepeert, aber nur "einseitig" - also ohne Peer in der HB-Beacon-B01.
Sorry, wieder FHEM als Sample:
Code: Alles auswählen
set HM_A5A601_Sen peerChan 0 <actor_device_name> single set actor
Die jeweils individuellen Aktivitäten werden mit den Registern im Aktor definiert.
Das klappt soweit sehr gut ! Es gibt allerdings Probleme bei batteriegetriebenen Aktoren, die einen BURST brauchen. Diese Teile reagieren nicht auf die Broadcast-Message.
Soweit ich das als Anfänger beurteilen kann (in aller Vorsicht), gibt es vielleicht ein Design-Problem in der AskSin-Lib ?
Bei Aufruf der Initialisierung der Message gibt man ja die gewünschten Parameter mit
Code: Alles auswählen
flags = AS_WAKEUP | AS_WAKE_ME_UP | AS_BROADCAST | AS_BURST | AS_MESSAGE_TO_MASTER;
Message::init(13, msgcnt, AS_MESSAGE_SENSOR_EVENT, flags, t1, t2);
aber in der Device.h Line 563 und 564 wird dann das BURST wieder abgeschaltet
Code: Alles auswählen
void broadcastEvent (Message& msg) {
msg.clearAck();
//msg.burstRequired(false); //bmw => Battery-Devices werden nicht getriggert !
//msg.setBroadcast(); //bmw
send(msg,HMID::broadcast);
hal->sendPeer();
}
Ich habe die beiden Zeilen mal auskommentiert und schon lassen sich auch die Batterie-Aktoren triggern. Broadcast bedeutet doch eine Message an alle und nicht an fast alle und für eine saubere Struktur sollte das allein bei Aufruf der Initroutine definiert werden.
Kann sein, dass ich das völlig falsch sehe, aber könnt Ihr das bitte mal checken ??
Ich bin mal gespannt, wie sich diese Konstellation in einem längeren Test verhält.
Moin
Bernd
