Hauptmenü

culfw@ARM

Begonnen von Telekatz, 22 Juni 2015, 22:42:29

Vorheriges Thema - Nächstes Thema

RalfRog

Ehrlich:
k. A. zu lange her. Evtl. wg. dem Chip CC1100.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

birdy

#1201
Ich habe meinen MAX! Cube nun mit der Firmware-culfw_1.26.08_build_324 geflashed.
Nach dem Flashen der bootloader_CUBE.bin habe ich die CUBE_BL.bin in das bereit gestellte USB Laufwerk kopiert. Ich hoffe das war die richtige Datei?

Auch habe ich einen CUN  mit rfmode = MAX definiert. Aber jetzt weiss ich nicht mehr weiter 
Ich denke nun müsste man den CUL_ MAX definieren, gem. commandref   
define <name> CUL_MAX <addr>Aber woher weiss ich die addr?

Im Logfile erscheint unzählige male
CM_Parse, no matching CUL_MAX device found
FHEM  @Debian bullseye @Proxmox VE 8.2.2
GMKtec mit AMD Ryzen 7 5700U
CUL 433(a-culfw), CUL 868(SlowRF), Max-Cube CUN geflash, HM-CFG-USB-2 (HMALND)

RalfRog

Im Prinzip ja,
wegen der CUBE_BL.bin/CUBEx4_BL.bin kannst du in dem Bereich mal lesen  https://forum.fhem.de/index.php?topic=38404.msg655022#msg655022

Einen CUN habe ich ebenfalls wegen der LAN-Anbindung definiert.
Ich nutze die beiden Sender für "Homematic rfmode=HomeMatic" und "433Mhz Steckdosen rfmode=SlowRF".

Wenn ich das auf den MAX! übertrage müsstest du den 866er Sender auf rfmode = MAX stellen und dann wie ein MAX!-IO handeln. Dazu weiss ich aber nichts.
Ein "define <name> CUL_MAX <addr>" würde ja nur einen neuen separaten MAX-Cul erzeugen.

FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

birdy

Der Cun ist nach dem flashen wie folgt definiert
Internals:
   CFGFN     
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz
   CULmax_MSGCNT 32
   CULmax_RAWMSG Z0E5D02020D065A11EB4A0001190026
   CULmax_RSSI -53.5
   CULmax_TIME 2023-05-01 22:42:51
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        10.10.10.16:2323 0000
   DeviceName 10.10.10.16:2323
   FD         88
   FHTID      0000
   FUUID      64502378-f33f-f4b3-4c5b-fa141588ecfb6dc2
   LASTInputDev CULmax
   MSGCNT     16
   NAME       CULmax
   NR         1674
   PARTIAL   
   RAWMSG     Z0E5D02020D065A11EB4A000119002629
   RSSI       -53.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
   devioNoSTATE 1
   eventCount 3
   initString X21
Zr
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2023-05-01 22:39:21   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
     2023-05-01 22:42:51   state           Initialized
Attributes:
   rfmode     MAX
   room       CUL

das verursacht dann
...................
2023.05.01 22:44:56 2: CM_Parse, no matching CUL_MAX device found
2023.05.01 22:44:56 2: CM_Parse, no matching CUL_MAX device found
2023.05.01 22:44:59 2: CM_Parse, no matching CUL_MAX device found
...................

FHEM  @Debian bullseye @Proxmox VE 8.2.2
GMKtec mit AMD Ryzen 7 5700U
CUL 433(a-culfw), CUL 868(SlowRF), Max-Cube CUN geflash, HM-CFG-USB-2 (HMALND)

Telekatz

Hast du autocreate aktiviert?

birdy

Ja eigentlich schon,
Jetzt scheint der autocreate funktioniert zu haben, nach etwa dem 10. Mal definieren, löschen, neu definieren usw...
Na ja, man kann nicht immer alles verstehen.  
FHEM  @Debian bullseye @Proxmox VE 8.2.2
GMKtec mit AMD Ryzen 7 5700U
CUL 433(a-culfw), CUL 868(SlowRF), Max-Cube CUN geflash, HM-CFG-USB-2 (HMALND)

RappaSan

#1206
Hoffentlich liest hier noch jemand ab und zu mit.

Ich habe versucht, eine angepasste Version auf einem Pi3 mit Debian buster zu kompilieren.
Das ist auch nach einigem hin und her ohne Fehlermeldung und Abbruch gelungen, aber wenn ich die erzeugte CUBE_BL.bin auf den Cube kopiere, funktioniert er nicht mehr.
Nachdem ich die "alte" CUBE_BL.bin wieder drauf kopiere, ist alles wieder OK.
Funktioniert der compile-Prozess auf dem Pi3 Debian nicht richtig?

Hat sich erledigt, es gibt eine angepasste Version: a-culfw-bugfix-Fix-linker-script-for-CUBe-device

pipp37

Hallo.
Nachdem FHEM das Neustarten meiner gelflashten Maxcubes mit a-culfw nicht mitbekam, habe ich dafür ein AT gemacht erstellt, welches die Zeit des internen Readings prüft und ein REOPEN macht, wenn sich das Reading nicht verändert hat.

Vielleicht hilft das ja einigen.

https://forum.fhem.de/index.php?topic=129073.msg1313338#msg1313338

Gruss Armin
Vmware-ESX-VM-Ubuntu 16.04 Docker Main-FHEM -> Raspberry Pi-B ser2net
HMLAN mit HomeMatic, Busware SCC433 stacked SCC868 (culfw), Jeelink, MAX Heizkörperthermostate, Enigma2 (Vudo2/DM800SE), Philips 55" Ambilight PHTV - WMBUS EnergyCam+Engelmann FAW, Intertechno-Komponenten, Ubiquiti mPower