Hallo,
ich hatte bisher einen nanoCUL 868 für einen HM Bewegungsmelder in Betrieb und das hat auch reibungslos funktioniert.
Nun habe ich mir einen weiteren nanoCUL 433 zugelegt um Funkseckdosen zu schalten.
Den habe ich dann installiert bzw. in FHEM eingebunden und auch das hat soweit geklappt.
Nach einem FHEM Update hat sich der nanoCUL 868 pötzlich als 433 gemeldet und der Bewegungsmelder funktioniert nicht mehr.
Habt ihr eine Idee was ich da falsch gemacht haben könnte bzw. ob es vielleicht garnicht möglich die beiden nanoCUL parallel zu betreiben?
Irgendwie kann ich so recht nichts finden was mir dazu weiterhilft.
Danke im Voraus für eure Hilfe!
Grüße
Bernhard
S. hier https://wiki.fhem.de/wiki/Selbstbau_CUL#Hinweise_zum_Betrieb_mit_FHEM (https://wiki.fhem.de/wiki/Selbstbau_CUL#Hinweise_zum_Betrieb_mit_FHEM)
Geht allerdings nur bei NanoCULs mit eindeutiger IDs. Ist dies nicht der Fall, gibt es noch die Möglichkeit sie mit "/dev/serial/by-path/..." einzubinden, man darf sie danach aber nicht mehr umstecken, ohne die Definition anzupassen.
Du hast sie falsch eingebunden oder welche gekauft die zufällig den gleichen tty chip ohne eindeutige id haben. Einbinden musst du die immer mit /dev/serial/by-id/.......
Vielen Dank schon mal an alle! Denke schon, dass ich sie richtig eingebunden habe mit /dev/serial/by-id/... aber ich prüfe das noch mal und komme bei Bedarf noch mal wieder mit weiteren Details.
Also den nanoCUL 868 habe ich wie folgt eingebunden --> /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A5011P5A-if00-port0@38400 1234.
Unter VERSION steht dann --> V 1.26.03 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 868MHz), das kommt mir komisch vor.
Den nanoCUL 433 habe ich so eingebunden --> /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 0000.
Unter Version steht bei dem dann --> V 1.67 nanoCUL433.
Ich tue mir echt schwer das was raus zu lesen, sagt das euch vielleicht mehr?
So wie ich das sehe hat jemand auf dem 868 nanocul die firmware mit 433MHz aufgespielt und ihn dann umkonfiguriert auf 868MHz. Das Problem dabei ist das der Nanocul nur wenig speicher hat und daher so viele 433MHz Protokolle in der Firmware stecke und nicht so viele 868MHz Protokolle. Also ich würde an deiner stelle beide mit der aktuellen a-culfw flashen und darauf achten das sie auch mit der passenden Frequenz geflasht werden.
Hallo Eistee, vielen Dank für deine Tipps! Der Held der da was verbogen hat war wohl ich :-\.
Den einen nanoCUL868 hatte ich schon geflasht mal hier von einem Forum-Member gekauft und der hat jetzt auch seit über einem Jahr problemlos seine Dienste erledigt.
Den nanoCul433 habe ich selbst zusammengebaut und dann direkt am Raspberry nach dieser Anleitung geflasht --> https://haus-automatisierung.com/hardware/fhem/2017/11/18/fhem-tutorial-reihe-part-44-nano-cul.html (https://haus-automatisierung.com/hardware/fhem/2017/11/18/fhem-tutorial-reihe-part-44-nano-cul.html).
Der hat dann auch funktioniert. Aber vielleicht habe ich dabei an dem nanoCul868 etwas zerschossen.
Ja dann mache ich mich dran beide neu zu flashen.
Jetzt vielleicht noch eine dumme Frage: Kann ich dann beide nanoCULs gem. der verlinkten Anleitung flashen und bei einem am Schluss das "make programm-433" und beim anderen das "make programm-868" ausführen, oder muss ich da sonst noch was beachten?
Ach ja, muss ich die beiden nanoCULs davor erst noch irgendwie zurücksetzen, wenn ja, wie geht das?
den 868er solltest Du mit der culfw 1.67 flashen, da die aculfw für diese Frequenz eigentlich keine Vorteile bietet. Den 433er mit der aculfw, da hier bedeutend mehr Protokolle für 433MHz implementiert sind.
Grüße Markus
Was willst du mit dem 868-er eigentlich machen?
Wenn HomeMatic, wäre die TS-CUL-firmware eine Überlegung wert... Ansonsten wäre vorab zu klären, ob die Konfiguration der aculfw die Protokolle enthält, die du auf 868 benötigst. Ist das der Fall, brauchst du eigentlich nichts an der firmware zu ändern ;) . Das scheint ja der Fall zu sein, wenn es bisher funktioniert hat...
"Zurücksetzen" muß man vor dem neuen flashen nichts, die neue firmware überschreibt die alte.
Eventuell solltest du drei Dinge nochmal ansehen:
- Gibt es weitere USB-Devices? (dann auch die anderen auf by-id/by-path umstellen!)
- Test-PIN am FTDI auf GND? (ist der ATMega ansprechbar? Siehe FHEM-Wiki zu Arduino)
- Spannungsversorgung ausreichend?
Den nanoCUL 868 habe ich aktuell ausschließlich mit einem Homematic Bewegungsmelder "HM-Sen-MDIR-SM" am laufen und dafür suche ich die Lösung weil das nicht mehr funktioniert.
Dann würde ich diesen vielleicht jetzt als nächstes doch noch mal mit der culfw 1.67 flashen und testen, oder was meint ihr?
HM => Empfehlung wie schon erwähnt: TS-CUL-firmware (https://forum.fhem.de/index.php/topic,24436.0.html)
Aber nochmal: Wenn es nicht mehr funktioniert, seit der 2. CUL dran hängt (und du nicht versehentlich den "falschen" umgeflasht hast), dürfte was anderes die Ursache sein. Neben dem schon genannten: versehentlich vertauscht, bevor die Definition über by-id gemacht wurde? Also so, dass jetzt das 433-er Gerät mit 868 MHz betrieben wird und umgekehrt? Die firmwares legen das nahe...
Vielen Dank Beta-User! Ich denke am ehesten, dass ich den nanoCUL 868 nicht ausgesteckt hatte während ich den neuen nanoCUL 433 flashen wollte :-[ und daher vielleicht das Problem verursacht habe.
Dann werde ich mich heute Abend mal mit der TS-CUL-firmware versuchen.
Wenn du nur einen flash-Vorgang ausgelöst hattest, mußt du eigentlich zwangsläufig den "Eigenbau" erwischt haben, sonst wäre da jetzt gar keine fw drauf... (Jedenfalls habe ich noch keinen Nano in die Hand bekommen, auf der diese firmware "out of the box" drauf war). Da auch beide unterscheidlich sind, spricht das eher dafür, dass ein solches Versehen nicht vorliegt.
Kannst aber letztlich nur du wissen ;) . Ansonsten bleibe ich bei der Behauptung, dass etwas anderes faul ist ::) .
Für TS-CUL benötigst du aber auch einen Tausch diverser Module, nicht nur die firmware (steht alles im ersten Thread des Posts, glaube ich).
Ich finde ja nur die Version merkwürdig:
V 1.26.03 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 868MHz)
F-Band sagt doch aus das er aktuell auf 868MHz läuft. nur warum steht da dann nanoCUL433 bei?
Liefere doch mal ein list von den beiden...
Zitat von: Eistee am 28 August 2018, 15:00:01
Ich finde ja nur die Version merkwürdig:
V 1.26.03 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 868MHz)
F-Band sagt doch aus das er aktuell auf 868MHz läuft. nur warum steht da dann nanoCUL433 bei?
Das dürfte dann nicht merkwürdig sein, wenn wirklich der HM-Mode darauf aktiviert ist. Der stellt dann den CC1101 auf die passende Frequenz und das liefert dann auch ccconfig...
"Schwierig" wird es nur, wenn der Antennenschaltkreis für 433MHz ausgelegt ist; dann sind die Sendeleistungen mau und empfangen wird uU. auch nichts. Dto., wenn es für den 868-er auf 433 gestellt wird, allerdings kann ein solcher 868-er tatsächlich was auf 433MHz senden und uU. auch empfangen.
Deswegen nochmal die Empfehlung, die DEF's testweise mal zu tauschen und dann zu sehen, ob das nicht schon alles war ;) .
Erst noch mal 1000 Dank für alle die sich so sehr bemühen um mir zu helfen, da kann ich einfach nur dazu lernen!!!
Ich schaue mir das heute Abend noch mal alles an und gebe Rückinfo.
Normalerweise sollte ich das mit euren Lösungsvorschlägen irgendwie schaffen ;).
Schönen Tag noch und bis dann!
So, das ist jetzt das List des nanoCUL433 den ich selbst geflasht habe:
Internals:
CMDS ABCEeFfGhiKklMmRTtUVWXxYZz
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 0000
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
FD 22
FHTID 0000
NAME nanoCUL433
NR 128
PARTIAL
RAWMSG tA01B739732E6
RSSI -87
STATE Initialized
TYPE CUL
VERSION V 1.67 nanoCUL433
initString X21
nanoCUL433_MSGCNT 4
nanoCUL433_TIME 2018-08-28 19:30:44
MatchList:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04......a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-08-28 19:16:34 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
2018-08-27 20:05:22 raw No answer
2018-08-28 19:30:44 state Initialized
2018-08-24 20:13:55 version V 1.67 nanoCUL433
Attributes:
rfmode SlowRF
room CUL
Und hier noch das List von dem nanoCUL868. Den hatte ich hier im Forum vom Member "gloob" und der war laut seinen Angaben mit der im Jan. 2018 aktuellen culfw geflashed und hat mit dem HM-Sen-MDIR-SM ja auch mindestens 1 1/2 Jahre perfekt funktioniert.
Internals:
CMDS ABCeFfGiKLlMNRTtUVWXx
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A5011P5A-if00-port0@38400 1234
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A5011P5A-if00-port0@38400
FD 17
FHTID 1234
NAME nanoCUL868
NR 135
PARTIAL
RAWMSG A0DECA6411DCAE1133AC701EC0040FE
RSSI -75
STATE Initialized
TYPE CUL
VERSION V 1.26.03 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 868MHz)
initString X21
Ar
nanoCUL868_MSGCNT 3
nanoCUL868_TIME 2018-08-28 02:24:18
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-08-28 19:23:56 cmds A B C e F f G i K L l M N R T t U V W X x
2018-08-28 19:23:56 state Initialized
helper:
Attributes:
rfmode HomeMatic
room CUL
Glaube mir dämmert jetzt was mir passiert sein könnte.
Ich habe auf dem neuen nanoCul433 die culfw geflasht und danach gelesen, das die a-culfw die bessere Lösung wäre.
Danach habe ich versucht die a-culfw zu flashen und befürchte, dass ich meinen vorher funktionierenden nanaCUL868 überschrieben haben könnte.
Die Frage ist nur ob es wirklich so ist und ob ihr das aus den Lists evtl. erkennen könnt?
Das mit dem F-Band: 868MHz kommt daher, dass ich in der ersten Verzweiflung gedacht hatte, dass der 868 nicht mehr funktioniert weil der rfmode nicht auf Homematic steht und hab das umgestellt (ahnunglos halt :-\)
Noch zur Ergänzung:
Wenn ich bei dem nanaoCUL868 den rfmode auf SlowRF umstelle, dann sieht das list wie folgt aus:
Internals:
CMDS ABCeFfGiKLlMNRTtUVWXx
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A5011P5A-if00-port0@38400 1234
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A5011P5A-if00-port0@38400
FD 15
FHTID 1234
NAME nanoCUL868
NR 135
PARTIAL
STATE Initialized
TYPE CUL
VERSION V 1.26.03 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 868MHz)
initString X21
MatchList:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04......a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-08-28 20:08:53 ccconf freq:868.000MHz bWidth:325KHz rAmpl:42dB sens:4dB
2018-08-28 20:08:28 cmds A B C e F f G i K L l M N R T t U V W X x
2018-08-28 20:06:21 state Initialized
2018-08-28 20:08:38 version V 1.26.03 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 868MHz)
helper:
Attributes:
rfmode SlowRF
room CUL
Dann kommt das "F-Band: 868MHz" bei der Version doch nicht davon, dass ich den rfmode auf Homematic umgestellt hatte.
Welchen rfmode müsset ich den eigentlich für den Bewegungsmelder "HM-Sen-MDIR-SM" einstellen?
Und warum flashst du nicht die a-culfw auf den 433MHz? Die kann doch deutlich mehr Protokolle.
Zitat von: Eistee am 28 August 2018, 20:54:13
Und warum flashst du nicht die a-culfw auf den 433MHz? Die kann doch deutlich mehr Protokolle.
Das wollte ich eigentlich aber in meiner Naivität habe ich das wohl verbockt. Dann ich das als nächstes für den 433 probieren. Aber meine größere Sorge ist eigentlich der 868 weil da der Bewegungsmelder HM-Sen-MDIR-SM für die Kamera dran hängt. Wie müsste ich den dann jetzt flashen damit das wieder funktionieren?
Gesendet von meinem HUAWEI VNS-L31 mit Tapatalk
Sorry Leute, aber das geht irgendwie sehr durcheinander...
Also: Für HM muß auch der Modus für HomeMatic eingestellt werden, und nach meinem Kenntnisstand wird dabei auch die Frequenz automatisch angepaßt (und im EEPROM des CC1101 gespeichert; daher steht das auch dort, bis man es wieder ändert). Alle drei Varianten der firmware sollten das HM-Protokoll beherrschen (nur nicht gleich gut...), und da ccconf gestern abend auch was vernünftiges erhalten hat, paßt scheinbar auch die Kommunikation bis zum CC1101 (es ist also vermutlich KEIN firmware-Problem und auch die Hardware dürfte "sauber" sein).
[OT]Ggf. solltest du überlegen, ob du gleich noch eine VCCU einrichtest, für den Fall, dass du HM weiter ausbauen willst (dann wäre mittelfristig ein (zusätzliches) anderes IO anzuraten...).
[/OT]
Von daher würde ich zunächst vorschlagen, erst mal alle anderen USB-devices auszustöpseln (die Antwort auf die indirekt gestellte Frage, ob es solche gibt, bist du uns noch schuldig) und dann den 868-er wieder für HM einzurichten, dass das funktioniert. Nicht gesetzt war eine HmID, das müßte man nachholen, wenn der Bewegungsmelder was an eine andere Zentrale als F11234 sendet (das sollte dort nach entsprechender Konfiguration des CUL zu sehen sein). Bitte also nach mind. 10 Min Betrieb auch ein list vom Bewegungsmelder...
DANACH kann man sich mit dem 433-er beschäftigen, wobei du dir zuerst überlegen solltest, ob du die erweiterten Optionen der aculfw brauchst oder das Teil besser als Signalduino betreibst (ganz andere firmware). Kommt auf die Devices an, die du nutzen willst...Funktioniert der 868-er nicht mehr, wenn auch der 433-er eingestöpselt ist, handelt es sich um ein Problem bei der Spannungsversorgung (auch dazu hast du bisher _nichts_ gesagt... Nur die Frage nach dem Test-PIN hast du indirekt mit dem Hinweis auf die Bezugsquelle beantwortet :( ).
Entschuldige bitte, denke für die meiste Verwirrung sorge ich wohl selbst, da leider nicht so versiert bin was diese Themen angeht.
Nichtsdetotrotz bin ich bestrebt dazuzulernen ;).
Folgende USB Devices hängen an meinem Raspberry Pi 2B:
Bus 001 Device 022: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 008: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]
Bus 001 Device 020: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ID 1a86:7523 ist der neu hinzugekommene nanoCUL433
ID 0403:6001 ist der nanoCUL868 an dem der HM-Sen-MDIR-SM hängt
ID 7392:7811 ist der WLAN Adapter
Das ist alles was dran hängt.
Jetzt habe ich den 433 mal ausgesteckt und den 868 wieder auf rfmode HomeMatic gestellt.
Tatsächlich funktioniert jetzt mein Bewegungsmelder HM-Sen-MDIR-SM auch wieder.
Hier das list dazu:
Internals:
DEF 1DCAE1
IODev nanoCUL868
LASTInputDev nanoCUL868
MSGCNT 12
NAME BewM_Haustuer
NOTIFYDEV global
NR 73
NTFY_ORDER 50-BewM_Haustuer
STATE noMotion
TYPE CUL_HM
lastMsg No:26 - t:41 s:1DCAE1 d:133AC7 01264540
nanoCUL868_MSGCNT 12
nanoCUL868_RAWMSG A0D26A6411DCAE1133AC701264540::-83:nanoCUL868
nanoCUL868_RSSI -83
nanoCUL868_TIME 2018-08-29 19:51:38
protLastRcv 2018-08-29 19:51:37
protRcv 5 last_at:2018-08-29 19:51:37
rssi_at_nanoCUL868 cnt:12 min:-89.5 max:-79 avg:-82.33 lst:-83
READINGS:
2017-12-27 16:40:33 D-firmware 1.2
2017-12-27 16:40:33 D-serialNr JEQ0459365
2018-08-29 19:51:37 battery ok
2018-08-29 19:51:37 brightness 69
2018-07-31 16:34:49 cover closed
2018-08-29 19:51:54 motion off
2018-08-29 19:51:37 motionCount 38_next:15s
2018-08-29 19:51:54 motionDuration 17
2018-07-31 16:34:49 powerOn 2018-07-31 16:34:49
2018-07-31 16:34:49 recentStateType info
2018-08-29 19:51:54 state noMotion
2018-08-29 19:51:37 trigDst_133AC7 noConfig
2018-08-29 19:51:37 trigger_cnt 38
helper:
HM_CMDNR 38
mId 004F
regLst ,0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +1DCAE1,00,00,00
nextSend 1535565098.8548
prefIO
rxt 2
vccu
p:
1DCAE1
00
00
00
mRssi:
mNo 26
io:
nanoCUL868:
-81
-81
prt:
bErr 0
sProc 0
sleeping 1
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
rssi:
at_nanoCUL868:
avg -82.3333333333333
cnt 12
lst -83
max -79
min -89.5
Attributes:
IODev nanoCUL868
autoReadReg 4_reqStatus
devStateIcon noMotion:IR@green motion:IR@red
expert 2_raw
firmware 1.2
model HM-SEN-MDIR-SM
room CUL_HM,Eingang
serialNr JEQ0459365
subType motionDetector
Wo und wie die HmID zu setzen ist und woher ich die bekomme weiß ich allerdings nicht, vielleicht könnt ihr mir das kurz erklären.
Als nächstes schaue ich jetzt mal was passiert wenn ich den nanoCUL 433 wieder einstecke.
Zukünftig soll noch ein weiterer Bewegungsmelder HM-Sen-MDIR-SM eingebunden werden und mit dem nanoCUL 433 steuere ich aktuell lediglich Funksteckdosen an.
Meine Ansprüche sind also aktuell relativ gering was halt auch meinem Anfängerstatus entspricht.
Um so mehr bin ich aber begeistert, dass auch solche Anfänger eine Chance bekommen, auch wenn ich manches in den Kommentaren noch garnicht zuordnen kann.
Habe jetzt den nanoCUL 433 wieder eingesteckt und getestet, der funktioniert, ich kann meine Funksteckdosen schalten.
Aufgefallen ist mir jetzt noch, dass nach dem Einstecken des 433 ein autocreate für einen CUL_TX_13 erfolgt der Temperaturen meldet?!
Habe echt keine Ahnung wo das jetzt her kommt :-\ ?!
Hier mal das list dazu.
Internals:
CFGFN
CODE 13
DEF 13
LASTInputDev nanoCUL433
MSGCNT 7
NAME CUL_TX_13
NR 539
STATE T: 23.7
TYPE CUL_TX
corr 0
lastH 0
lastT 1535567893
minsecs 0
nanoCUL433_MSGCNT 7
nanoCUL433_RAWMSG TXA01A737730
nanoCUL433_RSSI -85
nanoCUL433_TIME 2018-08-29 20:38:13
READINGS:
2018-08-29 20:38:13 state T: 23.7
2018-08-29 20:38:13 temperature 23.7
Attributes:
room CUL_TX
Mein 868 funktioniert aber jetzt auch noch denn mein Bewegungsmelder meldet wieder :D.
Das ist ja soweit prima aber irgendwie irritiert mich das auch.
Jetzt beobachte ich das halt mal die nächsten Tage.
Der Cul_tx_13 sendet in der Nachbarschaft. Einfach das Attribut ignore setzen, wenn Du ihn nicht behalten willst. Das wirst Du noch öfter haben. Schau aber auch noch in den Räumen Plots und Logs nach, dort werden wahrscheinlich entsprechende Devices angelegt worden sein. Die kannst Du einfach löschen.
LG
Andreas
Zitat von: berny25 am 29 August 2018, 20:49:29
Mein 868 funktioniert aber jetzt auch noch denn mein Bewegungsmelder meldet wieder :D .
Das ist ja soweit prima aber irgendwie irritiert mich das auch.
Schön, dass das bis dahin funktioniert. Leider ist das nur ein Teil der Wahrheit...
Vorab eine Anmerkung: du wirst kaum umhin kommen, dich etwas in die Themen einzuarbeiten und selbst mitzudenken. Sonst wirst du nicht lange Freude an FHEM haben und solltest darüber nachdenken, ob dies eine passende Lösung für deine Anliegen ist.
Die nachfolgenden Ausführungen wirst du vermutlich erst mal nicht verstehen, aber bitte lies dich an den angegebenen Stellen einfach in die Materie ein und stelle ggf. erst danach Fragen. Alle * bedeuten: sollte nach meiner Kenntnis da stehen, ggf. solltest du weitere in FHEM übliche Quellen (https://wiki.fhem.de/wiki/Dokumentationsstruktur) befragen.
Dass Funk den Vor- und Nachteil hat, dass man mit dem passenden Empfänger (z.B. mit FHEM) alles mögliche empfangen, auswerten und einbinden kann, hast du hoffentlich seit der Antwort von rischbiter123 auf dem Schirm. Das gilt im Prinzip auch für das Steuern von Aktoren...
Damit sind wir im Falle von HM bei der HmID für den CUL (bzw. auch andere HM-IO's und eine VCCU). Bitte lies daher in der commandref* nach, was es mit der HmID (für den HM-CUL) auf sich hat und im Wiki*, wozu eine VCCU gut ist. Dann solltest du dich mit RSSI beschäftigen (Wikipedia*).
Da du bislang nur ein HM-Gerät hast und ich mal nicht unterstelle, dass sich dein Nachbar den Bewegungsmelder einverleibt hat, würde ich als ersten Fix mal empfehlen, die HmID des CUL auf 133AC7 zu setzen. Dann mal ein getConfig für den Bewegungsmelder auslösen und einige Zeit warten, dann sollten nach einem Browser-refresh neue Readings am Bewegungsmelder dazugekommen sein.
Dabei kann es zwei Probleme geben: die eine hat mit RSSI zu tun und die andere mit einer eventuell doch anderen HmID für die im Bewegungsmelder gespeicherte Zentrale.
Just my2ct.
Beta-User
Guten Morgen Beta-User!
Vielen Dank für deine Tipps die mir schon sehr weitergeholfen haben, das gilt natürlich auch für alle anderen die sich meiner Thematik angenommen haben!
Mir ist klar geworden, dass ich mich weiter in die "Geheimnisse" von FHEM einarbeiten muss und auch möchte weil so ein System halt einfach auch einen besonderen Reiz hat.
Denke mit deinen Tipps und den Quellengaben sollte ich ein riesen Stück weiter kommen.
Ich habe die HmID des CUL868 auf 133AC7 gesetzt und auch ein getConfig für den Bewegungsmelder ausgelöst.
Nach dem getConfig sieht das list für den Bewegungsmelder wie folgt aus:
Internals:
DEF 1DCAE1
IODev nanoCUL868
LASTInputDev nanoCUL868
MSGCNT 121
NAME BewM_Haustuer
NOTIFYDEV global
NR 73
NTFY_ORDER 50-BewM_Haustuer
STATE noMotion
TYPE CUL_HM
lastMsg No:50 - t:41 s:1DCAE1 d:133AC7 01500E40
nanoCUL868_MSGCNT 121
nanoCUL868_RAWMSG A0D50A6411DCAE1133AC701500E40::-72.5:nanoCUL868
nanoCUL868_RSSI -72.5
nanoCUL868_TIME 2018-08-31 07:40:54
protCmdPend 3 CMDs_pending
protLastRcv 2018-08-31 07:40:54
protRcv 47 last_at:2018-08-31 07:40:54
protSnd 8 last_at:2018-08-31 07:40:54
protState CMDs_pending
rssi_at_nanoCUL868 cnt:121 min:-89.5 max:-70 avg:-75.31 lst:-72.5
READINGS:
2017-12-27 16:40:33 D-firmware 1.2
2017-12-27 16:40:33 D-serialNr JEQ0459365
2018-08-31 07:40:54 battery ok
2018-08-31 07:40:54 brightness 14
2018-07-31 16:34:49 cover closed
2018-08-31 07:41:11 motion off
2018-08-31 07:40:54 motionCount 80_next:15s
2018-08-31 07:41:11 motionDuration 17
2018-07-31 16:34:49 powerOn 2018-07-31 16:34:49
2018-07-31 16:34:49 recentStateType info
2018-08-31 07:41:11 state noMotion
2018-08-31 07:40:54 trigDst_133AC7 noConfig
2018-08-31 07:40:54 trigger_cnt 80
cmdStack:
++A001133AC71DCAE100040000000000
++A001133AC71DCAE101040000000001
++A001133AC71DCAE10103
helper:
HM_CMDNR 80
getCfgList all
getCfgListNo ,4
mId 004F
regLst ,0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +1DCAE1,02,00,00
nextSend 1535694054.2441
prefIO
rxt 2
vccu
p:
1DCAE1
00
00
00
mRssi:
mNo 50
io:
nanoCUL868:
-70.5
-70.5
prt:
bErr 0
sProc 2
sleeping 1
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO nanoCUL868
flg A
ts 1535694054.14582
ack:
HASH(0x1646380)
508002133AC71DCAE101010E00
rssi:
at_nanoCUL868:
avg -75.3140495867769
cnt 121
lst -72.5
max -70
min -89.5
Attributes:
IODev nanoCUL868
autoReadReg 4_reqStatus
devStateIcon noMotion:IR@green motion:IR@red
expert 2_raw
firmware 1.2
model HM-SEN-MDIR-SM
room CUL_HM,Eingang
serialNr JEQ0459365
subType motionDetector
verbose 3
Ich werde mich in der nächsten Zeit mal tiefer in die von dir genannten Themen eingraben.
Noch mal danke und ein schönes Wochenende!
Moin berny25,
Danke für die Rückmeldung.
Wenn du eine umfassende Darstellung zu HM suchst: Anhang zum "Einsteiger-pdf"; die ist super, allerdings sehr technisch. Mir hat es geholfen, die Zusammenhänge zu erahnen (bin kein Techniker oder EDV'ler)...
Was deinen Bewegungsmelder angeht: "cmds pending" ist (wenn es nach einigerer Wartezeit nicht verschwindet) kein guter Zustand. Empfehlung für den nächsten Schritt: Werksreset am (physischen) Gerät lt. Bedienungsanleitung durchführen, "set ... clear all" am FHEM-Device machen und dann das Device neu Pairen (siehe Wiki).
Nach erneutem Warten und Browser-Refresh sollte dann ein Reading da sein, das das korrekte Pairing mit der Zentrale beinhaltet (ohne "set_...").
Ok, danke für die weiteren Infos!
Ich schau mir das die nächsten Tage an und würde mich wieder melden falls ich irgendwo nicht weiter komme.