[gelöst]Kein Pairing bei Raspberrymatic und AskSin++

[MichaelAnders]

Moin zusammen,

Ich kämpfe mit dem Anlernen meines Arduino/CC1101 an Raspberrymatic.

Hier ein paar Infos:
1) Der Code basiert auf HB-UNI-Sen-Temp-DS18B20. Eigenes Coding und Onewire/DS18b20 Zeugs ist auskommentiert weil ich das nicht brauche, der Rest ist eigentlich gleich (siehe Anhang)
2) Ich nutze das HM-MOD-RPI-PCB auf Rpi 2B
3) Auf Raspberrymatic ist JP HB 2.12 installiert
4) Der AES Key wurde vom Raspberrymatic ausgelesen und entsprechend eingetragen in AskSinPP.h (keine Ahnung ob das zwingend ist, denke eher nicht, macht auch keinen Unterschied?)
5) Die Frequenz wurde im Script angepaßt (das Program SDR# zeigt mir nun visuell, daß die Frequenz ziemlich genau 838,3 MHz ist, lag vorher um 0.0625 MHz daneben). Ich habe ebenfalls einen zweiten Android/CC1101 getestet (etwas andere Frequenzabweichung).
6) Vor der Anpassung der Frequenz konnte ich unter Homegear im Loglevel 5 sehen, daß Pakete zwar gesendet wurden com CC1101 aber Pakete vom Arduino nicht empfangen/verarbeitet wurden. Nach der Nutzung von Raspberrymatic kann ich leider Homegear nicht mehr nutzen da die Firmware geupdated wurde (mit HmIP Support was Homegear nicht mag) - und ich leider nicht weiß wie ich downgraden kann um dort nochmal zu gucken was da gelogged wird.
7) Sender und Empfänger sind knapp 1 Meter auseinander
Ich sehe im Arduino Serial Monitor, daß Temperaturen verarbeitet werden und ich sehe diese Pakete auch in SDR#

Wenn ich nun in Raspberrymatic versuche das Device anzulernen tut sich nichts. Ich sehe die Pakete in SDR# - ein einmaliges senden von Paketen nach der Initiierung vom Pairing, aber mehr ist nicht zu sehen. Erst nach ein paar Sekunden werden dann wieder die Temperaturen gesendet.

Loglevel oder sowas habe ich gesucht aber nicht gefunden bei Raspberrymatic (vermutlich weil Closed Source und da wäre Debugtext "hinderlich"?) - macht die Fehlersuche nicht viel einfacher.

Hat jemand Ideen?

Danke im voraus!

[jp112sdl]

Hi,

AES würde ich erstmal komplett außen vor lassen.
Geht m.W. auch gar nicht bei Wettersensoren. Zumindest lässt es sich bei den HM Sensoren nicht aktivieren.
Also USE_AES erst mal aus.

Loglevel oder sowas habe ich gesucht aber nicht gefunden bei Raspberrymatic

Einstellungen->Systemsteuerung->Zentralenwartung unten bei Fehlerprotokoll "homematic Funk" auf "Alles loggen" setzen.
Dann kannst du z.B. per SSH mit tail -f /var/log/messages "live" sehen, was an Paketen reinkommt.

[TomMajor]

) Die Frequenz wurde im Script angepaßt (das Program SDR# zeigt mir nun visuell, daß die Frequenz ziemlich genau 838,3 MHz ist, lag vorher um 0.0625 MHz daneben). Ich habe ebenfalls einen zweiten Android/CC1101 getestet (etwas andere Frequenzabweichung).

gemeint ist sicherlich 868,3 MHz ?

Ich würde nicht die Freq mit SDR messen und in den sketch eintragen sondern papas Frequenztest benutzen, 1) legt der das an der richtigen Stelle im EEPROM ab und 2) siehst du dann schon im Frequenztest Betrieb ob generell eine Kommunikation mit der Zentrale geht.

[MichaelAnders]

Danke! Ist gelöst... ich schreib noch was dazu.

Einstellungen->Systemsteuerung->Zentralenwartung unten bei Fehlerprotokoll "homematic Funk" auf "Alles loggen" setzen.
Dann kannst du z.B. per SSH mit tail -f /var/log/messages "live" sehen, was an Paketen reinkommt.

Ich habe AES ausgemacht und den Log Level erhöht, das hat geholfen zu sehen das gar nichts ankam beim raspberrymatic (das aber geht da ja die Thermostaten gingen).

Ich würde nicht die Freq mit SDR messen und in den sketch eintragen sondern papas Frequenztest benutzen,
1) legt der das an der richtigen Stelle im EEPROM ab und
2) siehst du dann schon im Frequenztest Betrieb ob generell eine Kommunikation mit der Zentrale geht.

Freqtest tut bei mir leider auf keinem der beiden Arduino's irgendwas. Immer 0/0, und ja, ich änderte die Temperaturen an den Thermostaten fortlaufend über das Webui. Daher wollte ich jetzt mal "aktiv" loggen mit PING_FROM und PING_TO, nach der offiziellen Anleitung https://asksinpp.de/Grundlagen/FAQ/Fehl ... C1101.html.
1) Leider finde ich die "BidCos-RF.dev" Datei nicht? Auch ein passender "grep" in /etc/config liefert mir nur die Einträge unter "/etc/config/rfd/"?

2) Tut vielleicht nichts zur Sache aber der Code ist "komisch" (in meinen Augen). Ein Kommentieren von "HMID PING_FROM" in freqtest.ino verhindert das kompilieren (msg.to(PING_TO); msg.from(PING_FROM); ). Finde ich etwas seltsam da diese ja angeblich nur bei ACTIVE_PING relevant sind? Das sieht dann so aus als wären die Adressen doch irgendwie relevant, was ja aber eigentlich nicht sein kann denn die Adressen können ja nie zu denen beim Benutzer passen?

Gelöst habe ich das ganze nun doch per SDR# (da ja Freqtest bei mir nicht geholfen hatte):
1) Ich habe die Rolläden bzw. Temperaturen über das WebUI geändert und SDR# beobachtet.
2) Gesehen hab ich die Änderung in SDR# auf 867,83 MHz (!) - ziemlich weit weg von 868,3 MHz, aber egal.
3) Dann habe ich die Frequenz im Sketch so verändert daß es fast punktgenau auf dem Sendet wie Raspberrymatic.

Und siehe da - das Gerät wurde gefunden

Dankeschön! Nach Tagen des verrücktwerdens geht es nun endlich und ich kann an meinem Sketch weiterarbeiten

[jp112sdl]

Hmm, bei dir ist irgendwie alles anders als bei allen anderen

1) Leider finde ich die "BidCos-RF.dev" Datei nicht? Auch ein passender "grep" in /etc/config liefert mir nur die Einträge unter "/etc/config/rfd/"?

Also die "BidCos-RF.dev" muss existieren.
Das ist quasi das Gerät "HM-RCV-50" in der WebUI.
Und ja, die Datei liegt in "/etc/config/rfd/". Wie kamst du auf "/etc/config"?

2) Tut vielleicht nichts zur Sache aber der Code ist "komisch" (in meinen Augen). Ein Kommentieren von "HMID PING_FROM" in freqtest.ino verhindert das kompilieren (msg.to(PING_TO); msg.from(PING_FROM); ). Finde ich etwas seltsam da diese ja angeblich nur bei ACTIVE_PING relevant sind? Das sieht dann so aus als wären die Adressen doch irgendwie relevant, was ja aber eigentlich nicht sein kann denn die Adressen können ja nie zu denen beim Benutzer passen?

Ja ist irrelevant.
Ist nur etwas "unschön", aber die Message wird eh nur gesendet, wenn ACTIVE_PING definiert ist:

Code: Alles auswählen

#ifdef ACTIVE_PING
    sdev.radio().write(msg,msg.burstRequired());
#endif

Schöner wäre es wohl, wenn man das #ifdef ACTIVE_PING ganz nach oben packt:

Code: Alles auswählen

#ifdef ACTIVE_PING
    InfoActuatorStatusMsg msg;
    msg.init(cnt++, ch, hal.radio.rssi());
    msg.to(PING_TO);
    msg.from(PING_FROM);
    msg.ackRequired();
    msg.setRpten();
    sdev.radio().write(msg,msg.burstRequired());
#endif

2) Gesehen hab ich die Änderung in SDR# auf 867,83 MHz (!) - ziemlich weit weg von 868,3 MHz, aber egal.

Ein halbes MHz Offset? Oh ha... Liegts vielleicht an der Software oder doch am China-SDR? Hmm

[MichaelAnders]

Hmm, bei dir ist irgendwie alles anders als bei allen anderen

Das ist nichts neues

Also die "BidCos-RF.dev" muss existieren.
Das ist quasi das Gerät "HM-RCV-50" in der WebUI.
Und ja, die Datei liegt in "/etc/config/rfd/". Wie kamst du auf "/etc/config"?

"/etc/config" weil ich ein

Code: Alles auswählen

grep "^<device serial" * -r

auf oberster Ebene absetzen wollte.

Und nein, es gibt keine "BidCos-RF.dev" Datei bei mir, sorry (daher ja mein Versuch mit o.g. grep). Ich hab das aktuelle Image eingespielt - vielleicht ist da was anders und das fällt beim Update nicht auf? Keine Ahnung. Bei mir sehe ich nur das hier:

Code: Alles auswählen

ls
MEQ0****8.dev  MEQ07****6.dev  MEQ07****8.dev  UNITEMP001.dev

Schöner wäre es wohl, wenn man das #ifdef ACTIVE_PING ganz nach oben packt:

Schöner und verständlicher, ja. Dann könnte man auch gleich noch das PING_TO / PING_FROM in ein #ifdef packen (ist ja ggf. überflüssig und beim Arduino spare ich gerne wo immer es geht)

2) Gesehen hab ich die Änderung in SDR# auf 867,83 MHz (!) - ziemlich weit weg von 868,3 MHz, aber egal.

Ein halbes MHz Offset? Oh ha... Liegts vielleicht an der Software oder doch am China-SDR? Hmm

Hab jetzt 0x216555 == 868.2915 MHz im Sketch drin (ohne diesen festen Eintrag hat es nie geklappt mit dem Pairing, hatte ich ja schon auf anderem Weg geschrieben gehabt). Mir war das Ziel wichtig und nicht der Weg, denn Hauptsache es tut endlich

[TomMajor]

Wenn 0x216555 die richtige Frequenz ist hätte aber imho der FreqTest sketch das finden müssen. Liegt dann eventuell daran das die Adresse der Zentrale nicht herausgefunden wurde.

@Jerome

Also die "BidCos-RF.dev" muss existieren.
Das ist quasi das Gerät "HM-RCV-50" in der WebUI.

Ich habe übrigens ein backup von Dez. 2018 da ist auch keine BidCos-RF.dev Datei drin, nicht in /rfd.
Aber die ids Datei ist da.
Ich hatte damals das "kleine" Funkmodul, mittlerweile das große.

[jp112sdl]

Ich habe übrigens ein backup von Dez. 2018 da ist auch keine BidCos-RF.dev Datei drin, nicht in /rfd.
Aber die ids Datei ist da.
Ich hatte damals das "kleine" Funkmodul, mittlerweile das große.

Dann setzt sich das Puzzle für mich jetzt anders zusammen.

Habs grad noch mal nachgestellt....
Die BidCos-RF.dev wird erst erstellt, wenn man eine Direktverknüpfung zwischen virtueller Taste und Aktor erstellt.

Dann ist mir jetzt aber wieder unklar, wie das beim Wechsel des Funkmoduls funktioniert.
In der .dev-Datei der Geräte steht die phys. Adresse der Zentrale nicht drin, nur die Seriennummer bidcos_interface="NEQ0477663".
Diese steht zusammen mit der BidCoS-Address (phys. Adresse) in der /var/ids.

Wird nun das Funkmodul getauscht, ändern sich ja beide Werte in der /var/ids.

Dann kann doch gar nicht mehr mit der alten phys. Adresse an den Aktor gesendet werden!?
Eine Übertragung der neuen Funkmoduladresse an die Geräte erfolgt ja auch nicht...

[jp112sdl]

Ah, ein wenig Licht im Dunkel...

Ich bin immer davon ausgegangen, dass /var/ids nur ein Symlink auf /etc/config/ids ist.
Aber das ist ja gar nicht so

/etc/init.d/S50eq3configd

Code: Alles auswählen

init () {
        radio_mac=$(cat /sys/module/plat_eq3ccu2/parameters/radio_mac)
        board_serial=$(cat /sys/module/plat_eq3ccu2/parameters/board_serial)
        echo "BidCoS-Address=$radio_mac" > /var/ids
        echo "SerialNumber=$board_serial" >> /var/ids
        if [ ! -e /etc/config/ids ] ; then
                cp /var/ids /etc/config
        fi
...

Die Datei /var/ids wird also beim Boot zur Laufzeit jedes Mal neu erstellt.
Sie enthält die Infos des tatsächlich aufgesteckten Moduls.

Die Datei /etc/config/ids wird nur einmalig erstellt und wandert dann mit ins Backup.
Mit der darin enthaltenen Adresse wird dann auch gefunkt.
/etc/config/rfd.conf

Code: Alles auswählen

Address File = /etc/config/ids

Spielt man nun also ein Backup auf einer anderen Zentrale ein oder ändert sich die Adresse des Funkmoduls, wird trotzdem weiterhin mit ursprünglichen Adresse gefunkt.

Nu hab ichs hoffentlich kapiert

[TomMajor]

Schöner wäre es wohl, wenn man das #ifdef ACTIVE_PING ganz nach oben packt:

Code: Alles auswählen

#ifdef ACTIVE_PING
    InfoActuatorStatusMsg msg;
    msg.init(cnt++, ch, hal.radio.rssi());
    msg.to(PING_TO);
    msg.from(PING_FROM);
    msg.ackRequired();
    msg.setRpten();
    sdev.radio().write(msg,msg.burstRequired());
#endif

Wollte sowie so einen PR für die Anzeige der RSSI Werte mit -dBm machen, nach den Erkenntnissen diese Woche im grünen Forum dazu.
Habe bei der Gelegenheit auch den range des ACTIVE_PING defines nach Vorschlag von Jerome geändert.
https://github.com/pa-pa/AskSinPP/pull/140