CUNX und CUL parallel: Sender einstellen

Hallo,

ich setze Homegear 0.7.12-1492 auf einem Raspberry Pi mit einem CUL und CUNX mit Homematic Geräten ein. OpenHAB 2.1 spricht dabei Homegear an.

Beim Packet Empfang sehe ich dass das gleiche Packet meist von beiden empfangen wird:
01/15/18 13:03:39.382 HomeMatic BidCoS packet received (CUNX-AR, RSSI: -70 dBm): 0C…
01/15/18 13:03:39.382 HomeMatic BidCoS packet received (CUL-AR, RSSI: -66 dBm): 0C…
(gerade stehen testweise beide nebeneinander daher die etwa gleiche Signalstärke)

Der Versand geht immer über den CUNX:
01/15/18 13:06:52.300 Module HomeMatic BidCoS: CUNX “CUNX-AR”: Info: Sending (CUNX-AR): 0C…

Manche Geräte erreicht dieser jedoch nicht mehr zuverlässig, hier würde ich gerne über den CUL gehen. Wie kann ich erzwingen welches Gerät hierfür verwendet wird?

Vielen Dank

Ich würde eins deiner Funkmodule entfernen, zwei Module auf gleicher Frequenz und für die gleiche Familie macht doch keinen Sinn.

Ich denke mal, die Module stören sich gegenseitig.

Die werden, wenn ich weiß wie ich ein Funkmodul erzwinge, wieder an unterschiedlichen Stellen im Haus stehen. Mit einem Funkmodul kann ich nicht alles abdecken

Dann solltest du aber doch den Test mit zwei Raspberry Pi machen, und nicht mit einem. Einer wird dann Gateway und dann sollten die Geräte roamen. Was natürlich nur sinnvoll funktionieren kann, wenn die nicht nebeneinander stehen.

Schau mal hier https://forum.homegear.eu/t/mehrere-raspberry-pi-mit-scc/1657.

1 Like

Moment,

der CUNX ist doch ein “Netzwerk-CUL”. Damit werden quasi beide in der homematicbidcos.conf eingetragen und die Geräte sollten selbstständig zwischen den Funkmodulen roamen.

Oder @sathya?

1 Like

Oha. OK. Man sollte vorher googlen, wenn man gefährliches Halbwissen hat. Ich dachte das wäre nur ein anderer Name für so einen USB Adapter. Wusste gar nicht, dass es so etwas gibt.

Sorry, falls ich da auf dem falschen Zug war.

Aber dieses Zitat aus meinem Link sollte dann trotzdem helfen, oder?

1 Like

Genau das ist ein Netzwerk-CUL und daher perfekt geeignet um es irgendwo zu platzieren (Netzwerkdosen habe ich in jedem Raum). Das klappt für den Empfang auch perfekt. Für manche Sensoren sehe ich dass die Pakete von beiden empfangen werden, manche Packete aber auch nur von einem.

Das Problem ist das Senden, laut Logfile (siehe oben) geht das IMMER über den CUNX. Jetzt habe ich einen Heizungsthermostat den der CUNX aber nicht erreicht, daher müsste ich hier über den CUL gehen. Bei zwei Fensterkontakten habe ich ein ähnliches Problem: ich sehe den Status immer (Empfang durch den CUL), der Acknowledge geht aber über den CUNX raus und der kommt meistens nicht an.

setInterface klingt genau richtig, hier müsste ich dann:
homegear -e rc 'print_v($hg->setInterface(11, "CUL-AR"));'
ausführen wenn ich es richtig verstanden habe?

Homegear könnte doch auch einfach selbst entscheiden welches Interface er zum Senden nutzt, es sollte immer das Interface genutzt werden mit dem besten RSSI Wert?

Da muss einfach @sathya was zu sagen, ich bin davon zu weit weg. Hab ihn schon gebeten hier mal rein zu gucken.

@job: Ein mit aCulFW geflashter Max-Cube ist auch ein Cunx :wink:

So ähnlich haben die Excel-Entwickler auch gedacht, als es darum ging, was tun wenn ein Punkt und ne Ziffer eingegeben wird. Ooch, am besten nachen wir immer ein Datum raus. :wink:

Und jetzt haben wir den Salat… :joy:

Hallo,

Ja, das geht. Dafür haben die Geräte den Konfigurationsparameter ROAMING auf Kanal 0. Wenn dieser auf true gesetzt wird, wird das Interface automatisch gewählt. Für die manuelle Wahl ist setInterface() genau der richtige Befehl.

Viele Grüße

Sathya

2 Likes

Danke für die Hilfe, ich mache aber noch etwas falsch scheint mir. Laut Ausgabe von ls gibt es ein Device mit ID 1, daher sollte doch dieser Aufruf einen Wert liefern?

# homegear -e rc 'print_v($hg->getValue(1, 0, "ROAMING"));'
Exit code: 255

Laut Doku: getValue(Integer peerId, Integer channel, String parameterName)

Konfigurationsparameter musst du glaube ich mit getParamset abfragen und entsprechend mit setParamset setzen.

Klasse das war die Lösung. Funktioniert jetzt wie gewünscht:

01/19/18 15:09:38.177 Info: Changing interface of peer 3 to CUL-AR, because the reception is better.

01/19/18 15:10:59.135 Info: Changing interface of peer 6 to CUNX-AR, because the reception is better.

Falls mal jemand über diesen Thread stolpert noch der Aufruf:
homegear -e rc '$hg->putParamset(1, 0, array("ROAMING" => true));'
1 ist die PeerID

1 Like