GELÖST: FHEM2FHEM im RAW Modus an CUL SCC rfmode MAX

[Sinus]

Moin,

nachdem mir nun FHEM seit über einem Jahr viel Freude bereitet (Herzlichen Dank an die vielen Entwickler!) bin ich nun an einem Punkt an dem mich auch das Lesen diverser Foren Beiträge, Wikis und der Commandref nicht weiterbringt, deshalb wende ich mich an Euch.
Nach dem Umzug des FHEM Systems auf einen OrangePi Plus soll der RaspberryPI B nur noch als Remote Instanz für einen SCC CUL V 1.65 rfmode MAX genutzt werden. Deshalb habe ich auf dem OrangePi ein DummyDevice für den CUL_0 angelegt und anschließend ein FHEM2FHEM Device definiert:

Code Auswählen Erweitern

define raspi2opi FHEM2FHEM IPAdresse:7072 RAW:CUL_0 Das funktioniert soweit auch alles gut. Kurz nach dem Anlegen wurde per autocreate das Device CULMAX0 erzeugt. Auch das erscheint mir logisch denn dieses ist ja auch auf dem Raspi vorhanden.
Ich habe die Funktion des FHEM2FHEM Moduls wie folgt aufgefasst:

Code Auswählen Erweitern


Gerät mit Infrastruktur (hier:raspberrypiB) Gerät ohne Infrastruktur (hier:orangepi+)
--------------------------------- -------------------------- --------------------------------- ------------------------- --------------------------------
| NAME:MAXLAN0 | | NME:CUL_0 | | NAME:raspi2opi | | NAME:CUL_0 | | NAME:MAXLAN0 |
| IODev:CUL_0 | ---> | (SCC V 1.65) | ---> | | ---> | (dummy) | ---> | IODev:CUL_0 |
| TYPE:CUL_MAX | | TYPE:CUL | | TYPE:FHEM2FHEM | | TYPE:CUL | | TYPE:CUL_MAX |
--------------------------------- -------------------------- --------------------------------- ------------------------- ---------------------------------


Nun wurde dieses MAXLAN0 Device allerdings entgegen meiner Vermutung per autocreate auf dem OrangePi mit dem IODev:raspi2opi angelegt. Seitdem wird das Filelog mit Meldungen wie folgt gefüllt.

Code Auswählen Erweitern

CUL_MAX_Check: No IODev has no VERSION
Error in CUL_MAX_SendQueueHandler: CUL raspi2opi did not answer request for current credits. Waiting 5 seconds.

Das ist ja nicht falsch. Das Dummy CUL_0 auf dem Orangepi wird mit dem Hinweis im Filelog

Code Auswählen Erweitern

CUL_MAX_Check: Detected firmware version 0 of the CUL-compatible IODev
(Ist hier Meldung mit "keine firmware gefunden" zu Übersetzen?) Wenn nicht ist der Eintrag ja richtig. Alle IODev haben eine Firmware (wenn auch manchmal eine sehr niedrige (0)).
Auch der zweite Eintrag ist nicht falsch, denn das Device raspi2opi hat keine Credits.

Ein "reopen" des CUL_0 sowohl auf dem raspi als auch auf dem orangepi wie in Forenbeiträgen beschrieben ändert nichts....

Das manuelle Ändern des IODev auf CUL_0 im MAXLAN0 Device des orangepi ändert augenscheinlich auch gar nichts. Bei beiden Konfigurationen werden die selben Readings der angeschlossenen Thermostate und Fensterkontakte ausgelesen.


Wie ist der Absatz im Wiki im Bezug auf RAW Devices/Verbindungen zu interpretieren?

muss das Reading "state" explizit geschrieben werden. Sonst zeigt der Status des Dummy nur "??" (Abhilfe: siehe Beispiel)

Dies ist auch bei mir der Fall, jedoch nutze ich kein LOG und mir stehen lt. Definition keine Regexp zur Verfügung.

Wie kann ich also den state als Reading oder Internal und die credits10ms als Reading dem orangepi zur Verfügung stellen?
Was ist zu tun um Commands an die Devices am raspi zu schicken? Funktioniert das automatisch wenn auf dem Hauptsystem die verbleibenden Credits bekannt sind?
Was ist denn nun richtig als IODev für das MAXLAN0 Dev auf dem orangepi?
Wenn wie von autocreate angelegt das raspi2opi Device wozu ist dann das CUL_0 Dummy auf dem orangepi da?

Ich hoffe der ein oder andere hat vielleicht einen Hinweis oder Vorschlag zu meinen Fragen was ich Verbessern kann um die von mir erwarteten Funktionen zu nutzen.

Vielen Dank
Sinus

[chris1284]

fhem2fhem finde ich nur bedingt geeignet um einen cul in der ferne anzubinden. schau dir mal ser2net an

zb hier der letzte post http://forum.fhem.de/index.php?topic=28413.10

bzw einfach im forum danach suchen und du findest viele einbindungsbeispiele

[Sinus]

Moin,

jau das ist ja easy. War in 10 min. eingerichtet. 
Ich bin davon ausgegangen, dass wenn es extra ein Modul in FHEM für u.a. solche Anwendungsfälle gibt (RAW Modus) es sicherlich eleganter ist die Lösung erstmal mit FHEM eigenen Boardmitteln zu versuchen.
Allerdings benötige ich folgenden Workaround um den CUL auf dem orangePi auf Initalized zu setzen.
Auf dem raspi: stop ser2net - start fhem - stop fhem - start ser2net
Auf dem orangePi: ein notify welches den Status des CUL überwacht und dem raspi bei Bedarf per knockd eine Info schickt das einmal durchzuführen
Ein reopen ist nicht nötig der CUL wird danach sofort auf Initalized gesetzt.

Nun stellen sich mir die Fragen:
Was passiert beim starten von fhem mit dem CUL?
Warum wird dieser erst dann von ser2net "richtig" bereitgestellt?
Wie kann ich diesen Initprozess auch mit linux Boardmitteln gestalten?

Herzlichen Dank
Sinus