IT Empfang mit CUL

Begonnen von mehf, 18 August 2013, 20:47:11

Vorheriges Thema - Nächstes Thema

KölnSolar

Zitatund sende mit IT Repetition 6 die IT Pakete.
senden kann er doch  ::) Aber die Frequenz anzupassen könnte helfen.  ;) Ist aber bei Original-IT eigentlich nicht das Problem
Auch an der Pulsweite könnte man noch feilen. Mir sieht das vermeintlich vom PIR emfangene etwas komisch aus.
Zitat2017.03.17 12:08:29 2: CUL1: unknown message p 7  304 1136 1040  416  304 1136  24  1  3 0   288  9888     0 03 041015
2017.03.17 12:08:29 4: CUL_Parse: CUL1 p 7  304 1136 1040  416  320 1136  24  1  3 0   288  9968     0 03 041015
Ich hab meinen 433 leider verliehen, dass ich es nicht prüfen kann, aber Pulsweiten 304 1136 1040  416   passen irgendwie nicht. Muss doch eher so ähnlich wie 400 1200 1200 400 sein. Poste das Log nochmal bei Betätigen der ITZ. Über Batterien haben wir auch noch nicht gesprochen. Aber ich hoffe doch, dass die frisch sind  ::)
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

Hasi32

Klingt jetzt blöd, aber es funktioniert wieder alles. Frei nach dem Motto: "Ein Reboot tut immer gut" habe ich den Raspi neu gestartet und schon funktionierte es. Aber auch das ist nicht nachvollziehbar, da ich das schon getestet hatte.
Das Fragezeichen über meinem Kopf ist inzwischen größer als ich und blinkt in bunten Farben.

Aber hier mal ein paar Antworten:
- VERSION - V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) CUL433 (F-Band: 433MHz)

- Der CUL ist der aktuelle, von Busware vor ein paar Tagen geliefert

- Der Download der Firmware erfolgte über den mediafire-link hier im Forum, vorher war eine 1.66 drauf mit dfu-programmer geflasht, Links auch hier aus dem Forum

- Mein Raspi ist eine 3B V1.2 mit Jessie auf dem neuesten Stand (Linux version 4.4.48-v7+)

Kann ich hier Bilder direkt posten, oder muss ich die irgendwo anders ablegen und hier verlinken? Wobei ich denke, dass die obigen Antworten eigentlich reichen sollten.

Übrigens funktioniert es gerade mal wieder nicht, die ITZ-500 (V1) wird als 

2017-03-18 16:12:16 CUL CUL1 UNKNOWNCODE i040114

empfangen. Ein "shutdown restart" hat nicht geholfen. Ein Reboot per Putty (eben gerade ausgeführt) führt dazu, das er die ITZ gar nicht mehr erkennt (Verbose immer global 4).
Also mache ich ein "raw X25" und er bringt denselben Output wie im ersten Post:
Zitat2017-03-18 16:18:03 CUL CUL1 UNKNOWNCODE i040114
2017-03-18 16:18:03 CUL CUL1 UNKNOWNCODE p 7  320 1104 1040  400  288 1168  24  1  3 0   304  9904     0 02 040114

Also nochmal "dann versuchs mal über die Parameter des CULs bwidth 464, rAmpl 42, sense 8 ..." und schon erkennt mein CUL gar nichts mehr, auch nicht per X25.

Das ist schon ein wenig komisch ...

Grüße
Mathias

Hasi32

Nachtrag

Was hilft ist folgendes:

Ehefrau den Einkauf reintragen und dann einen "set CUL raw e" absetzen. Und schon erkennt fhem wieder die ITZ und autocreate legt das Device an.

Verwirrte Grüße
Mathias

bjoernh

Lösch doch mal die Dose und lass sie neu anlegen. Vielleicht stimmt nur der on/off code nicht.

Gesendet von meinem Mobile Device.


RaspiLED

Hi,
Ich glaube hier braucht ein Firmware Profi den Dump der Register und Detailfotos vom neuen Busware CUL. Welche Version genau? Hat die schon wer anders aktiv in Verwendung?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Hasi32

#800
Also wie man einen Dump der Register macht weiß ich nicht, aber hier mal ein Bild. Falls die Details nicht ausreichen hätte ich das auch noch in GROSS, aber ich dachte ich haue hier mal nicht so ein MB-Monster rein  :o

Da der Raspi eigentlich noch im Testbetrieb läuft, wird abends auch mal "Kodi" gestartet für ein wenig Kurzweil. Danach wird aber immer ein Neustart gemacht und ich hatte den Raspi auch schon zwischendurch komplett runtergefahren und es lief auch nicht. Abgesehen davon muss so ein System einen Neustart oder einen Stromausfall aushalten, denke ich zumindest.

Grüße und einen schönen Samstag Abend
Mathias

RaspiLED

Hi, hat diesen Busware CUL V3.4 jemand ohne das Problem im Einsatz?

Bzgl. register auslesen:
get <name> raw C99
Aber zur Interpretation brauchen wir jemanden mit Erfahrung!
(Vgl. http://culfw.de/commandref.html#CUL
get raw ...
C<reg>
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.
Example: C35 -> C35 = 0x0D / 13

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

KölnSolar

#802
nana Arnd,
da wollen mir mal nicht übertreiben. Das Problem sitzt sicherlich eher vorm Bildschirm als bei busware, oder der aculfw, denn die spiegelt sich in den Registern wieder.
Mathias, bitte mal stromlos machen, neu booten und dann die 3 Parameter ändern. Dann wieder stromlos und reboot. Dann ein ccconf um zu prüfen, ob die Parameter unverändert geblieben sind. Und danach erst einmal Finger weg von ALLEN CUL-Kommandos. Ein list(und wirklich den Befehl list)des CUL, des PIR1000 und ein device der ITZ hier einstellen.
Der CUL steckt direkt am Rpi oder mit Adapter oder Hub dazwischen ?
edit: und bitte die lists in code-tags(s.o. Symbol #)
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

Hasi32

Einen wunderschönen alle zusammen ...

Neuer Tag, neues Glück. Nach Neustart gestern abend um aus Kodi raus und in den normalen Desktop zu kommen, bietet sich folgendes Bild:

ITZ-500 Device wird sofort erkannt und angelegt, ein gestern angelegtes ist noch vorhanden. Ich lösche beide Device und versuche es nochmal und es wird wieder:

Zitat2017-03-19 13:21:25 CUL CUL1 UNKNOWNCODE i044115
.

Leider habe ich vorher kein "list" des ITZ-Device gemacht. Hier aber die vom Pir und vom Cul:

PIR:
Internals:
   00         0
   CUL1_MSGCNT 3
   CUL1_RAWMSG i5a9995aa56669596
   CUL1_RSSI  -89
   CUL1_TIME  2017-03-18 23:44:32
   DEF        00111010100011110001010110 0 1001
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     3
   NAME       IT_V3_1d478ac9
   NR         206
   STATE      off
   TYPE       IT
   XMIT       0011101010001111000101011001001
   XMITdimdown 00
   XMITdimup  00
   XMITon     1
   Code:
     1          0011101010001111000101011001001
   Readings:
     2017-03-17 11:43:16   group           0
     2017-03-17 11:43:16   protocol        V3
     2017-03-18 23:44:32   state           off
     2017-03-17 11:43:16   unit            1001
Attributes:
   IODev      CUL1
   room       Innen


Und vom CUL:
Internals:
   CMDS       ABCEeFGhiKkLlMmRTtUuVWXxY
   CUL1_MSGCNT 4666
   CUL1_TIME  2017-03-19 13:23:25
   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:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/ttyACM0@38400 1234
   DeviceName /dev/ttyACM0@38400
   FD         11
   FHTID      1234
   NAME       CUL1
   NR         26
   PARTIAL
   RAWMSG     s6D8065DDF8F2;  512: 9072
   RSSI       -73
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) CUL433 (F-Band: 433MHz)
   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....(1|5|9).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 ^\*
   Readings:
     2017-03-17 14:30:14   ccconf          freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:8dB
     2017-03-18 23:19:41   cmds             A B C E e F G h i K k L l M m R T t U u V W X x Y
     2017-03-16 11:36:49   credit10ms      900
     2017-03-19 13:13:18   raw             is00F0000F0FF0
     2017-03-19 13:23:25   state           Initialized
     2017-03-16 15:24:53   uptime          0 00:02:13
     2017-03-16 18:28:07   version         V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) CUL433 (F-Band: 433MHz)
Attributes:


Soll ich jetzt tatsächlich nochmal Bandwith, Ampl. und Sense setten? Die Werte stehen doch schon drin.

Ich lass jetzt mal die Finger vom CUL und warte auf Antwort, aber scheinbar gibt es ja einen Zustand, den man mit Neustart + "raw e" herstellen kann, dass er Devices erkennt und danach erkennt er auch alle weiteren im IT V1. Das wiederum scheint mir aber die Theorie zumindest in diesem Fall zu widerlegen, dass das Problem vor dem Bildschirm sitzt.

Grüße
Mathias

Hasi32

Nachtrag:

Möglicherweise hat das Problem vor dem Bildschirm das Problem hinter dem Bildschirm gefunden. FHEM erkennt das ITZ-Device immer noch, solange es ein Device mit einer Nummer (1-16) <=8 (FFF0 in den Stellen 5-8) oder >=11 (0F0F) ist.

Nö, da weigere ich mich jetzt einfach mal zu glauben, dass dieses Problem vor dem Bildschirm sitzt  ;)

Hier nochmal ein "list" des Device mit der Nummer 8:

Internals:
   00         f0
   CFGFN
   DEF        00F0FFF00F FF F0
   IODev      CUL1
   NAME       IT_00F0FFF00F
   NR         349
   STATE      ???
   TYPE       IT
   XMIT       00f0fff00f
   XMITdimdown 00
   XMITdimup  00
   XMITon     ff
   Code:
     1          00f0fff00f
   Readings:
     2017-03-19 13:41:51   protocol        V1
Attributes:
   IODev      CUL1
   room       IT


Und die Nummer 11:

Internals:
   00         f0
   CFGFN
   DEF        00F00F0F0F FF F0
   IODev      CUL1
   NAME       IT_00F00F0F0F
   NR         355
   STATE      ???
   TYPE       IT
   XMIT       00f00f0f0f
   XMITdimdown 00
   XMITdimup  00
   XMITon     ff
   Code:
     1          00f00f0f0f
   Readings:
     2017-03-19 13:43:05   protocol        V1
Attributes:
   IODev      CUL1
   room       IT


Vielleicht sollte ich noch erwähnen, dass ich in meine bisherigen Versuchen nicht so auf die Devicenummer geachtet habe. Bis zur Nr. 7 ist bei mir alles belegt und ich habe immer mit Device 8-10 gearbeitet. Das erklärt manches bisher unerklärbare.

Grüße
Mathias

KölnSolar

2 Dinge auf die Schnelle:
Das was Du beim CUL siehst, wird nur aktualisiert, wenn Du get ccconf machst ! Sollte danach noch alles wie zuvor sein --> Finger weg vom CUL
0F0F(4-7 bei zählweise mit 0 beginnend), also die vermeintliche 11, ist eine 5 und die vermeintliche 8(FFF0) eine 14. Gerät vielleicht da etwas bei Dir durcheinander ?
Nochmal IT-Klartext: 0-3 = Buchstabe, 4-7 = Ziffer, 8-9 = fix 0F und 10-11 0F/F0 für on/off.
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

Hasi32

#806
Ich meinte natürlich die Stellen 4-7. Aber das ist auch nicht das Problem. Es funktionieren nämlich auch meine ehemlige 8 und die 11 nicht mehr, wenn ich sie einmal aus der fhem.cfg gelöscht habe. Dabei ist es egal, ob ich die Devices per Befehl oder delete-anklicken lösche oder ob ich sie einfach im Editor aus dem .cfg File schmeiße.

Ich denke nicht mehr, dass das etwas mit dem CUL zu tun hat.

Grüße
Mathias

KölnSolar

#807
mir war noch aufgefallen, dass Deine RSSIs ziemlich schlecht waren !!! Was ist denn mit der Antenne ?
edit: und fhem.cfg editieren  :o machen wir nicht. Nicht, dass da was in der Reihenfolge durcheinander ist ?
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

Hasi32

Da ist eine gewinkelte kurze Stabantenne dran (ich glaube +3dbi) und der Standort ist suboptimal. Das ist aber auch nicht das Problem. Nach einem "shutdown restart" erkennt FHEM die Devices wieder.

Ich fasse mal zusammen, da hier ja einiges durcheinander ging:

- bWidth:464KHz rAmpl:42dB sens:8dB sind die Lösung des Problems, dass der CUL die Intertechno-Protokolle gar nicht erkennt.

- Löscht man ein so erkanntes Device, wird es nicht erneut erkannt, bis man einen "shutdown restart" gemacht hat. Ich kann gerne weiter testen, z.B. wie sich ein kompletter Neustart des Raspis auswirkt etc.

Ob der Fehler (wenn man ihn so nennen will) nun bei der a-culwf oder beim FHEM liegt müssen andere entscheiden, ich helfe aber gerne mit und teste, sofern gewünscht.

Warum soll ich nicht in der fhem.cfg editieren? Solange meine Reihenfolge halbwegs logisch ist ist doch alles OK. FHEM selber setzt soch auch einfach (fast) alles hintereinander, wie es gerade kommt. Beim Programmieren muss ich ja auch bestimmte Vorgaben einhalten, was die Reihenfolge angeht.

Also bisher hat das alles sehr gut geklappt und meine ITs und Somfys machen genau das, was sie sollen. Im nächsten Schritt will ich Sensor und Aktor trennen (z.B. PIR mit anderem Hauscode als die Schalter), um bestimmte Szenarien aufzubauen, die dann automatisch ablaufen. Dazu wollte ich eben Empfang und Erkennung der Protokolle.

Grüße
Mathias

KölnSolar

ZitatWarum soll ich nicht in der fhem.cfg editieren?
Das ist Forums-Philosophie.
ZitatSolange meine Reihenfolge halbwegs logisch ist ist doch alles OK.
wenn es nicht nur halbwegs ist  ;) Gibt halt schon nicht zu unterschätzende Abhängigkeiten. Und so
ZitatFHEM selber setzt soch auch einfach (fast) alles hintereinander, wie es gerade kommt
ist es nicht richtig.

Ich würd auf jeden Fall nochmal mit ner leeren cfg arbeiten und mal nicht selber editieren. Und schließlich könntest Du die culfw 1.67(bzgl. IT V1 idntisch der aculfw) mal probieren, obwohl ich da eher nicht die Ursache vermute.

ZitatbWidth:464KHz rAmpl:42dB sens:8dB sind die Lösung des Problems, dass der CUL die Intertechno-Protokolle gar nicht erkennt.
wobei das ähnlich dem RSSI eher auf Reichweitenprobleme deutet.
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