Ich habe mit einer Platine von Technikkram und der Software von AskSinPP einen Temperatursensor mit dem Bosch BME280 gebaut.
Pairing ging einwandfei, Sensor funktioniert einwandfrei. Die Platine soll zukünftig als Entwicklungsboard für weitere Projekte
mit AskSinPP verwendet werden. Sie ist dafür gut geeignet.
Also auf Rasterplatine Arduino Mini Pro, CC11001 und BME zusammenglötet, gepaired, funktioniert einwandfrei bis heute.
Die Platine neu geflashed mit HM-RC-4 von AskSinPP, Pairen, Kanäle pairen, Virtuelles Device für Ack Antwort einrichten,
funktioniert alles, so weit so gut.
Jetzt den HM-RC-4 mit 4 Tastern auf Rasterplatine gebracht, geflasht, identisch zum Entwicklungsboard,
er läßt sich nicht mehr pairen.
Wieder auf das Entwicklungsboard geflasht, lasst sich nicht pairen.
Den Temperatursensor HM-WDS40-TH-I-BME280 geflashed, vorher Device-ID und Device Serial in der letzten Ziffer geändert,
das der erste Nachbau ja noch läuft und in FHEM integriert ist. Auch dieses Modul lässt sich nicht mehr pairen.
Ich habe alles versucht, nichts geht mehr.
Vielleicht hat jemand eine Idee und kann mir helfen.
Zur Analyse habe ich parallel imFHEM-Logfile und in der Ardino IDE Protokolliert:
Zur weiteren Info: Als CUL betreibe ich den NanoCUL 868Mhz mit rfmode HomeMatic und hmID 280247.
hier die Details:
Device Properties
// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
{0x87, 0x6f, 0x95}, // Device ID
"JPTH10I995", // Device Serial
{0x00, 0x3f}, // Device Model Indoor
0x10, // Firmware Version
as::DeviceType::THSensor, // Device Type
{0x01, 0x00} // Info Bytes
};
Arduino Monitor zum hmPairfor serial
32:35.710 -> debounce
22:32:35.778 -> pressed
22:32:36.085 -> released
22:32:36.119 -> <- 1A 10 84 00 876F95 000000 10 00 3F 4A 50 54 48 31 30 49 39 39 35 70 01 01 00 - 181512
22:32:36.152 ->
22:32:38.719 -> -> 15 03 84 01 280247 000000 01 0A 4A 50 54 48 31 30 49 39 39 35 - 184111
22:32:38.891 -> <- 1A 15 80 00 876F95 280247 10 00 3F 4A 50 54 48 31 30 49 39 39 35 70 01 01 00 - 184248
22:32:42.044 -> -> 15 04 84 01 280247 000000 01 0A 4A 50 54 48 31 30 49 39 39 35 - 187400
22:32:42.180 -> <- 1A 15 80 00 876F95 280247 10 00 3F 4A 50 54 48 31 30 49 39 39 35 70 01 01 00 - 187539
FHEM-Logfile dazu:
2020.08.26 22:29:17 5: SW: As15028401280247000000010A4a505448313049393935
2020.08.26 22:32:38 5: SW: As15038401280247000000010A4a505448313049393935
2020.08.26 22:32:41 5: SW: As15048401280247000000010A4a505448313049393935
2020.08.26 22:33:09 5: SW: As15058401280247000000010A4a505448313049393935
2020.08.26 22:34:27 3: Device 876F95 removed from ActionDetector
Arduino Monitor zum hmPairforSec 300:
22:48:58.891 -> pressed
22:48:59.232 -> released
22:48:59.266 -> <- 1A 18 84 00 876F95 000000 10 00 3F 4A 50 54 48 31 30 49 39 39 35 70 01 01 00 - 249657
22:48:59.266 ->
Hierzu ist kein Eintrag in das Logfile von FHEM erfolgt
Wiederholung hmPairForSerial
Arduino:
22:55:58.466 -> -> 15 08 84 01 280247 000000 01 0A 4A 50 54 48 31 30 49 39 39 35 - 297129
22:55:58.637 -> <- 1A 15 80 00 876F95 280247 10 00 3F 4A 50 54 48 31 30 49 39 39 35 70 01 01 00 - 297263
FHEM-Logfile:
2020.08.26 22:55:58 5: SW: As15088401280247000000010A4a505448313049393935
List vom CUL:
Internals:
CMDS ABCEeFfGhiKklMmRTtUVWXxYZz
CUL868T_MSGCNT 38
CUL868T_TIME 2020-08-26 23:52:43
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.2:1.0-port0@38400 0000
DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.2:1.0-port0@38400
FD 10
FHTID 0000
FUUID 5e6ab559-f33f-f21b-d127-0fc9ec736e579e2a
HM_CMDNR 8
NAME CUL868T
NR 119
NR_CMD_LAST_H 15
PARTIAL
RAWMSG A0C118670876F9900000000E0002E
RSSI -51
STATE Initialized
TYPE CUL
VERSION V 1.67 nanoCUL868
hmPairSerial JPTH10I995
initString X21
Ar
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2020-04-13 19:48:06 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2020-08-26 22:24:17 cmds A B C E e F f G h i K k l M m R T t U V W X x Y Z z
2020-03-17 06:41:30 raw 6
2020-08-26 23:52:43 state Initialized
2020-08-25 01:02:10 uptime 0 01:33:54
2020-08-25 01:01:48 version V 1.67 nanoCUL868
XMIT_TIME:
1598475148.61357
1598475188.15142
1598475655.21138
1598475933.67245
1598476258.03312
1598476260.97124
1598476300.9268
1598476852.23839
1598477872.06619
1598478172.42528
1598478245.11712
1598478452.01646
1598478744.76637
1598478744.88614
1598478745.34744
helper:
6B5B22:
QUEUE:
6B5CAD:
QUEUE:
6B5D88:
QUEUE:
6B5DDC:
QUEUE:
6B5DE9:
QUEUE:
6B5E1A:
QUEUE:
6B5E1D:
QUEUE:
6B5E2A:
QUEUE:
6B9B30:
QUEUE:
6B9B51:
QUEUE:
6C1515:
QUEUE:
Attributes:
comment Sende- und Empfangsmodul (transceiver) 868MHz eingestellt auf die Homatic Protokolle,
führt die Kommunikation zu allen HM-devices durch, Fensterkontakte, Thermometer, Tastenfernbedienung usw.
group rf_Transceiver
hmId 280247
icon cul_868
rfmode HomeMatic
room CUL_HM,CUL_alle,Heizung,Schalter,Steckdosen
verbose 5
Warum erst alles funktioniert hat und jetzt nichts mehr geht ist mir unverständlich
autocreate ist activ und funktioniert, habe ich mit einem einfachen Pearl Funkthermometer ausprobiert.
Hast Du zwischen durch ein Update von FHEM gemacht ? Derzeit scheint einiges im Homematic-Module geändert zu werden. Vielleicht geht deshalb das Pairen auch nicht mehr.
Wenn jetzt ein anderes Funkmodul verwendet wird, könnte es auch sein, dass dieses mit einen abweichenen Frquenz läuft. Einfach mal folgendes probieren: https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html
Danke für den Tip.
Auf der Platine, die für zukünftige Projekt als Platform dienen soll, wurde die Hardware nicht verändert, das Sendemodul ist noch das gleiche CC1101, der Arduino Mini und das BME280 ebenfalls dazu noch Taster, Widerstand und LED, mehr ist nicht drauf.
Der einzige Unterschied ist die Device id und die Seriennummer, jeweils 5 statt 9 am Ende. Das musste ich ändern das Modul mit 9 am Ende jetzt den Istwert für die Regelung der Fußbodenheizung überträgt, Gleiche Schaltung, gleiche Software, war vorher auf dem Entwicklungsbord.
Ich werde morgen noch mal einen neuen Fensterkontakt HM_SEC_SCO bauen und ausprobieren, bin gespannt ob das funktioniert.
Da hat sich ein Schreibfehler eingeschlichen, es muss heißen
Das musste ich ändern, da das Modul mit 9 am Ende jetzt den Istwert für die Regelung der Fußbodenheizung überträgt.
Für den neuen Fensterkontakt hat autocreate problemlos ein device erstellt und er konnte ohne Probleme sofort gepaired werden.
Am autocreate oder am CUL liegt es demzufolge vermutlich nicht.
coole log. Wir arbeiten hier mit dem Sniffen, wie in Wiki beschrieben.
Auszu zeichnen ist das pairen (logisch) . Ab dem Zeitpunkt, wenn du "config" (= Anlernen) am auslöst.
Wird ein device angelegt?
Ich kenne es auch so, wenn ich den config button drücke legt autocreate ein device an, danach kann man pairen.
Leider wird hier kein device angelegt und es ist auch kein Eintrag im Logfile bei config drücken.
Beim neuen Fensterkontakt hat das alles funktionert, dh. autocreate und hmPairForSec funktionieren.
Das hat ja auch mit diesen Modulen einmal funktioniert und der baugleiche Temperatursensor funktioniert einwandfrei.
Nur bei der Wiederholung auf einem Nachbau der Hardware (gleich dem Temperatursensor) und auf dem fertigem Board von Technikkram funktioniert es nicht, Im Arduino Monitor wird die korrekte Funktion und auch der Empfang des Pairing Signals von FHEM angezeigt. Kann es vielleicht sein das durch das erste Pairing im Mini Pro Register vorbelegt sind, die auch beim erneuten flshen nicht gelöscht werden. Ich bin da leider kein Fachmann.
Du kannst ja mal nen RESET - ConfigButton mindestens 6 Sekunden drücken - versuchen. Das sollte bei allen Geräten gleich sein. Dannach wird der EEPROM neu initialisiert.
nun, ich würde erst einmal sniffen
Du solltest ein Device 876F95 haben. Wenn du nichts gelöscht hast. Eine Bestätigung bringt
{$modules{CUL_HM}{defptr}{"876F95"}{NAME}}
sollte den Namen des Devices ausgeben.
Nun kannst du Verbose auf 5 für das Device einschalten.
hmPairForSec am IO einstellen.
Noch einmal config drücken (sniffen wäre immernoch gut:) )
Ein Log mit de Seriennummern und mehr sollte kommen
Leider habe ich kein device, weder durch autocreate noch beim pairing wurde ein device angelegt. Ich habe die ID geändert in 876f97, daher die Infos alle unter 876F97.
{$modules{CUL_HM}{defptr}{"876F97"}{NAME}} zeigt kein device
{$modules{CUL_HM}{defptr}{"876F99"}{NAME}} zeigt HM_876F99 an, das ist der erste baugleiche Nachbau und arbeitet als Temperatursensor einwandfrei.
In fhem.cfg habe ich eingetragen
attr global verbose 1
attr global mseclog 1
attr <cul> verbose 4
und rereadcfg ausgeführt.
Beim Drücken der config Taste gibt es im Logfile keinen Eintrag, auch nicht wenn FHEM in den pairing Mode versetzt wird hmPairForSec 300.
Beim Drücken der config Taste und anschließendem hmPairSerial
ist der Eintrag im Logfile
2020.08.29 22:53:04.086 5: SW: As15038401280247000000010A4a505448313049393937
und im Arduino Monitor
22:53:05.074 -> -> 15 03 84 01 280247 000000 01 0A 4A 50 54 48 31 30 49 39 39 37 - 201000
22:53:05.209 -> <- 1A 15 80 00 876F97 280247 10 00 3F 4A 50 54 48 31 30 49 39 39 37 70 01 01 00 - 201138
22:53:17.786 -> ignore 0C 6D 86 70 876F99 000000 00 D7 00 - 213637
22:53:28.131 -> Measure...
22:53:28.131 -> T/H = 222/47
22:53:28.165 -> <- 0C 17 86 70 876F97 000000 00 DE 2F - 221026
22:56:48.795 -> Measure...
22:56:48.795 -> T/H = 223/47
22:56:48.828 -> <- 0C 18 86 70 876F97 000000 00 DF 2F - 221069
Das Modul empfängt offenbar um 22:53:05.074 die hmID und sendet als Bestätigung die deviceID und die hmID zurück, so interpretiere ich diese Einträge.
Scheinbar hat das Modul die hmID nicht gespeichert, da die folgende Sendung von Temperatur und Feuchtigkeit keine hmID enthält sondern 000000.
FHEM zeigt dazu keinen Eintrag im Logfile an.
In dem Zeitraum gibt es nur Meldungen 876F99.
2020.08.29 22:53:16.843 5: CUL868T: dispatch A0C6D8670876F9900000000D700::-49:CUL868T
2020.08.29 22:56:32.131 5: CUL/RAW: /A0C6E8670876F9900000000D70035
2020.08.29 22:56:32.131 4: CUL_Parse: CUL868T A 0C 6E 8670 876F99 000000 00D70035 -47.5
Ich habe jetzt einmal den HM-RC-P1 auf das Modul geflashed und habe folgende Einträge.
Logfile FHEM
2020.08.30 02:05:20 4: CUL_Parse: CUL868T A 0B 06 8640 001A00 000000 410001 -73.5
2020.08.30 02:05:20 5: CUL868T: dispatch A0B068640001A000000004100::-73.5:CUL868T
2020.08.30 02:05:20 3: CUL868T: Unknown code A0B068640001A000000004100::-73.5:CUL868T, help me!
Arduino:
02:05:19.319 -> 01 pressed
02:05:19.728 -> 01 longpressed
02:05:19.762 -> <- 0B 03 86 40 001A00 000000 41 00 - 323
02:05:20.203 -> 01 longpressed
02:05:20.237 -> <- 0B 04 86 40 001A00 000000 41 00 - 358
02:05:20.642 -> 01 longpressed
02:05:20.676 -> <- 0B 05 86 40 001A00 000000 41 00 - 395
02:05:21.123 -> 01 longpressed
02:05:21.123 -> <- 0B 06 86 40 001A00 000000 41 00 - 430
02:05:21.191 -> 01 longreleased
02:05:21.225 -> <- 0B 07 86 40 001A00 000000 41 00 - 468
Dieses wurde nur einmal erzeugt nach dem ersten Start.
Bei erneutem Tastendruck als auch Neustart und Tastendruck war keine Meldung hierzu im Logfile mehr.
kannst du nun einmal die Logs wie in sniffen dargestellt erstellen? Ich habe keine Lust, auf das Logging einzelner User einzugehen. Du kannst sie gerne für dich nutzen.
Beim nächsten mal werde ich das einfach ignorieren - sorry.
warum machst du hmPairForSec und dann noch hmPairSerial? Eins nach dem anderen bitte. Getrennt mit separaten Logs!!!
Und dazwischen immer das clear msgEvents nicht vergessen.
Da ich nur ein config sehe und du beschreibst, es 2-mal gedrückt zu haben bitte ich dich also die Logs geordnet und wie angefragt zu erstellen.
Unter sniffen habe ich nur gefunden, in fhem.cfg die Anweisungen
attr global verbose 1
attr global mseclog 1
attr <cul> verbose 4
einzugeben.
Das Ergebnis stünde dann im Logfile.
Was muss ich anders machen, als die Teile aus dem Logfile auszugeben, die dieses device betreffen?
Die Arduino Protokolle habe ich nur zugefügt, damit man sehen kann, was der Arduino des Modules über das CC1101 ausgibt bzw. empfängt.
mfg
Also ich tippe auf ein "fehlerhaftes" CC1101 Modul. Es kann zwar etwas empfangen - aber FHEM hört die Antwort nicht. Bitte mal die Anweisungen von hier https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html befolgen.
Das sollte leider Pflicht werden, da es nur noch minderwertige CC1101-Module auf dem Markt gibt.
Danke für die Hinweise.
asksinpp Grundlagen habe ich gelesen, sonst hätte ich das Modul nicht bauen können.
Die FAQs habe ich durchsucht, hat mir leider nicht weitergeholfen.
Ich glaube nicht, dass das CC1101 nicht funktioniert, weil
- dieses Board beim ersten mal als Temperatursensor richtig funktioniert hat, der Nachbau frei verdrahtet mit der gleichen Software funktioniert bis heute.
- das erneute flashen des boards als HM-RC-4 hat ebenfalls funktioniert, aber eben nur einmal und mit dem Nachbau und in Wiederholung mit dem board nicht wieder.
- das erneute flashen des boards als HM-RC-P1, devID 001A40, sandte nach der Inbetriebname eine Nachricht aus, siehe Protokoll Arduino, diese wurde vom CUL868T empfangen, siehe Logfile.
Das funktionierte nur bei der ersten Inbetriebnahme einmal, danach niemals wieder. Aber es zeigt, dass das Modul gesendet hat.
Offenbar konnte FHEM mit dem gesendeten Code nichts anfangen (Logeintrag Unknown Code A0B0... :CUL868T help me)
Ich bin am Donnerstag wieder zu Hause und werde weiter probieren.
Über einen Tip, welche Untersuchungen und welche Darstellungen hilfreich sind, wäre ich dankbar.
mfg
deine CUL ist geflashed? Sie hat die HM-FW geladen? Die "normale" kann keine timestamps.
Auch die FHEM CUL sollte TSCUL nutzen.
wie ist dein Stand?
Auch wenn der CUL - mal was empfangen hat, solltest Du den Frequenztest laufen lassen. Nur weil mal eine Nachricht durch kam, funktioniert das noch lange nicht. Damit es geht, muss halt jede Nachricht durchkommen.
Schreibfehler devID 001A00 statt 001A40
Meine CUL ist eine nanoCUL868 mit rfmode HomeMatic.
ein list ist weiter oben.
was ist TSCUL?
gelöst.
Aus welchem Grund auch immer, die beiden CC1101 haben nicht gesendet, obwohl ein Modul auf dem Board zuerst sowohl als Temp-Sensor geflashed als auch als HM-RC-4 geflashed funktioniert hat und dann nicht mehr.
Beide Module empfangen auf der richtigen Frequenz (866.296Mhz und 866.294Mhz), aber senden nicht mehr.
Es sieht so aus als wären beide gleichermaßen zerstört worden, woduch?
Der Mini Pro arbeitet korrekt und der FTDI Adapter gibt 3,6 V aus, daran scheint es nicht zu liegen.
2 neue CC1101 beschafft und eingelötet, alles funktioniert einwandfrei.