CUL RFR mit InterTechno möglich?

Begonnen von weini, 20 November 2016, 15:29:41

Vorheriges Thema - Nächstes Thema

weini

Ich hatte die Frage so schon im CUL-Bereich gestellt (https://forum.fhem.de/index.php/topic,61031.0.html).

Nach Rudolfs Feedback
ZitatAber mW ist das IT Modul in FHEM nicht RFR/FHEM2FHEM/SCC/etc faehig, da es annimmt, direkt Zugriff auf dem CUL zu haben, um z.Bsp fuer das Senden von 868MHz auf 433Mhz zu schalten.

versuche ich jetzt hier nochmal mein Glück: Kann ich einen 433 MHz CUL RFR mit dem IT Modul nutzen?

SofB

Hast du es inzwischen ausprobiert?
Ich habe auch zwei 433 Culs und stehe vor der gleichen Frage.
Bisher habe ich das IODev immer direkt zugewiesen. Allerdings stehen immernoch Meldungen im Log die auf Wechselwirkungen hinweisen.
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

weini

Habe damals leider keine Antwort bekommen und bin deshalb dann alternativ auf einen WiFi-CUL als zweiten 433er ausgewichen.

SofB

Wie hast du es implementiert?
Für das konkrete device dann das gewünschte IODev gesetzt?
Hast du auch merkwürdige einträge im log? wenn ein device geschaltet wird, bekommt die andere CUL irgendwas mit und versteht es nicht. irgendwas "abgehacktes"...
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

weini

Tatsächlich habe ich es noch nich so am laufen, wie ich es mir vorstelle. Ich habe zwei WLAN CULs (1x Selbstbau, 1x Mini-CUL) und mit keinem bekomme ich meine IT Geräte sauber geschalten.
Klar, das IODev muss im Gerät entsprechend gesetzt werden.

Die "Funkstörungen" habe ich auch gesehen, das sehe ich aber als normal an. Da fängt der andere CUL eben (teilweise) das auf, was sein Partner gesendet hat.

SofB

was meinst du mit nicht "sauber geschaltet"?
Bei mir läuft das Konstrukt stabil. bis auf die Log Einträge, die scheinbar eher kosmetischer Natur sind.
Bei Problemen lag bei mir idR immer nur ein Reichweiten Problem vor.
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

weini

Ich meinte in meiner ersten Antwort, dass ich RFR nicht versucht habe und mir stattdessen einen WiFi-CUL selbst gebaut und dann noch einen weiteren gekauft habe.
Der gekaufte hat leider eine extrem geringe Reichweite und bei meinem Selbstbau bekomme ich den Arduiono nicht geflasht. Ich habe das aber nach kurzer Zeit abgebrochen weil ich jetzt erst mal meine Heizungssteuerung aufbauen musste.
Das Thema "zweiter 433er CUL" bekommt bei mir jetzt demnächst wieder Prio.

Hast du den zweiten CUL via RFR angebunden? Läuft das bei dir?

SofB

Ich habe beide als separate IODevs definiert und weise diese manuell den Geräten zu und lebe mit den "Fehlerlogs". vielleicht probiere ich es mal an einem verregneten Sonntag aus.
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

KölnSolar

Hi Björn,
da ich derzeit keine 2 433er habe, kann ich es nicht testen und muss die Frage noch einmal hervorkramen :-[

Bisher habe ich nur gegenteilige Antworten  gefunden, z.B. von Rudi
ZitatAber mW ist das IT Modul in FHEM nicht RFR/FHEM2FHEM/SCC/etc faehig, da es annimmt, direkt Zugriff auf dem CUL zu haben, um z.Bsp fuer das Senden von 868MHz auf 433Mhz zu schalten.
und
Zitatdas FHEM IT Modul greift direkt auf das zugeordnete CUL zu (haelt sich nicht and die nie dokumentierten "offiziellen" Schnittstellen  ), und ist damit nicht FHEM2FHEM oder RFR faehig,

Mir sagt das leider noch nicht viel  :-\ Wo müsste man ansetzen das IT_Modul zu befähigen bzw. was sind evtl. Hinderungsgründe/Funktionsverlust ?

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Ralf9

Momentan wird beim set mit
CallFn($io->{NAME}, "SetFn" ....
und
CallFn($io->{NAME}, "GetFn" ...
direkt auf die SET- und GET-Routine der 00_CUL.pm des zugeordneten CUL zugegriffen.

Dies müsste so wie es auch schon beim Signalduino gemacht wird, auf IOWrite umgestellt werden. Dies wird aber vermutlich ein etwas größerer Aufwand, dazu muss wahrscheinlich auch einiges an der 00_CUL.pm angepasst werden.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

KölnSolar

Danke, dann guck ich mir das für die 10_IT mal an.
Zitat
Dies müsste so wie es auch schon beim Signalduino gemacht wird, auf IOWrite umgestellt werden.
Aber Ihr "schiebt" doch auch nur die IT-Befehle an die 10_IT weiter, oder ?  :-\
ZitatDies wird aber vermutlich ein etwas größerer Aufwand, dazu muss wahrscheinlich auch einiges an der 00_CUL.pm angepasst werden.
Hmm, aber die ist doch Modul-unabhängig.  :-\
Vielleicht wird es mir klarer, wenn ich CallFn und  IOWrite verstanden hab.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

RaspiLED

Hi Ralf,
gibt es einen Thread wie das im Signalduino genau funktioniert?
Wer arbeitet beim CUL aktuell daran?
Gruß Arnd


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

KölnSolar

Hab mir jetzt mal CallFn und  IOWrite im Wiki näher angeguckt. So ganz schlau geworden bin ich nicht.  :-[

@Ralf
Du rufst ja aus der 10_IT so auf
IOWrite($hash, 'sendMsg', $protocolId . $message . '#R' . $SignalRepeats . $ITClock . $ITfrequency);
Damit wird dann SIGNALduino_Write und von dort   SIGNALduino_Set mit Argument 'sendMsg' aufgerufen u. verarbeitet. Richtig ?

Bei FS20/CUL so IOWrite($hash, "04", "010101" . $hash->{XMIT} . $hash->{BTN} . $c);

@Rudi
kann ich dann CallFn($io->{NAME}, "GetFn", $io, (" ", "raw", $message));
so
IOWrite($hash, "i", substr($message,1)); bei $message = "is".uc($hash->{XMIT}.$onoffcode);
ersetzen ?
(mir ist klar, dass es nicht 100% das selbe ist, weil in der GetFn noch mehr steckt)
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Ralf9

ZitatDamit wird dann SIGNALduino_Write und von dort   SIGNALduino_Set mit Argument 'sendMsg' aufgerufen u. verarbeitet. Richtig ?
Ja.

Dies wird beim cul so nicht funktionieren
IOWrite($hash, "i", substr($message,1));

In der CUL_Write ist dies momentan nicht vorgesehen, daß was zur get-Routine weitergereicht wird
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/00_CUL.pm#L709

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

KölnSolar

Hi Ralf, danke,
ich komme der Sache näher.   :-\

Also ist  nicht das IOWrite das Entscheidende, sondern CUL_AddSendQueue bzw.
push(@{$qHash->{QUEUE}}, $bstring);

Über das Queue-Handling muss ich mir dann hoffentlich keinen Kopf machen ?!?  :-\
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt