Hauptmenü

culfw@ARM

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

Vorheriges Thema - Nächstes Thema

toxic-tonic

#915
Hi,

da ich ziemlich viel Stress hatte das zusätzliche Interface an den Cube zu bekommen hier mal die Schaltung für einen E07-M1101D-TH:

Pin  - CC   -  Cube
1    -  GND  -  GND
2    -  VCC  -  VCC
3    -  GDO0 -  PB25
4    -  CSN  -  PA6
5    -  SCK  -  SCK
6    -  MOSI -  MOSI
7    -  MISO -  MISO
8    -  GDO2 -  PA5


Voraussetzung ist dieser Patch: https://loetzimmer.de//patches/cube.patch um die PINs richtig zuzuordnen!

Gruß

Tobias

toxic-tonic

#916
Moin,

Eine Frage: kann es sein, dass das zusätzliche Modul (CubeX4)  keine Signale empfangen kann? Ich habe den Cube als cul_max konfiguriert und benutze das zweite Modul als Intertechno-Sender. Mit dem alten Cul habe ich auch Schalter von Intertechno empfangen, jetzt kommt nichts mehr an.

Generell ein Problem des cubex4 oder kann ich da was dran machen?

Danke und Gruß

Tobias

Telekatz

Beim CUBEx4 funktioniert SlowRF ohne Einschränkungen auch beim zweiten Transceiver.

toxic-tonic

Moin,

habe es jetzt noch mal näher eruiert. Denke das Problem ist die Konfiguration als MAX-Device. meine config sieht so aus:

define cun01 CUL x.x.x.x:2323 xxxx
attr cun01 rfmode MAX
attr cun01 room Z_-_System
define cun01_max CUL_MAX xxxxxx
attr cun01_max IODev cun01
attr cun01_max room Z_-_System

define cun02 STACKABLE_CC cun01
attr cun02 room Z_-_System


Wenn ich den MAX-Teil rausnehme kann ich die IT-Sachen empfangen. Wahrscheinlich wird durch diese Konfiguration das erste Interface auf "lauschend" gestellt und das zweite kommt dann nicht mehr zum Zug? Oder mach die Konfiguration als "Stackable" vielleicht noch einen unterschied?

Danke und Gruß

Tobias

Telekatz

An der a-culfw sollte es nicht liegen, die kann gleichzeitig MAX und IT empfangen:

Z170000000FEF74123456001004024C4551303739343539324D
*i001151F9
*i00155FFB
Z0B0106300FEF7412345600103D
Z170000000FEF74123456001004024C45513037393435393237
Z0B0106300FEF7412345600123D
Z0B0106300FEF74123456001229
*s52800660F9;  464: 9520
*i00145101
*i00155F03
Z0B0106300FEF7412345600124E
Z0B0206300FEF74123456001038
Z0B0206300FEF7412345600102F
Z0B0206300FEF74123456001016
*s52800660FE;  480: 9520
Z0B0206300FEF74123456001018
Z0B0206300FEF7412345600502C
*s52800660FD;  464: 9552


Versuch mal den zweiten Transceiver räumlich etwas anders anzuordnen. Ich hatte mal das Problem, das mehrere nur auf Empfang geschaltete Transceiver sich trotzdem gestört hatten.

toxic-tonic

Hi,

Habs auch rausbekommen, musste noch den SlowRF als rfmode setzen:

define cun02 STACKABLE_CC cun01
attr cun02 rfmode SlowRF
attr cun02 room Z_-_System


Danke und Gruß

Tobias

DJNoXD

Hallo

Erst einmal Danke für diese tolle Firmware. :-)


Wir ihr euch schon denken könnt, habe ich eine Frage, bei der ich eure Unterstützung benötige.

Folgendes (aus meiner Sicht seltsames) Verhalten tritt bei mir auf.

Ich habe meinen Cube um einen CC1101 erweitert (868MHz), welcher auch funktioniert.
Nach meiner Recherche handelt es sich um ein echtes 86MHz Modul. (https://www.ebay.de/itm/CC1101-868-MHz-Modul-FHEM-CUL-Transciever-Wireless-Funk-Arduino-Raspberry-Pi/183119455997?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649)
Mein Problem ist, dass der neue CC mit 433 MHz erkannt wird.
Ich ändere die Konfiguration dann auf 868MHz und alles funktioniert einwandfrei mit guten Empfang.

Nach einer gewissen Zeit "vergisst" das Modul dann leider die Konfiguration und es funktioniert erst dann wieder, wenn sie wieder angepasst habe.

Hier meine Konfiguration aus der fhem.cfg:

define CUL0 CUL 192.168.0.94:2323 0000
attr CUL0 icon cul_868
attr CUL0 rfmode MAX
attr CUL0 room System,RF
attr CUL0 verbose 0

define CUL1 STACKABLE_CC CUL0
attr CUL1 connectCommand Nr1
attr CUL1 icon cul_868
attr CUL1 rfmode SlowRF
attr CUL1 room System,RF
attr CUL1 verbose 0

define CULMAX0 CUL_MAX 123456
attr CULMAX0 IODev CUL0
attr CULMAX0 room System,RF


Auszug aus dem Log des CUBEs, wenn er erpfängt:

*N0195C3723701AAAA0000943243
H431780280055FF
*N0191D8167D03DE716B676BD0D9
H434701160400FF


Hier die Ausgaben der Module:
CUL0 (orginal Cube Modul):
Internals:

CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz*
CUL0_MSGCNT 1728
CUL0_TIME 2018-03-19 08:55:01
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.0.94:2323 0000
DeviceName 192.168.0.94:2323
FD 10
FHTID 0000
NAME CUL0
NR 52
PARTIAL
RAWMSG H432C00790142FF
RSSI -74.5
STACKED CUL1
STATE Initialized
TYPE CUL
VERSION V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
initString X21 Zr Za123456 Zw111111


Readings:

ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB 2018-03-19 08:58:44
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 * 2018-03-19 08:58:47
credit10ms 3106 2018-03-19 08:59:02
fhtbuf AE 2018-03-19 08:59:00
raw No answer 2018-03-17 00:39:27
state Initialized 2018-03-19 08:58:41
uptime 0 00:21:36 2018-03-19 08:58:52
version V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz) 2018-03-19 08:58:55


CUL1 (ergännztes Modul):
Internals:

CMDS bCFiAZNEGMKLUYRTVWXfz
CUL1_MSGCNT 1123
CUL1_TIME 2018-03-19 09:03:00
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 CUL0
IODev CUL0
NAME CUL1
NOTIFYDEV CUL0
NR 54
NTFY_ORDER 50-CUL1
PARTIAL
RAWMSG N0191D8427D676408B23AFFA89A
RSSI -74.5
STATE Initialized
StackLevel 1
TYPE STACKABLE_CC
VERSION V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
initString X21


Readings:

ccconf freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB 2018-03-19 09:05:24
cmds b C F i A Z N E G M K L U Y R T V W X f z 2018-03-19 09:05:29
credit10ms 3496 2018-03-19 09:05:32
fhtbuf AE 2018-03-19 09:05:35
raw ? ( is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z 2018-03-17 21:18:53
state Initialized 2018-03-19 09:05:42
uptime No answer 2018-03-19 09:05:45
version V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz) 2018-03-19 09:05:45


Die Firmware habe ich selbst kompiliert, da ich das die Konfiguration der Pins angepasst habe und die LaCross Unterstützung aktiviert habe.
Meine Änderungen könnt ihr hier sehen:
https://github.com/DJNoXD/a-culfw/commits/master


Wie kann ich herausbekommen, woher der Fehler kommt?
Ist mein Module evtl. defekt?

Vielen Dank für eure Hilfe.
Randolf

RaspiLED

Hi,
Probiere mal ein Werksreset
set CUL0 raw e
Ist dann der CUL1 wieder auf 433?
Ich schätze irgendwie wird der resetet.

Du könntest entweder in Deiner Firmware beim init die Freq/Mode setzen oder Du machst ein regelmäßiges get CUL1 config und setzt dann mit DoIf/ Notify die Werte...

Gruß Arnd



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

Telekatz

Zitat von: DJNoXD am 19 März 2018, 09:16:08
Ich habe meinen Cube um einen CC1101 erweitert (868MHz), welcher auch funktioniert.
Nach meiner Recherche handelt es sich um ein echtes 86MHz Modul. (https://www.ebay.de/itm/CC1101-868-MHz-Modul-FHEM-CUL-Transciever-Wireless-Funk-Arduino-Raspberry-Pi/183119455997?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649)
Mein Problem ist, dass der neue CC mit 433 MHz erkannt wird.
Der Cube kann gar nicht erkennen, ob ein 433MHz oder ein 868MHz Modul angeschlossen ist. Für den zweiten Port ist 433 der Standardwert, der nach einem Reset des Dataflash geladen wird.

Nimm einfach den CUL0 für SlowRF und CUL1 für MAX. Der MAX Mode stellt automatisch die richtige Frequenz ein, unabhängig von Standardwert.

DJNoXD

#924
Danke für eure Hilfe.

Ich habe die Reihenfolge geändert.
CUL0 = SlowRF
CUL1 = MAX

Ich melde mich wieder, sobald ich etwas sagen kann.

DJNoXD

#925
Aktuell sieht es gut aus.
Beide CULs können senden und empfangen.

Danke :-)


Evtl. habt ihr noch einen weiteren Tipp für mich.
Aktuell habe ich einen CUBe mit der eq3 Firmware laufen und einen CUBe als CUL.
Ein Thermostat habe ich mit dem CUL gepaired und kann es steuern.
Seltsam ist (für mich) das folgende Verhalten:
Ich setzte den gewünschten Temperatur Wert auf z.B. 21°C.
Der Wert wird erfolgreich an das Thermostat übertragen (durch ablesen am Thermostat überprüft).
Nach einer bestimmten Zeit wird der Wert, ohne das ich etwas gemacht habe, auf ON gesetzt.

Was könnte der Grund hierfür sein?
Liegt das evtl. am Dual-Betrieb?

daredevil.2k

Hallo!

Ich habe meinen Cube entsprechend der Anleitung geflashed (aktuell auf dem Stand 1.26.02 Build 276) und habe für ein paar Tage erfolgreich damit arbeiten können. Nun ist der Cube nach einiger Zeit nicht mehr erreichbar und verliert seine Konfigurationsparameter für IP, Netzmask, Gateway usw. Hat jemand selbiges beobachtet oder eine Idee, was da vor sich geht?

RalfRog

#927
Hallo daredevil.2k

Bisher habe ich die kompilierte Firmware von mediafire.com (by Bjoern Hempel) benutzt.

Mein Cube mit V1.21.00a war alle paar Monate mal nicht erreichbar. Es war immer etwas schwierg ihn wieder an LAN zu bekommen. Einfach die Spannungsversorung aus/an hat oft nicht gereicht. Mehrfaches wiederholen oder auch mal LAN ziehen brachte irgendwann den Erfolg.

Hatte dann letzte Woche die Idee auf V1.26.02abuild_276 zu gehen und hoffte auf Besserung. Das war irgendwie instabil. Inbesondere nach SET/GET Kommandos konnte ich keine IT Geräte mehr schalten. Das lief erst nach set <Cube-device> reopen wieder.

Bin daher ohne weitere Untersuchung auf die V1.24.02a_build_209. Das lief zufriedenstellend.

Habe nun meinen Cube mit einem weiteren Sender ausgestattet. Musste daher wieder auf V1.26.02abuild_276 CUBEx4_BL.bin

Die Einrichtung soweit abgeschlossen. Morgen gehe ich produktiv und werde mal zum LAN Thema berichten.
Siehe auch nächter Beitrag
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

RalfRog

Hallo in die Runde

Setze den Cube ein um abgsetzt per LAN noch Intertechno Steckdosen erreichen zu können. Nun brauchte ich die Erweiterung um noch ein HM Device abgesetzt zu erreichen.

Ich habe meinen Cube daher um einen 433MHZ CC1100 erweitert. Danke also schon mal an Euch für die tolle Arbeit, dass das möglich ist.
Als letzte Sichterheit zum "Löten" war der Hinweis #915 von toxic-tonic für die Zuordnung der In-/Out-Pins CC110 - Cube super wichtig.
https://forum.fhem.de/index.php/topic,38404.msg757526.html#msg757526

CC1100 - Cube (mit board.h Patch)
GND    - GND
VCC    - VCC
GDO0   - PB25
CSN    - PA6
SCK    - SCK
MOSI   - MOSI
MISO   - MISO
GDO2   - PA5


Ich habe um die kompilierte FW verwenden zu können mit den Originalzuordnungen gearbeitet, also PB28 auf GD00.

Daher ein Vorschlag zum leichten Nachbau hinsichtlich der Zuordnung:
- wie in der Original FW in der board.h für die Out-/ In-Pins einen Kommentar auf GD00 (=PB28) und GD02 (=PA5) einfügen
- die anderen PINs sind ja durch ihre Bezeichnung bzw. das Foto klar (Antwort #823)

Abschließen noch eine Frage. Hat es eine "Beudeutung", dass die kompilierte FW vom mediafire.com Build 276
a-culfw_1.26.02_build_276.zip heisst
aber die Versionsabfrage liefert Build 275:
- 1.26.02 a-culfw Build: 275 (2018-02-07_20-27-53) CUBEx4_83 (F-Band: 868MHz) oder
- 1.26.02 a-culfw Build: 275 (2018-02-07_20-27-53) CUBEx4_83 (F-Band: 433MHz)

Gruß Ralf
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

phantom

#929
Hi,
ich habe meinen MAX!Cube mit einem 1-Wire Transceiver DS2482S-100 erweitert. Den kann man per I2C direkt am CUBe anschließen (TWI/TWCK).
Um den 1-wire Bus via OWX anzusprechen musste ich noch einen kleinen Patch in 00_OWX.pm einfügen.

in Zeile 193 der aktuellen Version 16437 von  pah  https://forum.fhem.de/index.php/topic,85924.msg783211.html#msg783211  ist noch zusätzlich CUBE als weiteres zulässiges Device eingetragen:
}elsif( $defs{$dev} && $defs{$dev}->{VERSION}  && $defs{$dev}->{VERSION} =~ m/CSM|CUNO|CUBE|MapleCUN...(4|5|6|7|C|D|E|F)/ ){

Man könnte auch CUBEx4 eintragen, da dies ohnehin nur bei einem erweiterten CUBe relevant ist (hier mein aktueller Version-String dazu):
VERSION      V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_C3 (F-Band: 868MHz)

Evtl. könnte dies jemand kurz prüfen.
Unklar ist mir noch was dazu in den Folgemodulen wie 11_OWX_CCC etc. zu ändern ist ...

Gruß Phantom