Alternative culfw

Begonnen von bjoernh, 15 März 2015, 12:01:06

Vorheriges Thema - Nächstes Thema

KölnSolar

Zitatweil ich das bestehende CUL device von Max auf slowRF (und die Frequenz) umgestellt habe, anstatt das alte zu löschen?
Das sollte egal sein. Mit Umstellung des rfmode wird der CC1101 neu initialisiert.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

freetz

Ok, danke, dann muss ich wohl selber mal schauen, ob ich da sinnvolle Daten ausmachen kann...
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

freetz

#1892
Was mich wundert, ist, dass es bei den Telegrammen keine Checksumme zu geben scheint, zumindest kann ich mir nicht erklären, warum bei diesen Telegrammen, die bis auf das letzte (Checksummen?-)Byte identisch sind, keine identische Checksumme enthalten ist:
AA0000000000003A
AA000000000000EE
AA0000000000000E
AA0000000000000D
AA000000000000ED

Teilweise wiederholen sich diese Telegramme, andere (mit mehr Daten als nur Nullen), dafür nicht. Aber ohne Checksummen-Byte frage ich mich, ob die Daten überhaupt vollständig/korrekt empfangen wurden...

Edit: Sehe gerade, dass meine Einstellungen so waren, dass das letzte Byte der RSSI Wert ist. Aber auch, wenn man den weglässt, sieht mir nichts davon nach einer Checksumme aus...
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

freetz

Ich habe jetzt einmal die Telegramme mitgeschnitten, die bei der Empfangsstation nach dem Einschalten zur ersten Anzeige von Temperatur und Feuchtigkeit führen, und werde da überhaupt nicht schlau daraus. Es kommen immer zwei Telegramme, von denen bei dem ersten manchmal hinreichend komplexe Bytefolgen enthalten sind, die auf eine Codierung von Fließkommazahlen hindeuten könnten. Dann aber wieder sind es Telegramme, die so simpel aussehen, dass da nie und nimmer irgendein Wert mit Bedeutung codiert sein könnte. Hinzu kommt, dass bei identischen Werten keine identischen Telegramme kommen (eigentlich noch nicht mal ansatzweise). Dabei liegt der Sender nur ein paar Zentimeter neben dem CUL-Max. Kann das trotzdem auf Empfangsprobleme beim CUL-Max hindeuten? Oder ist vielleicht der slowRF-Modus nicht passend, so wie wenn man eine falsche Baudrate bei der seriellen Schnittstelle einstellt?

Falls Ihr noch einen Hinweis habt, würde ich mich sehr freuen!

Hier die Telegrammmitschnitte (Temperatur, rel. Luftfeuchtigkeit, Kanal):

Raum 1 (Entfernung zum CUL-Max ca. 6 Meter, zwe Wände), Kanal 2:

omAAB5356C4A95C7 16,2 46 Kanal 2
omAA0AFFC000EFFF

omAAB0FC3FF1E000 16,2 46 Kanal 2
omAA000000000000

omAAB53D1815C040 15,8 47 Kanal 2
omAA0038003FFFFF80

omAAC535DBF6D006 15,9 47 Kanal 2
omAA0007FFFFC000

omAA0F99FDFE0006 15,9 47 Kanal 2
omAA000000000000

tA093C08F3C 15,8 47 Kanal 2
omAA000000000000

omAA000000000000 15,8 47 Kanal 2
omAA007FFE000000


Das vorletzte Telegramm fing hier mit "t" statt mit "om" an, leider finde ich keine Infos zu diesen Präfixen, hat das was zu bedeuten?


Raum 2 (Entfernung zum CUL-Max ca. 10cm), Kanal 3:

omAA0003FE00000000 18,7 51 Kanal 3
omAA0000007E0000

omAA9FFD3CE98798 18,7 51 Kanal 3
omAA000000000000

omAA000000000000 18,8 51 Kanal 3
omAA000000000000

omAA0000FFFF0000 18,8 51 Kanal 3
omAA000000000001

omAA00003FFFFF8000 18,8 50 Kanal 3
omAA00001E00000000

omAA000001FF801F80 18,8 50 Kanal 3
omAA07FFFFFFFFFF

omAA000000000000 18,8 50 Kanal 3
omAA000000000000
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

KölnSolar

ZitatDann müsstest Du das Protokoll selber analysieren. Am einfachsten geht das sicherlich mit einem nanoCUL als S'duino geflashed
Wenn keine Regel erkennbar ist, wird es sonst zäh :'( Wer weiß, vielleicht ist es noch nicht einmal ASK, vielleicht auch die Freq. minimal abweichend von "normalen" 433.92 Erhöhe mal bwidth. Vielleicht kommt dann eine Regelmäßigkeit. Ist das Signal wenigstens zeitlich periodisch ?
Wo hast Du die Daten "extrahiert? Raw vom Cul im Details View oder aus dem Log ?

btw., besser wäre ein eigener Thread.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

freetz

Ich kann mich beim Max-CUL per Telnet anmelden und habe dann Zugriff auf die CUL-"Kommandozeilenebene". Dort kriege ich mit X01 z.B. die eingehenden Telegramme angezeigt, die periodisch auftauchen (müssten 60 Sekunden vom Sender sein). FHEM-Log zeigt das dann letztlich auch so an.
Ich habe nun dafür einen eigenen Thread erstellt (https://forum.fhem.de/index.php/topic,106613.0.html), erstmal vielen Dank für die Hilfe bis hierhin!
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

punker

Hi,
habe einen NanoCUL433 mit aculfw 1.26.08 gekauft.
Den hab ich an einem Raspi mit WLAN mittels dieser Anleitung https://wiki.fhem.de/wiki/CUL_ueber_Netz (socat-Variante) angesteckt.
In FHEM eingebunden funzt er aber nicht
Normal sollte der so schon funzen - oder?
Ein am selben Raspi angesteckter BuswareCUL 868Mhz funzt problemlos!
Beider laufen über verschiedene Ports.
Der CUL868 zeigt "initialized" in FHEM, der 433er Nanocul nur "opened"!

Woran kanns liegen?
LG

Dieter

The truth is out there!

Ralf9

Hallo,

ich bin gerade dabei die Signalduino firmware zu erweitern, daß auf dem Maple Mini bis zu 4 cc1001 Module unterstützt werden
https://forum.fhem.de/index.php/topic,106278.0.html

Beim Einbauen der Routinen zum Detekt und init der cc1101 Module habe ich mir auch den Code von der a-culfw und AskSin angeschaut,
dabei ist mir aufgefallen, daß bei der a-culfw nirgends nach einem select() ein waitMiso() verwendet wird,
Beim AskSinPP und beim Signalduino ist es beim cc1101 reset so eingebaut
https://github.com/pa-pa/AskSinPP/blob/8268dbf6d6b76b66df3fcd081592019ebfb10064/Radio.h#L414

Ich würde es gerne beim Signalduino so einbauen, daß beim wait_Miso ein Timeout gibt.

Ich habe es so eingebaut. Ich bin mir dabei nicht sicher ob es beim wait_Miso so passt. Ist das "delayMicroseconds(10);" ok?

uint8_t res_wait_Miso() { // wait until MISO goes low
uint8_t i = 255;
while(isHigh(misoPin)) {
delayMicroseconds(10);
i--;
if (i == 0) { // timeout
cc1101_Deselect();
break;
}
}
return i;
}

bool CCreset(void) {
cc1101_Deselect();            // some deselect and selects to init the cc1101
delayMicroseconds(30);

// Begin of power on reset
cc1101_Select();
delayMicroseconds(30);

cc1101_Deselect();
delayMicroseconds(45);

cc1101_Select();
if (res_wait_Miso() == 0) {  // wait until MISO goes low
return false;            // timeout
}
sendSPI(CC1101_SRES);        // send strobe command

if (res_wait_Miso() == 0) {  // wait until MISO goes low
return false;            // timeout
}
cc1101_Deselect();

delay(10);
return true;
}



Beim Detekt habe ich den folgenden Code gefunden:
https://github.com/heliflieger/a-culfw/blob/f4305ea7ca9aba2ace6978c9c29e2645072e5c66/culfw/clib/hw_autodetect.c#L56

Bedeuted dies, daß die CC1101 PARTNUM immer 0 sein muss, und bei der cc1101 Version die Bit0-3 immer einer der folgenden Werte haben muss?   0x03, 0x04, 0x05, 0x07, 0x08

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Telekatz

Es funktioniert in der a-culfw ohne waitMiso(), weil man da nie auf das CHIP_RDYn Signal warten muss.
When CSn is pulled low, the MCU must wait
until CC1101 SO pin goes low before starting to
transfer the header byte. This indicates that
the crystal is running. Unless the chip was in
the SLEEP or XOFF states, the SO pin will
always go low immediately after taking CSn
low.

Bis der CC1101 Init Code ausgeführt wird ist der Quarz des CC1101 schon angelaufen. Und im Gegensatz zum AskSin Code bleibt er dann auch an.
AskSin wechselt auch in den SLEEP Modus. Deshalb muss man da dann warten.

Die PARTNUM ist bei allen CC11xx Chips immer 0. VERSION gibt dann an, welcher Chip es ist (CC1100, CC1101, CC1100E, CC110L oder CC113L). Siehe auch https://e2e.ti.com/support/wireless-connectivity/other-wireless/f/667/t/370643?CC1101-VERSION-register-interpretation

Ralf9

Ich finde das waitMiso beim CC1101_SRES sinnvoll.
Es lässt sich dann beim waitMiso über den timeout feststellen ob ein cc1101 angeschlossen ist.

Auszug aus der askin:
   // Pull CSn low and wait for SO to go low (CHIP_RDYn).
    spi.select();
    spi.waitMiso();

    // Issue the SRES strobe on the SI line
    uint8_t ret = spi.send(CC1101_SRES);

    // When SO goes low again, reset is complete and the chip is in the IDLE state.
    spi.waitMiso();
    spi.deselect();
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Telekatz

Ob ein CC1101 angeschlossen ist oder nicht wird in hw_autodetect schon über PARTNUM und VERSION festgestellt.

Ralf9

Ok, es funktioniert demnach auch ohne das waitMiso, demnach sind beim Signalduino bis auf evtl das CC1101_SRES die waitMiso überflüssig und können entfernt werden.

Ich finde es beim CC1101_SRES mit dem waitMiso sauberer.
Es dürfte auch keine Nachteile haben, wenn ich es beim CC1101_SRES beim waitMiso mit dem timeout mache.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Telekatz

Aber selbst für SRES ist es einfacher, einfach so lange zu warten, wie dein timeout wäre. Wenn er vorhanden ist, wird er danach über autodetect erkannt. Wenn nicht, wartet dein timeout genauso lange. Der einzigste Vorteil ist, dass dein Programm ein paar Microsekunden schneller startet.

Maista

Hallo zusammen,

ich habe hier eine Wetterstation mit einem Sensor (THGR228N) von Aldi geerbt.
Jetzt hab ich mich gefragt ob ich mit aculfw (NanoCul) auch Daten an die Wetterstation von anderen FHEM-Sensoren schicken kann?
Das Oregon-Modul ist ja nur für den Empfang der Daten ausgelegt.

Danke schon mal für die Antwort.

Gruss Gerd

KölnSolar

Hi Gerd,
leider nein. Dieses feature wollte ich auch immer mal haben.
Eigentlich müsste es mit dem S'duino klappen.
ZitatSensor (THGR228N) von Aldi geerbt
Aldi hat mal Oregon verkauft?  :-\
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt