Selbstbau CUN (MapleCUN)

[dmq]

Ist mir auch schon aufgefallen... RSSI von -74,5 habe ich auch für alle meine LaCrosse Sensoren?! Egal ob neben der Antenne oder draußen im Garten.

Danke - ich vermute die Frage ist dann leider wahrscheinlich auch in den Threads der einzelnen Gerätetypen/Sketches besser aufgehoben oder ggf. in den Quellcode gucken "lacrosse.c". Die 74.5 sind mir suspekt. Auf meinem Jeelink (+ TX29 IT) bekomme ich auch keine RSSI Werte, da der RFM12 das wohl nicht anbietet. Ich empfange grundsätzlich auch alle geplanten Sender, die ich mit dem Jeelink auch empfange. Also bin ich zufrieden. Ich hätte es halt nur gerne verstanden.

 

[gloob]

Hat schonmal jemand von euch ein HM-MOD-RPI-PCB Modul an der Platine von Ranseyer zum laufen bekommen? Hab jetzt das Modul aufgelötet. Alle Verbindungen haben Kontakt zu den STM32 Pins und irgendwie mag das Modul in FHEM nicht.

Code Auswählen Erweitern

defmod myRemoteHmUART HMUARTLGW uart://192.168.1.153:2324
attr myRemoteHmUART room Gateways

Code Auswählen Erweitern

2019.01.17 13:30:29 1: HMUARTLGW myRemoteHmUART did not respond for the 1. time, resending
2019.01.17 13:30:32 1: HMUARTLGW myRemoteHmUART did not respond for the 2. time, resending
2019.01.17 13:30:35 1: HMUARTLGW myRemoteHmUART did not respond for the 3. time, resending
2019.01.17 13:30:38 1: HMUARTLGW myRemoteHmUART did not respond after all, reopening
2019.01.17 13:30:38 1: 192.168.1.153:2324 reappeared (myRemoteHmUART)
2019.01.17 13:30:42 1: HMUARTLGW myRemoteHmUART did not respond for the 1. time, resending
2019.01.17 13:30:45 1: HMUARTLGW myRemoteHmUART did not respond for the 2. time, resending
2019.01.17 13:30:48 1: HMUARTLGW myRemoteHmUART did not respond for the 3. time, resending
2019.01.17 13:30:51 1: HMUARTLGW myRemoteHmUART did not respond after all, reopening
2019.01.17 13:30:51 1: 192.168.1.153:2324 reappeared (myRemoteHmUART)
2019.01.17 13:30:55 1: HMUARTLGW myRemoteHmUART did not respond for the 1. time, resending
2019.01.17 13:30:58 1: HMUARTLGW myRemoteHmUART did not respond for the 2. time, resending
2019.01.17 13:31:01 1: HMUARTLGW myRemoteHmUART did not respond for the 3. time, resending
2019.01.17 13:31:04 1: HMUARTLGW myRemoteHmUART did not respond after all, reopening
2019.01.17 13:31:04 1: 192.168.1.153:2324 reappeared (myRemoteHmUART)

[Beta-User]

EDIT: Gelöscht - Hier vermutlich nicht das Problem.

[Ranseyer]

Hat schonmal jemand von euch ein HM-MOD-RPI-PCB Modul an der Platine von Ranseyer zum laufen bekommen? Hab jetzt das Modul aufgelötet. Alle Verbindungen haben Kontakt zu den STM32 Pins und irgendwie mag das Modul in FHEM nicht.

Ja das läuft. Weil ich geizig bin habe ich nur zwei HM-MOD-UART. Der, der aktuell produktiv läuft stammt von dir und ist noch immer auf der Platine die du verlötet hast...
Welche Bitrate der UART am MAPLE per Default hat weiss ich nicht. Setze doch mal bitte ein "pi" ab...

Dann die Bitrate richtig einstellen und vor allem speichern siehe: https://wiki.fhem.de/wiki/MapleCUX-Platinen#Konfiguration_f.C3.BCr_die_AddOnPlatine

[gloob]

Ja das läuft. Weil ich geizig bin habe ich nur zwei HM-MOD-UART. Der, der aktuell produktiv läuft stammt von dir und ist noch immer auf der Platine die du verlötet hast...
Welche Bitrate der UART am MAPLE per Default hat weiss ich nicht. Setze doch mal bitte ein "pi" ab...

Dann die Bitrate richtig einstellen und vor allem speichern siehe: https://wiki.fhem.de/wiki/MapleCUX-Platinen#Konfiguration_f.C3.BCr_die_AddOnPlatine

Auf die Baudrate scheint er immerhin richtig eingestellt zu sein:

Code Auswählen Erweitern

019.01.17 13:46:10 3: set MAPLECUL_21 raw pi
2019.01.17 13:46:10 5: SW: pi
2019.01.17 13:46:10 5: CUL/RAW: /0:115200
1:115200

2019.01.17 13:46:10 4: CUL_Parse: MAPLECUL_21 0 :1 15 200   

Eingebunden ist er über den Port 2324, sollte ja auch richtig sein.

Auf welchen Pins müsste ich denn beim Durchpiepsen landen?

[Ranseyer]

Kann sein... 

Oder:

Ein am UART1 angeschlossener HM-MOD-UART kann z.B. mit folgender Definition in FHEM eingebunden werden:
define myRemoteHmUART HMUARTLGW uart://192.168.42.23:2325

[gloob]

Kann sein... 

Oder:

Toll. Irgendwie war ich die ganze Zeit auf 2324 fixiert. Mit 2425 gibt es dann auch ein sinnvolles Ergebnis:

defmod myRemoteHmUART HMUARTLGW uart://192.168.1.153:2325
attr myRemoteHmUART room Gateways
attr myRemoteHmUART verbose 0

setstate myRemoteHmUART opened
setstate myRemoteHmUART 2019-01-17 13:52:31 D-HMIdOriginal 6A56C4
setstate myRemoteHmUART 2019-01-17 13:52:31 D-firmware 1.2.1 (outdated)
setstate myRemoteHmUART 2019-01-17 13:52:31 D-serialNr PEQ0533764
setstate myRemoteHmUART 2019-01-17 13:52:28 D-type HM-MOD-UART
setstate myRemoteHmUART 2019-01-17 13:52:31 cond ok
setstate myRemoteHmUART 2019-01-17 13:52:31 load 0
setstate myRemoteHmUART 2019-01-17 13:52:31 loadLvl low
setstate myRemoteHmUART 2019-01-17 13:52:28 state opened



Und dann macht man noch das Firmware Update und alles ist gut:

Code Auswählen Erweitern

defmod myRemoteHmUART HMUARTLGW uart://192.168.1.153:2325
attr myRemoteHmUART room Gateways
attr myRemoteHmUART verbose 0

setstate myRemoteHmUART opened
setstate myRemoteHmUART 2019-01-17 13:59:07 D-HMIdOriginal 6A56C4
setstate myRemoteHmUART 2019-01-17 13:59:07 D-firmware 1.4.1
setstate myRemoteHmUART 2019-01-17 13:59:07 D-serialNr PEQ0533764
setstate myRemoteHmUART 2019-01-17 13:52:28 D-type HM-MOD-UART
setstate myRemoteHmUART 2019-01-17 13:59:07 cond ok
setstate myRemoteHmUART 2019-01-17 13:59:07 load 0
setstate myRemoteHmUART 2019-01-17 13:59:07 loadLvl low
setstate myRemoteHmUART 2019-01-17 13:58:40 state opened

Ich glaub ich muss mal die Schritte ins Wiki eintragen, wenn mir jemand die richtige Stelle nennt.

[dmq]

Bin zwar ein wenig spät, aber ja, bei mir läuft es auch unter :2325 UART2.

[Ranseyer]

Ich glaub ich muss mal die Schritte ins Wiki eintragen, wenn mir jemand die richtige Stelle nennt.

Ich denke das hat mit dem MAPLE-CUL Projekt an sich nichts zu tun. Daher schlage ich vor: https://wiki.fhem.de/wiki/MapleCUX-Platinen

[Markus.]

hallo Zusammen,

ich hab auf dem Maple jetzt MAX auf Stamp 3 (1-4) laufen. Ein Fensterkontakt wurde auch sofort erkannt bei einer Aktion. Es wurde ein CUL_MAX angelegt und der Kontakt selber per autocreate. Denke mal das ist richtig so. Gibt es für den CUL_MAX oder den Fensterkontakt noch irgendwelche Settings die man machen sollte in Verbindung mit dem Maple?
Bei meinen Anfänglichen Tests habe bemerkt, das wenn man den Kontakt zu schnell/ zu oft öffnet oder schliesst, tut sich Garnichts mehr. Soll heissen, das der Zustand des Kontaktes nicht mehr registriert wird. Habe dann den Kontakt und den CUL_MAX gelöscht und neu angelegen lassen.
Nun läuft er eigentlich seit Stunden stabil.


Gruß

Markus

[dmq]

Hi,

kann es sein, dass der MapleCUN nur ein Socket (per Dienst) erlaubt? Wenn ich eine bestehende TCP-Verbindung auf :2323, :2324 und :2325 offen (ESTABLISHED) habe, bekomme ich bei allen weiteren versuchen darauf ein tcp rst.

Ist das bekannt? Gewollt? Konfigurierbar?

Danke vorab

[Rheingold]

Hi,

ich war so naiv und glaubte ein Update von FHEM an einem Sonntagabend sei eine gute Idee  Das Resultat ist, dass mein Stacked CUL nicht mehr richtig funktioniert. Die ersten paar Minuten nach einem Neustart ist alles super, aber dann wenn ich ein paar Dinge schalte kommt im Log einfach nur

2019.01.20 18:35:00 1: FHEM:DEVIO:MAPLECUL868Stack:9600 disconnected, waiting to reappear (MAPLECUL433)

Geändert an der Hardware oder der config habe ich nichts. Die einzige Änderung war ein Update von FHEM. Gut, das letzte Update ist schon eine Weile her, aber nun ist der CUL irgendwie unbrauchbar geworden
Ein "Reopen" des MAPLECUL433 hilft nicht. Auch den Strom kurzzeitig trennen und dann ein "reopen" hat das gleiche Ergebnis.

Wer kann mir helfen? Ich bin ratlos was den Stacked CUL betrifft Das einzige was ich verstehe, ist dass der Stacked868 die Verbindung verliert. Den Grund verstehe ich nicht...

Definiert ist es wie folgt:

Code Auswählen Erweitern

define MAPLECUL868 CUL 192.168.178.47:2323 4444
attr MAPLECUL868 model CUN
attr MAPLECUL868 rfmode SlowRF
attr MAPLECUL868 room 99_System,CUL
define MAPLECUL868Stack STACKABLE MAPLECUL868
attr MAPLECUL868Stack room CUL
define MAPLECUL433 CUL FHEM:DEVIO:MAPLECUL868Stack:9600 0000
attr MAPLECUL433 model CUN
attr MAPLECUL433 room CUL
define MAPLECUL433Stack STACKABLE MAPLECUL433
attr MAPLECUL433Stack room CUL

Danke schon mal

[Eistee]

MapleCUN vom Strom trennen und wieder verbinden. Dann im FHEM ein shutdown restart. Dann sollte alles wieder gehen wenn deine config ok ist. Hab das auch schon paarmal gehabt da half nur ein fhem neustart. evtl ist da ein fehler in den CUL Modulen im FHEM das da irgend was hängen bleiben kann.
Und generell läuft bei mir STACKABLE_CC stabiler wie STACKABLE

[Rheingold]

MapleCUN vom Strom trennen und wieder verbinden. Dann im FHEM ein shutdown restart. Dann sollte alles wieder gehen wenn deine config ok ist. Hab das auch schon paarmal gehabt da half nur ein fhem neustart. evtl ist da ein fehler in den CUL Modulen im FHEM das da irgend was hängen bleiben kann.

Hi,
danke für die flotte Antwort. Ein Neustart von FHEM habe ich jetzt schon etwa 25 Mal gemacht. Erst funktioniert alles, aber sobald ich ein Device über diesen MAPLECUL433 schalten will, verabschiedet er sich (zusammen mit dem MAPLECUL868Stack). Stimmt meine zuvor geschriebene Config nicht? Wie gesagt, vor dem Update lief alles wunderbar.

Was mich wundert ist, dass der MAPLECUL868Stack plötzlich nicht mehr defined ist, sondern den Status 0 hat.

[Telekatz]

Hi,

kann es sein, dass der MapleCUN nur ein Socket (per Dienst) erlaubt? Wenn ich eine bestehende TCP-Verbindung auf :2323, :2324 und :2325 offen (ESTABLISHED) habe, bekomme ich bei allen weiteren versuchen darauf ein tcp rst.

Ist das bekannt? Gewollt? Konfigurierbar?

Danke vorab

Ja, das ist so gewollt.