Alternative culfw

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

Vorheriges Thema - Nächstes Thema

bjoernh

Zitat von: homeum am 22 August 2015, 11:25:45
Hallo,

habe nun meinen CUL (v3) mit a-culfw geflasht und damit auch 2 TCM97... Funksensoren über autocreate einbinden lassen, was probemlos funktioniert hat.
Die wurden automatisch als CUL_TCM97001_145 und  CUL_TCM97001_150 erzeugt.
Soweit alles gut.

Was ich nicht verstehe:
Sobald ich die Batterien entferne, wird des Sensor wieder über autocreate unter einer anderen Bezeichnung erneut angelegt, wie ein völlig neues Device und die Verbindung zum vorherigen Device (und damit allen aufgezeichneten Daten) ist hinfällig, obwohl es der gleiche Sensor ist. Dabei habe ich nichtmal die Einstellung vom Kanal geändert oder sowas, einfach nur Batterien raus und neue eingelegt.

Kann ich das irgendwie umgehen?
Hallo,

das ist leider eine Eigenheit der Sensoren. Beim Einlegen von neuen Batterien erzeugen die Sensoren immer eine neue ID. Somit werden diese dann auch neu angelegt.

Gruß
Björn

homeum

Danke für die Info.

Beim Batteriewechsel werde ich also separat 3V an den Sensor legen müssen. Solange die Batterien nicht vollständig leer sind, sollte das damit zu umgehen sein...

Gruß Gerd

bjoernh

Kannst du probieren,  allerdings würde ich niedriger gehen. Du solltest die Batterien ja nicht laden.

Gesendet von meinem LG-P880 mit Tapatalk


Ralf9

Zitat von: homeum am 22 August 2015, 12:41:11
Beim Batteriewechsel werde ich also separat 3V an den Sensor legen müssen.

Alternativ muß ich dann nach dem Batteriewechsel die per autocreate angelegten Einträge löschen und beim bestehenden define Eintrag die neue ID eintragen.

Bei meinen beiden Temperatursensoren ist mir aufgefallen, daß nur bei einem die Kanalnr angezeigt wird.
Was hat es mit der Kanalnr auf sich? Senden die Kanäle auf verschiedenen Frequenzen oder ist der Kanal nur ein Eintrag im Funktelegramm?

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

bjoernh

Die ID ist im Protokoll. Senden tun die alle auf der selben Frequenz.

Ralf9

Zitat von: bjoernh am 22 August 2015, 14:43:20
Die ID ist im Protokoll. Senden tun die alle auf der selben Frequenz.
Dann müsste ich ja auch 5-10 gleiche Temperatursensoren mit dem selben Kanal verwenden können, solange es keine doppelten device ID gibt.

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

bjoernh

Zitat von: Ralf9 am 22 August 2015, 16:44:01
Dann müsste ich ja auch 5-10 gleiche Temperatursensoren mit dem selben Kanal verwenden können, solange es keine doppelten device ID gibt.

Gruß Ralf
Klar, theoretisch schon.
Wobei jetzt weiß ich auch was Du mit Kanal meintest. Die Kanalschalter fließen natürlich schon in die ID ein. Wenn dein Sensor solche Schalter hat, dann wechselt er glaube auch nicht die ID.   

bjoernh

Zitat von: chris1284 am 06 August 2015, 13:30:20
hallo bjoern,

zur ws0002 problematik: es muss am Modul 14_CUL_TCM97001 liegen. auch mt dem signalduino als DEVIO (cul's abgestöpselt). schafft das modul max 3 sensoren zu unterscheiden.
man sieht das auch schön daran das ein sensor in fhem 40°C hat und beim nächsten update 23°C, da werden 2 reale auf ein fhemdevice "gemapped".
im gegensatz zum 14_FHEMduino_TCM.pm wird auch nicht unterschieden ob es ein auto-send oder ein manuelles senden der werte vom sensor war.

EDIT: offenbar müssen die ID's der sensoren stark von einander abweichen (da ich vom sensor gleich generierte id's einfach mal ausschließe). nimmt man bei den doppelt oder nicht erkannten sensoren die batterie solange raus bis eine id generiert wurde die das modul unterscheiden kann funktionieren alle. aufwendiger aber funktionierender workaround
habe das nun 5 mal hinterinander so gemacht (alle sensoren batterie raus und einen nach dem anderen wieder batterie rein bis er im fhem auftauchte)

Ich glaube jetzt verstehe ich was Du meinst. Wenn es zwei Sensoren mit der gleiche ID, aber verschiedene Kanäle gibt, werden diese vermischt in einem Eintrag.
So eine richtige Idee wie man das lösen kann habe ich aber noch nicht. Evtl. unter dem entsprechenden Device die Werte mit prefix 0_, 1_ usw anlegen würde gehen.

geohem

Hallo,
ich habe dieses Thema jetzt komplett durchforstet und bin nun soweit, dass ich einen Selbstbaucul mit der 433Mhz a-culfw  betreibe, um meine brennenstuhl Steckdosen zu schalten und die Signale der zugehörigen Fernbedienungen empfange. Dafür erst einmal vielen Dank. Für meine kleineren Lichtspielereien sind mir die Aktoren der Homematic Serie zu teuer.

Jetzt habe ich noch einen IT+ Temperatursensor, den ich an einem zweiten Selbstbaucul mit der 868Mhz a-culfw auslesen möchte.
Ich habe aber keinen Schimmer wie ich das anstellen soll.
Im Changelog steht "RF-Native Mode for RFM12 based protocols i.e. LaCrosse/IT+/PCA302,  ie.  use "Nr1" "
Wie bringe ich den Cul in diesen RF-Native Mode?
Fhem auf bpi2mu - Fhem Remote auf Raspberry2
hmlan - hmuartlgw - culmax -yeelightbridge-jeelink-cul

locutus

Das Kommando
set CUL raw Nr1
versetzt den CUL in den LaCrosse/IT+ Empfangsmodus.

Siehe auch: http://forum.fhem.de/index.php/topic,36565.0.html

geohem

Danke locutus für deine Antwort, das klappt leider nicht.
Ich gebe "set nanoCUL868 raw Nr1" ein und im Logfile steht: " nanoCUL868: unknown message ? (Nr1 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x"
Mit dem N fängt mein CUL scheinbar nichts an.
Fhem auf bpi2mu - Fhem Remote auf Raspberry2
hmlan - hmuartlgw - culmax -yeelightbridge-jeelink-cul

Jendaw

Hallo Björn,

Zitat von: Jendaw am 02 August 2015, 15:14:11
ich habe mehrere HomeEasy-Fenstersensoren vom Typ HE305EU (Hersteller ist Byron,  auf einem Auskleber steht auch HE852, ohne EU) und einen a-CUL v1.05.03. Soweit ich das im Thread und im git gesehen habe, gibt es eine prinzipielle Unterstützung für HE-Geräte im IT-Modul. Obiger Fensterkontakt wird leider nicht erkannt.
[...]

Siehst du eine Chance, diesen Sensor in die Firmware zu integrieren?

VG
FHEM/RaspberryMatic @RaspPi + nanoCUL 433 + Signalduino 433 + JeeLink-Clone + CC2531 + Slaesh-Stick
IT Funkschalter, HE-Sensoren, TX 29 DTH-IT, HMIP, HM-Wired, zigbee2mqtt
ESPEInk + waveshare 7.5inch_e-Paper_HAT_(B) + ESP8266 (Firmware von https://github.com/Yattien)

bjoernh

Denke das sollte möglich sein.  Ich will mir aber keinen extra kaufen.  Kommt beim raw X25 irgendwas an?  Wenn nein brauche ich so ein Teil mal Vorort. 
Grüße Björn

Jendaw

Hallo Björn,

danke für die schnelle Antwort :)

Zitat von: bjoernh am 08 September 2015, 12:12:28
Denke das sollte möglich sein.  Ich will mir aber keinen extra kaufen.  Kommt beim raw X25 irgendwas an?  Wenn nein brauche ich so ein Teil mal Vorort. 

Ja, das Log vom X25 ist im Ursprungspost zu sehen.

VG
FHEM/RaspberryMatic @RaspPi + nanoCUL 433 + Signalduino 433 + JeeLink-Clone + CC2531 + Slaesh-Stick
IT Funkschalter, HE-Sensoren, TX 29 DTH-IT, HMIP, HM-Wired, zigbee2mqtt
ESPEInk + waveshare 7.5inch_e-Paper_HAT_(B) + ESP8266 (Firmware von https://github.com/Yattien)

OliS.

Hallo, Björn!

Ich habe festgestellt, dass der Empfang meiner ITV3 Fernbedienungen extrem unzuverlässig ist. Von 20 Versuchen vielleicht einmal. Keine Ahnung, seit wann das so ist. Irgendwann muss es aber schon mal funktioniert haben, da ich ja meine ganzen V3-Geräte per autocreate angelegt habe.
Mir ist das nur gerade aufgefallen, weil ich versuche, mit einer V3 Fernbedienung andere Aktionen in FHEM zu starten. V3 klappt dagegen absolut zuverlässig.

Ich habe die aktuelle a-cul-fw auf einem selbstgebastelten nanoCUL laufen. Hier mal ein list nanoCUL:

Internals:
   CMDS       BCFiAGMKUYRTVWXefLltx
   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:CUL_RFR::CUL_TCM97001:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A96PDNBV-if00-port0@38400 1234
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A96PDNBV-if00-port0@38400
   FD         19
   FHTID      1234
   NAME       nanoCUL
   NR         433
   PARTIAL
   RAWMSG     i10101424
   RSSI       -56
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.05.04 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
   initString X21
   nanoCUL_MSGCNT 3
   nanoCUL_TIME 2015-09-08 12:16:27
   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]+
   Readings:
     2015-09-07 09:28:46   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:16dB
     2015-09-08 09:36:34   cmds             B C F i A G M K U Y R T V W X e f L l t x
     2015-09-08 12:03:01   raw             is10100100010000011010101010000001
     2015-09-08 12:16:27   state           Initialized
     2015-03-26 10:19:39   uptime          0 09:09:39
Attributes:
   icon       cul_cul
   room       Labor


Gruß
Oli
FHEM in Debian VM auf DS720+, HMLAN und HMUARTLGW, RFXTRX, Conbee II, Homebridge, Alexa
Geräte: Homematic, Tradfri, Shelly, IT, ESA2000, VU+, Denon-AVR, Sonos, Fritz!Box, Harmony Hub, IP-Cams, Roborock, Automower