AskSin HB-UNI-Sensor-1 - Frage zum Peering
Moderator: Co-Administratoren
-
- Beiträge: 7
- Registriert: 08.04.2021, 13:33
- System: keine Zentrale (nur Pairing, FHEM etc.)
- Hat sich bedankt: 3 Mal
AskSin HB-UNI-Sensor-1 - Frage zum Peering
Moin,
auf der Suche nach einer Alternative für nicht mehr lieferbare EM-8 bin ich über AskSin "gestolpert". Echt coole Sache
Vielen Dank an alle, die daran mitgewirkt haben bzw. immer noch mitwirken !
Ich habe inzwischen einige Sensoren/Aktoren in Betrieb und bin begeistert.
Einen HB-UNI-Sensor-1 mit BH1750 (brightness) und DIGINPUT läuft bei mir im Test und funktoniert. Damit möchte ich diverse Switche und Jalousieaktoren per Peering direckt ansteuern - zum Beispiel Ein- und Ausschalten der Fußwegbeleuchtung etc.
Die Definition des Peerings mit einem Testswitch HM-LC-SW1-BA-PCB läuft formal durch, allerdings passiert dann anschließend nix mehr. Irgendwelche Trigger bzw. Reaktionen kann ich nicht erkennen.
Frage: Der HB-UNI-Sensor-1 hat ja einen WeatherChannel - kann der überhaupt mit einem Switch / Blindaktuator gepeered werden und wenn ja, welche Werte werden dann aus der Fülle der Readings vom HB-UNI-Sensor-1 überhaupt verwendet ?
Ich würd ja gern etwas über AskSin etc lernen - wo im Sktech oder in der Lib finde ich denn eigentlich die Definition / Kommunikation des peerings ?
Schon mal vielen Dank vorab
Bernd
auf der Suche nach einer Alternative für nicht mehr lieferbare EM-8 bin ich über AskSin "gestolpert". Echt coole Sache
Vielen Dank an alle, die daran mitgewirkt haben bzw. immer noch mitwirken !
Ich habe inzwischen einige Sensoren/Aktoren in Betrieb und bin begeistert.
Einen HB-UNI-Sensor-1 mit BH1750 (brightness) und DIGINPUT läuft bei mir im Test und funktoniert. Damit möchte ich diverse Switche und Jalousieaktoren per Peering direckt ansteuern - zum Beispiel Ein- und Ausschalten der Fußwegbeleuchtung etc.
Die Definition des Peerings mit einem Testswitch HM-LC-SW1-BA-PCB läuft formal durch, allerdings passiert dann anschließend nix mehr. Irgendwelche Trigger bzw. Reaktionen kann ich nicht erkennen.
Frage: Der HB-UNI-Sensor-1 hat ja einen WeatherChannel - kann der überhaupt mit einem Switch / Blindaktuator gepeered werden und wenn ja, welche Werte werden dann aus der Fülle der Readings vom HB-UNI-Sensor-1 überhaupt verwendet ?
Ich würd ja gern etwas über AskSin etc lernen - wo im Sktech oder in der Lib finde ich denn eigentlich die Definition / Kommunikation des peerings ?
Schon mal vielen Dank vorab
Bernd
-
- Beiträge: 1793
- Registriert: 30.08.2017, 23:25
- Hat sich bedankt: 175 Mal
- Danksagung erhalten: 399 Mal
- Kontaktdaten:
Re: AskSin HB-UNI-Sensor-1 - Frage zum Peering
Hi Bernd,
den DIGINPUT habe ich hilfsweise in die Wetterdaten eingebunden weil ich für bestimmte Anwendungen beim Sensor einfach den Status eines digitalen Inputs zusätzlich brauchte.
Ich würde vermuten der ist nicht direkt peerfähig, intern hat er bei mir den HM Datentyp "VALVE_STATE" bekommen.
https://github.com/TomMajor/SmartHome/t ... enden-kann
ich weiß nicht ob es irgendwo eine öffentliche Liste gibt wo hervorgeht welche Sensoren/Aktoren/Channels/Datenpunkte nach welchen Kriterien genau peerfähig sind.
Das einfachste aus meiner Sicht wäre deine gewünschten Aktionen per Skript erledigen wenn sich DIGINPUT ändert, so würde ich es machen.
den DIGINPUT habe ich hilfsweise in die Wetterdaten eingebunden weil ich für bestimmte Anwendungen beim Sensor einfach den Status eines digitalen Inputs zusätzlich brauchte.
Ich würde vermuten der ist nicht direkt peerfähig, intern hat er bei mir den HM Datentyp "VALVE_STATE" bekommen.
https://github.com/TomMajor/SmartHome/t ... enden-kann
ich weiß nicht ob es irgendwo eine öffentliche Liste gibt wo hervorgeht welche Sensoren/Aktoren/Channels/Datenpunkte nach welchen Kriterien genau peerfähig sind.
Das einfachste aus meiner Sicht wäre deine gewünschten Aktionen per Skript erledigen wenn sich DIGINPUT ändert, so würde ich es machen.
Viele Grüße,
Tom
Tom
-
- Beiträge: 7
- Registriert: 08.04.2021, 13:33
- System: keine Zentrale (nur Pairing, FHEM etc.)
- Hat sich bedankt: 3 Mal
Re: AskSin HB-UNI-Sensor-1 - Frage zum Peering
Hi Tom,
danke für Deine schnelle Rückmeldung !
Den DIGINPUT habe ich nur als Test drin, um die Funktion zu sehen.
-> brightness von einem HM-SEN-MDIR-O-2 triggert ein notify (ich arbeite mit FHEM) und damit werden die Switche geschaltet. Ich will aber auf Peering umstellen, um von der Zentrale und diversen anderen Faktoren unabhängig zu sein und somit die Betriebssicherheit zu erhöhen. Mein Ziel: der HB-UNI-Sensor-1 wäre so eine Art Bake, der alle 60 Sekunden die Helligkeit per peering an die zu schaltenden Devices sendet. Die Devices agieren dann eigenständig entsprechend ihrer Registerprogrammierung.
Könnte man einen zusätzlichen Schaltkanal in den Sketch einbauen, der z.B von brightness getriggert wird ?
Es ist zu blöd, AskSin finde ich super interessant und innovativ und ich finde keinen Anfang, um es zu verstehen.... mäh
Aber es wird mir wohl noch gelingen (hoffentlich)
Bernd
danke für Deine schnelle Rückmeldung !
Den DIGINPUT habe ich nur als Test drin, um die Funktion zu sehen.
...das ist meine bisherige Konstellation:Das einfachste aus meiner Sicht wäre deine gewünschten Aktionen per Skript erledigen
-> brightness von einem HM-SEN-MDIR-O-2 triggert ein notify (ich arbeite mit FHEM) und damit werden die Switche geschaltet. Ich will aber auf Peering umstellen, um von der Zentrale und diversen anderen Faktoren unabhängig zu sein und somit die Betriebssicherheit zu erhöhen. Mein Ziel: der HB-UNI-Sensor-1 wäre so eine Art Bake, der alle 60 Sekunden die Helligkeit per peering an die zu schaltenden Devices sendet. Die Devices agieren dann eigenständig entsprechend ihrer Registerprogrammierung.
Könnte man einen zusätzlichen Schaltkanal in den Sketch einbauen, der z.B von brightness getriggert wird ?
Es ist zu blöd, AskSin finde ich super interessant und innovativ und ich finde keinen Anfang, um es zu verstehen.... mäh
Aber es wird mir wohl noch gelingen (hoffentlich)
Bernd
-
- Beiträge: 1793
- Registriert: 30.08.2017, 23:25
- Hat sich bedankt: 175 Mal
- Danksagung erhalten: 399 Mal
- Kontaktdaten:
Re: AskSin HB-UNI-Sensor-1 - Frage zum Peering
Diese Art Frage kam hier schon öfter für diverse Geräte. Die Basis-Antwort von Jerome und mir ist meistens, ja, könnte man wohl, aber der Aufwand dafür ist wesentlich größer als ein zweites Gerät als Aktor aufzubauen. Es ist ja nicht nur der Sketch, auch das xml muss geändert werden - und da fängt der Spaß an.
Viele Grüße,
Tom
Tom
-
- Beiträge: 7
- Registriert: 08.04.2021, 13:33
- System: keine Zentrale (nur Pairing, FHEM etc.)
- Hat sich bedankt: 3 Mal
Re: AskSin HB-UNI-Sensor-1 - Frage zum Peering
Moin Tom,
danke für Deine Info.
... denn muss ich mir wohl etwas anderes überlegen. Schade
Viele Grüße und moin
Bernd
danke für Deine Info.
... denn muss ich mir wohl etwas anderes überlegen. Schade
Viele Grüße und moin
Bernd
-
- Beiträge: 1793
- Registriert: 30.08.2017, 23:25
- Hat sich bedankt: 175 Mal
- Danksagung erhalten: 399 Mal
- Kontaktdaten:
Re: AskSin HB-UNI-Sensor-1 - Frage zum Peering
Jerome hat als Kombigerät einen 4fach-Aktor und 4fach-Sender (Taster) im Angebot.
Evtl. hilft dir das weiter, das wäre ein Kombi Beispiel für beide Richtungen.
https://github.com/jp112sdl/HB-UNI-SenAct-4-4
Evtl. hilft dir das weiter, das wäre ein Kombi Beispiel für beide Richtungen.
https://github.com/jp112sdl/HB-UNI-SenAct-4-4
Viele Grüße,
Tom
Tom
-
- Beiträge: 7
- Registriert: 08.04.2021, 13:33
- System: keine Zentrale (nur Pairing, FHEM etc.)
- Hat sich bedankt: 3 Mal
Re: AskSin HB-UNI-Sensor-1 - Frage zum Peering
Moin,
den Sketch habe ich mir angesehen. Diese Mixdevices scheinen wirklich sehr interessant für spezielle Devices zu sein.
Allerdings fehlt mir jede Idee, wie man da einen Sensor, z.B. den BH1750 einbinden kann. Ein RemoteChannel müsste statt open/close den Werteberich 0 - 255 als brightness übertragen. Ich habe schon Einiges versucht, scheitere aber immer wieder in den "Tiefen der AskSin-Lib".
Bernd
den Sketch habe ich mir angesehen. Diese Mixdevices scheinen wirklich sehr interessant für spezielle Devices zu sein.
Allerdings fehlt mir jede Idee, wie man da einen Sensor, z.B. den BH1750 einbinden kann. Ein RemoteChannel müsste statt open/close den Werteberich 0 - 255 als brightness übertragen. Ich habe schon Einiges versucht, scheitere aber immer wieder in den "Tiefen der AskSin-Lib".
Bernd
-
- Beiträge: 12116
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 849 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: AskSin HB-UNI-Sensor-1 - Frage zum Peering
Schau dir mal die Motion.h:34-41 an.
Der Bewegungsmelder macht doch genau das, was du brauchst?
In der CCU kann man beim Peering zumindest die Helligkeit als Schwelle für die Einschaltbedingung mitgeben. Der Wert wird als SHORT_COND_VALUE_LO gesetzt.
-
- Beiträge: 7
- Registriert: 08.04.2021, 13:33
- System: keine Zentrale (nur Pairing, FHEM etc.)
- Hat sich bedankt: 3 Mal
Re: AskSin HB-UNI-Sensor-1 - Frage zum Peering
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:
und ein Auzug aus der HMConfig_myown.pm:
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:
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
aber in der Device.h Line 563 und 564 wird dann das BURST wieder abgeschaltet
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
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
}
};
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;
};
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
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);
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();
}
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
-
- Beiträge: 12116
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 849 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: AskSin HB-UNI-Sensor-1 - Frage zum Peering
TLDR;
Das hast du nun rausgenommen, so dass du die Methode zu einer verstümmelten Art sendPeerEvent umgebaut hast
Sollte dann vielleicht sendPeerEvent sein
Nein. Es gibt kein "broadcastEvent" mit Burst, daher muss das raus falls es versehentlich mit gesetzt wurden und es muss das BCAST flag gesetzt werden.
Das hast du nun rausgenommen, so dass du die Methode zu einer verstümmelten Art sendPeerEvent umgebaut hast
Dann ist das Problem in deinem Sketch zu suchen.
Sollte dann vielleicht sendPeerEvent sein