Projekt: wie funktionieren OTA Updates mit der CCU2?

[betateilchen]

Wie geil ist DAS denn???

Ich habe jetzt folgendes probiert:

• die bidcos-ID meiner CCU2 auf die gleiche Adresse gesetzt wie mein fhem
• drei untereinander gepeerte HM-Komponenten im Wohnzimmer (RT-DN, SEC-RHS und WDS-TH) über "Geräte anlernen" in die WebUI der CCU2 hinzugefügt

Und nun kann ich die Heizungsregelung sowohl über fhem als auch über die CCU2 gleichzeitig (!) vornehmen. Wenn ich in fhem ein set desired-temp ausführe, wird die neue Solltemperatur sofort im WebUI der CCU2 angezeigt. (natürlich funktioniert das auch umgekehrt)

(http://up.picr.de/17220926ry.png)

[jab]

Hi betateilchen,

hast du schon mal mit strace probiert? Mein Vorschlag:

Code Auswählen Erweitern


lsof | grep /dev/ttyAPP0 # spalte 2 ist die pid
strace -s9999 -o bidcos.strace -eread,write,ioctl -p pid_von_oben


Mich würde interessieren ob danach was sinnvolles in der bidcos.strace steht. Einfach bei normalen Operationen (wie Temperatur setzen). Dann wissen wir ob das prinzipiell geht oder nicht. Wenn kein lsof installiert sein sollte müsstest du etwas raten aber vermutlich ist es der rfd.

Wenn es jemand mit HMLan probieren will geht das ganze natürlich etwas anders. Zuerst AES für HMLAN deaktivieren. Dann:

Code Auswählen Erweitern


tcpdump -s 0 -w bidcos.network -ni eth0 host ip_of_your_hmlan

Danach sehen wir alles was an HMLAN gesendet wird auf dem LAN. Zusätzlich kann man auch das strace von laufen lassen. Da sieht man das meiste auch:

Code Auswählen Erweitern


strace -s9999 -o bidcos.strace -eread,write,ioctl,trace=network -p pid



Gruß,
Jan


Gruß,
Jan

[Dirk]

@Betateilchen,

Hast du nicht auch ein TV-Stick und eine SDR-Software rumliegen.
Schau doch mal ob das Übertragen der Firmware auf einem anderen Kanal passiert.
869,3 Mhz bis 870 Mhz währ der Interessante Bereich. Darunter (868 Mhz bis 869,3 Mhz) ist der erlaubte Duty Cycle < 1%, teilweise < 0,1%.

Gruß
Dirk

[betateilchen]

@jab ich hab mal an einem RT die Solltemperatur auf 17° gestellt:

Code Auswählen Erweitern

# cat bidcos.strace
read(5, "\0", 32)                       = 1
read(11, "Bin\0\0\0\0G\0\0\0\10setValue\0\0\0\3\0\0\0\3\0\0\0\fKEQ0578824:4\0\0\0\3\0\0\0\17SET_TEMPERATURE\0\0\0\4\"\0\0\0\0\0\0\5", 4095) = 79
read(11, 0xbef647a8, 4095)              = -1 EAGAIN (Resource temporarily unavailable)
ioctl(7, TCFLSH, 0)                     = 0
write(7, "\375\0\21\1k\2\0\0^\260\21\22p\0!\300\270\206\4\"\352\320", 22) = 22
write(6, "\0", 1)                       = 1
read(5, "\0", 32)                       = 1
read(11, "", 4095)                      = 0
read(5, "\0", 32)                       = 1
read(11, "Bin\0\0\0\0\32\0\0\0\22system.listMethods\0\0\0\0", 4095) = 34
read(11, 0xbef647a8, 4095)              = -1 EAGAIN (Resource temporarily unavailable)
read(11, "", 4095)   


[betateilchen]

Hast du nicht auch ein TV-Stick und eine SDR-Software rumliegen.
...
869,3 Mhz bis 870 Mhz währ der Interessante Bereich. Darunter (868 Mhz bis 869,3 Mhz) ist der erlaubte Duty Cycle < 1%, teilweise < 0,1%

Homematic arbeitet bei einem getConfig in beide Richtungen auf einer Frequenz um die 869.75 MHz

[jab]

@betateilchen:
Nach dem kurzen snippet würde ich vermuten, dass er das hier an das Funkmodul schickt (da man das open nicht sieht und daher nicht weiß welcher Handle was ist):

Code Auswählen Erweitern


\375\0\21\1k\2\0\0^\260\21\22p\0!\300\270\206\4\"\352\320

Daraus werde zumindest ich nicht direkt schlau. Schade. Einen Versuch war es wert.

Laut Signatur hast du doch ein HM-USB-CFG2 + hmland. Hat mal jemand probiert ob hmland mit der CCU2 funktioniert? Das wäre sonst eine Möglichkeit wo man das die Kommunikation auf dem LAN mitlesen könnte. Ansonsten brauchen wir wohl doch einen HMLAN.


Gruß,
Jan

[Dirk]

Homematic arbeitet bei einem getConfig in beide Richtungen auf einer Frequenz um die 869.75 MHz

Während des Firmwareupdates?

die normalen messages scheinen es nicht zu sein. Diese könnten wir ja sonst mit einem "monitor HMLAN" sniffen. Das ist schon versucht worden. Es kam die Message "enter boot loader" dann war Schluss. Die Messages sind also zumindest modifiziert.

Meine Theorie ist, dass der Firmwareupdate auf einer anderen Frequenz läuft, da dieser recht lange dauert und dabei sonst das erlaubte DuttyCycle für die "normale" Frequenz überschritten wird. Das währe nicht zulässig.
Daher die Idee auf einer anderen Frequenz zu lauschen wenn das OTA-Update übertragen wird.

[betateilchen]

Während des Firmwareupdates?

nein, während eines "normalen" getConfig, wie ich bereit oben geschrieben hatte.

Hat mal jemand probiert ob hmland mit der CCU2 funktioniert?

Ja, geht nicht.

(http://up.picr.de/17222563ap.jpg)

• der einzelne rote Punkt ist ein FS20 Schaltbefehl,
• die beiden roten Punkte nebeneinander sind ein Homematic Schaltbefehl

[jab]

Abend,

ich habe mir das ganze mal schnell mit einem Debugger angesehen. Folgendes passiert:
- Packet wird geschickt um das Gerät in den Bootloader zu starten (afaik es startet neu in den Bootloader)
- Die Datenrate wird auf 100k geändert
- Update wird gesendet

Ich gucke es mir später mal genauer an. Dutycycle wird beachtet. Es kann zu wenig da sein.


Gruß,
Jan

[betateilchen]

Im Anhang das strace eines Firmwareupdates.

Und ich würde sagen, da wird nicht nur die Frequenz geändert, sondern auch das Modulationsverfahren. Muss aber erstmal die Screenshots sortieren.

[betateilchen]

(http://up.picr.de/17225476tm.png)

(http://up.picr.de/17225479wf.jpg)

(http://up.picr.de/17225481ak.jpg)

[jab]

Abend,

also wenn ich das richtig lesen kann dann wird der Dutycycle geändert und die Datenrate. Sieht mir allerdings so aus als wenn da trotzdem "normale" BidCos Meldungen gesendet werden. Ich gucke es mir aber noch etwas näher an.


Gruß,
Jan

[Dirk]

... dann wird der Dutycycle geändert

Den Dutycycle kann man nicht ändern, denn dieser ist im verwendeten Frequenzbereich festgelegt.
Von 868,0 Mhz bis 868,6 Mhz sind nur < 1% Sendezeit erlaubt.
Man muss auf eine andere Frequenz ausweichen wenn man länger senden möchte.
In diesem Fall > 869,3 Mhz. Die Bilder von Betateilchen könnten diese Theorie auch bestätigen.

[jab]

Ok ich habe es für euch mal genauer analysiert. Dutycycle wird nicht geändert sondern nur gecheckt. Codefluss ist so (ohne Fehlerbehandlung):

1. BidcosInterfaceConcentrator::DutyCycleForUpdate(int,UpdateFile &)
-> checkt ob möglicherweise nicht genug duty frei ist
2. BidcosFrameStartBootloader::BidcosFrameStartBootloader(void)
- StructuredFrame::setType(0xCA0911) (ka warum da so viel hinter steht)
- BidcosFrame::setCtrl(0x80)
- BidcosFrame::setReceiverAddress(0x70)
- RFManager::getBidcosAddress -> BidcosFrame::setSenderAddress
- BidcosInterfaceConcentrator::sendFrame
3. Warten auf response (uninteressant)
4. RFDevice::set100kDataRate
5. In loop: BidcosInterfaceConcentrator::SendUpdataFrame(std::string  const&,int)
- Auth wird resettet. Also keine AES o.ä.
- Message Type ist 0xCA wenn ich das richtig interpretiere
- jeweils 0xC bytes der firmware pro message
6. BidcosInterfaceConcentrator::SetInterfaceTo10kMode(int)

EDIT: So ganz verstehe ich noch nicht wie das mit dem Umschalten funktioniert. Folgende Funktionen habe ich gefunden.
set100kDataRate:
Type: 0xCB
Ctrl: 0x0
Empfänger: 0x70
Message: (0x16 / 22 Zeichen)
0x10 0x5B 0x11 0xF8 0x15 0x47 0xB 0x8 0x1A 0x1C 0x19 0x1D 0x1B 0xC7 0x1C 0x0 0x1D 0xB2 0x21 0xB6 0x23 0xEA 0x0

HM2::CCU2CommController::setDataRate100k
payload: 0xE9 0xCA


Gruß,
Jan

[mgernoth]

EDIT: So ganz verstehe ich noch nicht wie das mit dem Umschalten funktioniert. Folgende Funktionen habe ich gefunden.
set100kDataRate:
Type: 0xCB
Ctrl: 0x0
Empfänger: 0x70
Message: (0x16 / 22 Zeichen)
0x10 0x5B 0x11 0xF8 0x15 0x47 0xB 0x8 0x1A 0x1C 0x19 0x1D 0x1B 0xC7 0x1C 0x0 0x1D 0xB2 0x21 0xB6 0x23 0xEA 0x0

Hey, das ist die CC1101-Konfiguration. Damit kann man dem CUL beibringen, mitzulauschen.

0x10 -> 0x5B (Exponent der Datenrate in den untersten 4 Bit -> 11)
0x11 -> 0xF8 (Mantisse der Datenrate -> 248)

Laut cc1101.pdf, Seite 35:

R_data = (((256+248)*2^11)/(2^28))*26000000
R_data = 99975.5848



Daneben werden noch eine Menge anderer Register angefasst (0x1A, 0x1C, 0x1D, 0x21, 0x23) die bisher bei BidCos im Default-Zustand waren und andere überschrieben (0x0B, 0x10, 0x11, 0x15, 0x19, 0x1B). Erklärungen dazu im cc1101.pdf, ab Seite 71.

Ich versuche da heute Abend mal was in die culfw reinzufrickeln, um den Empfang zu ermöglichen.

Gruß
  Michael