Bestimmte Protokolle von CUL Devices deaktivieren?

[Guest]

Originally posted by: <email address deleted>

Hallo zusammen,

ich verwende nun schon seit einiger Zeit einen CUL868 für meine FS20 Steuerung. Nun habe ich mir einen CUL433 dazu gekauft, um auch auf dem 433er Spektrum empfangen und senden zu können.
Allgemein bin ich davon etwas enttäuscht, da ich mir mehr Funktionalität bzgl. meiner 433er Restkomponenten versprochen habe, das ist aber ein anderes Thema.

Nun habe ich aber folgendes Problem:
Ich verwende die beiden USB-Sticks in meinem Raspberry Pi. Das funktioniert soweit ganz gut. Eine Zeit lang. Dann (nach einer unbestimmbaren Weile) ist der Pi nicht mehr erreichbar.
Nun ziehe ich also zum Testen den 433er ab. In FHEM wird dieser dann auch korrekt als Disconnected dargestellt. Wenn ich ihn wieder reinstecke auch als initialized.
Nun aber zu dem eigentlichen Problem:
Wenn er entfernt wurde, versucht FHEM alle FS20 Pakete über den nicht mehr vorhandenen und dafür ja auch niemals zuständigen 433er Stick zu senden. Was natürlich nicht gelingt.
Der Empfang von FS20 funktioniert weiterhin, ich kann halt nur nichts mehr senden.

Nun zur Frage:
Ist es möglich, einen CUL bei der Definition nur für bestimmte Protokolle zuzulassen? FS20 auf einem 433er geht ja sowieso nicht...
Wieso verwendet er weiterhin das Device, was ja als Disconnected dargestellt wird?

Danke schon mal für eure Unterstützung.

Reinerlein

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo nochmal,

ich konnte das Problem auf die Ermittlung des Devices zurückführen. FHEM
ist anscheinend nicht gut auf die gleichzeitige Verwendung von zwei CUL
Modulen vorbereitet, von denen eines nur für den Betrieb von 433MHz gedacht
ist.
Die beiden Devices werden gleichberechtigt behandelt, da man keinerlei
Möglichkeit hat, die Verwendbarkeit bzgl. Funkprotokolle einzuschränken
(ich habe da jetzt was hardcoded drin, was aber unschön ist). Leider hat
FHEM bei mir immer das falsche Device verwenden wollen, da das NR-Feld dort
einen höheren Wert hat (die Entscheidung basiert auf dem Letzten Element
der Device-Liste sortiert nach dem NR-Feld).

Kann man da nicht irgendwas bauen, damit man bei der Definition des Devices
die Verwendbarkeit nach Funkprotokollen einschränken kann?

Danke schon mal für eure Hilfe
Reinerlein
Am Samstag, 17. November 2012 15:48:35 UTC+1 schrieb Reinerlein:
>
> Hallo zusammen,
>
> ich verwende nun schon seit einiger Zeit einen CUL868 für meine FS20
> Steuerung. Nun habe ich mir einen CUL433 dazu gekauft, um auch auf dem
> 433er Spektrum empfangen und senden zu können.
> Allgemein bin ich davon etwas enttäuscht, da ich mir mehr Funktionalität
> bzgl. meiner 433er Restkomponenten versprochen habe, das ist aber ein
> anderes Thema.
>
> Nun habe ich aber folgendes Problem:
> Ich verwende die beiden USB-Sticks in meinem Raspberry Pi. Das
> funktioniert soweit ganz gut. Eine Zeit lang. Dann (nach einer
> unbestimmbaren Weile) ist der Pi nicht mehr erreichbar.
> Nun ziehe ich also zum Testen den 433er ab. In FHEM wird dieser dann auch
> korrekt als Disconnected dargestellt. Wenn ich ihn wieder reinstecke auch
> als initialized.
> Nun aber zu dem eigentlichen Problem:
> Wenn er entfernt wurde, versucht FHEM alle FS20 Pakete über den nicht mehr
> vorhandenen und dafür ja auch niemals zuständigen 433er Stick zu senden.
> Was natürlich nicht gelingt.
> Der Empfang von FS20 funktioniert weiterhin, ich kann halt nur nichts mehr
> senden.
>
> Nun zur Frage:
> Ist es möglich, einen CUL bei der Definition nur für bestimmte Protokolle
> zuzulassen? FS20 auf einem 433er geht ja sowieso nicht...
> Wieso verwendet er weiterhin das Device, was ja als Disconnected
> dargestellt wird?
>
> Danke schon mal für eure Unterstützung.
>
> Reinerlein

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Tobias]

                                                   

IMHO gibts dafür das Attribut IODEV

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Wenn er entfernt wurde, versucht FHEM alle FS20 Pakete über den nicht mehr
> vorhandenen und dafür ja auch niemals zuständigen 433er Stick zu senden.

Ich meine das stimmt so nicht.

Fhem ordnet dynamisch die einem CUL zugeordneten logischen Geraete (FS20/FHT)
_NICHT_ einem anderen zu, wenn das betroffene CUL inaktiv oder geloescht wird.
Wer sowas fuer wichtig haelt, kann via notify die IODev Attribute aller
betroffenen Geraete setzen/aendern.

Beim starten wird ein logisches Geraet (FS20/FHT) dem zuletzt definierten
kompatiblen CUL zugeordnet. Hier gibt es kein Unterschied zw. 868 und 433MHz,
FS20 Geraete koennen also bei "falscher" Reihenfolge einem 433MHz CUL
zugeordnet werden.  
Man kann aber per IODev Attribut diese Zuordnung beeinflussen.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Das bedeutet aber ja, dass ich bei exakt *jedem* FS20 Device dieses IODev
setzen muss, da bei mir nun mal die falsche Reihenfolge vorliegt.

Das Phänomen mit dem abgezogenen Stick kam nur daher, dass dann die ttyACM0
bzw. ttyACM1 vertauscht waren. Das habe ich mittels udev festgezurrt.
Trotzdem versucht FHEM auf den abgezogenen Stick (der von FHEM korrekt als
disconnected markiert ist) zu senden. Das ist schon sehr komisch, aber
sowieso nur Beiwerk, da das eigentliche Problem ja wegen der FS20 Zuordnung
zum 433er CUL besteht.

Ich habe mir jetzt eine if-Abfrage an der Stelle eingebaut, wo die Devices
"geladen" werden. Dort wird dann für den 433er Stick momentan nur das
Protokoll CUL_TX definiert. Die Erkennung wird auf einem zusätzlichen
Parameter hinter FHTID ausgeführt: "IRGENDWAS" oder "433".
Das ist nicht wirklich schön, funktioniert aber zentral; Und natürlich muss
ich das nach jedem Update nachziehen

Ist es kompliziert, diese möglichen Protokolle irgendwie per Attribut oder
so bei der Definition mit anzugeben, sodass es auch ins Konzept passt?
Das habe ich mir noch nicht angeschaut...

Am Sonntag, 18. November 2012 09:31:15 UTC+1 schrieb Rudolf Koenig:
>
> > Wenn er entfernt wurde, versucht FHEM alle FS20 Pakete �ber den nicht
> mehr
> > vorhandenen und daf�r ja auch niemals zust�ndigen 433er Stick zu
> senden.
>
> Ich meine das stimmt so nicht.
>
> Fhem ordnet dynamisch die einem CUL zugeordneten logischen Geraete
> (FS20/FHT)
> _NICHT_ einem anderen zu, wenn das betroffene CUL inaktiv oder geloescht
> wird.
> Wer sowas fuer wichtig haelt, kann via notify die IODev Attribute aller
> betroffenen Geraete setzen/aendern.
>
> Beim starten wird ein logisches Geraet (FS20/FHT) dem zuletzt definierten
> kompatiblen CUL zugeordnet. Hier gibt es kein Unterschied zw. 868 und
> 433MHz,
> FS20 Geraete koennen also bei "falscher" Reihenfolge einem 433MHz CUL
> zugeordnet werden.  
> Man kann aber per IODev Attribut diese Zuordnung beeinflussen.
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Das bedeutet aber ja, dass ich bei exakt *jedem* FS20 Device dieses IODev
> setzen muss, da bei mir nun mal die falsche Reihenfolge vorliegt.

Nein, man kann ja auch das passende CUL in fhem.cfg verschieben.

> Ist es kompliziert, diese möglichen Protokolle irgendwie per Attribut oder
> so bei der Definition mit anzugeben, sodass es auch ins Konzept passt?

Das ist (z.Zt) nicht moeglich.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com