Liebe Fhemer,
ich habe eigentlich nur HM (HomeMatic) Komponenten, die sind aber auch sch.... Teuer. Also habe ich jetzt mal versucht ein paar AB440S mit zu integrieren (über den CUL) umschaltung auf 433MHZ.
Das geht auch ganz prima, nur leider Schalten meine HM Aktoren dann nicht mehr, also eigentlich erst nach einem "Shutdown Restart".
Das ist jetzt auch nicht ganz so Sinn der Sache.....
Muss ich nach dem Schaltbefehl noch eine Rücksetzung des CUL veranlassen? Und wenn ja wie ?
define KUELichtT IT 0F00F0FFFF FF F0
attr KUELichtT IODev CUL1
attr KUELichtT group Schalter
attr KUELichtT model itswitch
define KUELichtTDummy dummy
attr KUELichtTDummy fp_Wplan 500,850,2,
attr KUELichtTDummy setList state:on,off
attr KUELichtTDummy webCmd state
Ich schalte von 868 auf 434 und zurück so:
# Wohnzimmer Schalter notify
define schalter_wz_on_notify notify Schalter_WZ:opened \
set CUL_0 freq 433.920;;\
set CUL_0 bWidth 325;;\
set ELRO_WZ_Fenster on;;\
set ELRO_WZ_IT on;;\
set ELRO_WZ_Vitrine on;;\
set CUL_0 freq 868.350;;\
set CUL_0 bWidth 406;;
Du müsstest vermutlich noch den mode setzen bei dir zurück auf homematic:
attr CUL rfmode HomeMatic
Hallo
Darf ich mich mal einklinken.
Seid wenigen Wochen mache ich meine ersten Schritte mit FHEm. Ich nutze den Cul mit 868 (mittlere Antennengröße) für FS20 und JeeLink.
Jetzt hatte ich noch Elro für den Garten. Eine Dose wollte ich jetzt innen mit Fhem ausprobieren.
Ich bin nach dem Wiki vorgegangen, und siehe da:Es funktioniert.
Jetzt meine Frage: obwohl mein Cul auf 868 funkt, läuft das Ganze mit den 433 von Elro. Warum ist bei Euch dieses Umschalten erforderlich ?
Oder allgemeiner: wann ist überhaupt eine Umschaltung der Frequenz erforderlich ?
Danke
Jürgen
1. Die Intertechno Implementation schaltet soweit ich weiss (und es bei mir auch geht) vor jedem Befehl von ALLEINE die Frequenz um unmittelbar danach wieder zurück. Wenn es bei noanda nicht geht, liegt da noch irgendeine Problem vor.
2. die Methode von Johannes ist wegen 1. eigentlich überflüssig UND auch nicht gut, weil beim Befehl
Zitatset CUL_0 freq ...
die neue Frequenz (im Gegenstaz zum Umschalten des IT Moduls) in's EEPROM des CUL geschrieben wird. Das kann man aber nur begrenzt oft machen, dann ist das EEPROM kaputt. Wie oft "begrenzt oft" ist weiss ich konkret nicht, das hängt vom EEPROM und so ab und ist irgendwas zwischen 10.000 und ein paar hundertausend Schreibvorgängen. Wenn das (sagen wir mal) beim CUL 10.000 mal ist und Johannes seinen Schalter 5x pro Tag schaltet, erzeugt er jeden Tag 10 Schreibvorgänge auf die selben Speicherbereiche, dann hält das CUL weniger als 3 Jahre.
Wenn er den Schalter nur 2x betätigt und das EEPROM 100.000 Schreibvorgänge ab kann, dann hält das CUL 68 Jahre.
Ob das praktisch ein Problem ist, muss jeder selber entscheiden.
Aus meiner Sicht ist die bessere Methode rauszufinden, warum das CUL nicht wie geplant zurückschaltet. Da wäre mein erster Ansatz, dass ich die Definition des CULs mal sehen wollte.
ZitatOder allgemeiner: wann ist überhaupt eine Umschaltung der Frequenz erforderlich ?
in allen praktischen Belangen gar nicht, jedenfalls nicht mit dem set freq Befehl. Der dient eher dazu , die passende Frequenz EINMAL einzustellen, wenn der Default nicht die besten Ergebnisse liefert. Vor allem FS20, S300 und FHTs sind in der Einhaltung der Frequenz notorisch ungenau, da kann leichtes Verändern der Frequenz oder Bandbreite am CUL helfen den Empfang zu verbessern. Siehe auch CUL eintrag im Wiki etc.
Zitat von: Zrrronggg! am 23 Dezember 2013, 01:54:33
weil beim Befehl
set CUL_0 freq ...
die neue Frequenz (im gegenstaz zum umschalten des IT Moduls) in's EEPROM des CUL geschrieben wird.
Ok, was dazu gelernt. Auch dass das angeblich automatisch von Statten geht mit dem Frequenzwechsel war mir nicht klar. Ich habe es mir aber auch nicht zum Spaß ausgedacht mit dem händischen Wechsel, da ich zuerst gemerkt habe, dass unter meinen Standardeinstellungen mit Frequenz 868 sich garnichts getan hat. Erst nach "set freq" ließen sich die Dinger ansprechen, hat vielleicht aber auch mit der geänderten bWidth zu tun.
Ich werde es mir auf jeden Fall nochmal anschauen. Wenn der CUL geschont werden kann, dann ist das natürlich besser so.. :-)
Hallo Zusammen,
ist ja so weit alles recht informativ, Danke dafür. Leider geht es aber ohne das Rücksetzen der Frequenz leider nicht. und auch nur dann nur begernzt. Schaue mir jetzt mal die Fehlrmeldugen an und werde diese dan hier posten. Irgend einen Grund muss es ja geben. (vielleicht der CUL selber ????)
Ich darf mich mal selber zitieren:
Zitat
Aus meiner Sicht ist die bessere Methode rauszufinden, warum das CUL nicht wie geplant zurückschaltet. Da wäre mein erster Ansatz, dass ich die Definition des CULs mal sehen wollte.
Wenn wir dir helfen sollen musst du schon mitlesen ;-)
Aber Fehler im Log auswerten ist auch eine gute Idee. Eventuell auch mal verbose 5 verwenden.
Nun der CUL ist so definiert:
define initialUsbCheck notify global:INITIALIZED usb create
define CUL1 CUL /dev/ttyACM0@9600 1234
attr CUL1 rfmode HomeMatic
Vielleicht ist das ja der fehler
verbose 5 läuft auch seit ein paar Minuten, denke ich muss noch warten.
--> Danke für die Hilfe
CUL Definition sieht auf den ersten Blick gut aus.
Allerdings setzt du die hmId nicht. Damit ist die gleich der überflüssigerweise angegebenen FHTID plus vorangestelltem F1, wenn ich commandref richtig verstehe.
Sollte aber trotzdem gehen.
kannst Du mir sagen wie ich die hmId setze ?
Allerdings beleibt das Problem, dass sobald die Elro geschaltet werden sich bei den HM Aktoren nix mehr tut.
Komme aber muss mir nachher mal die Logfiles ziehen.
Zitatkannst Du mir sagen wie ich die hmId setze ?
http://www.fhemwiki.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter#Einbindung_in_FHEM
gilt sinngemäss auch für CUL
Ausserdem immer gerne genommen:
http://www.fhem.de/commandref.html#CUL
(abschnitt hmID)
@Zrrrongg
Danke, sehr informativ
Jürgen
Also ich werde es dieser Tage versuchen!!!
Ich brauche nur ein wenig Zeit, es wäre Tragisch wenn der W-Baum Dunkel bleibt. Also noch ein wenig Geduld und ich bleibe dran.
Vielen Dank erst mal für alle Infos, das Forum ist echt super
Zitat von: Zrrronggg! am 23 Dezember 2013, 01:54:33
1. Die Intertechno Implementation schaltet soweit ich weiss (und es bei mir auch geht) vor jedem Befehl von ALLEINE die Frequenz um unmittelbar danach wieder zurück. Wenn es bei noanda nicht geht, liegt da noch irgendeine Problem vor.
Also ich habs jetzt nochmal durchgespielt ohne händisches setzen der Frequenz (Ausgangslage: 868,3).
Resultat: Es passiert nichts mehr, die Elros reagieren nicht.
Bei mir ist definitiv ein setzen der Frequenz (und bWidth) nötig, damit die Elros reagieren.
Im Log auf Verbose 5 war nichts wesentliches zu erkennen. CUL Version 1.57, IT Modul auf neuestem Stand.
Ich werde also bei der "manuellen" Methode bleiben müssen, warum es bei anderen geht bzw. was bei mir falsch laufen soll weiss ich nicht.
Gruß
Sehr seltsam.
Kleiner Bericht:
Die Vergabe einer HM ID führt dazu, dass ich keinen der Aktoren mehr ansprechen kann.
Vergabe der HM ID:
define CUL1 CUL /dev/ttyACM0@9600 1234
attr CUL1 rfmode HomeMatic
attr CUL1 hmId 123ABC
Auch ein neues Peering funktioniert nicht. Die Komponenten lassen sich über
Peering:
set CUL1 hmPairForSec 600
nicht mehr ansprechen
nach löschen der Zeile:
attr CUL1 hmId 123ABC
geht wieder fast alles.
Länger beobachtet, stelle ich fest, dass der CUL auch wieder in den 868 Modus bzw. in den HM Modus wechselt. HM Elektrokomponenten wie der HM-LC-Sw2-FM, schallten auch wenige Sekunden nach dem Schalten der ELRO AB 440 ganz normal.
→ Bei den Heizungen mit dem HM-CC-RT-DN sieht das ganz anders aus. Die Aktoren schalten auch, aber mit einer Verzögerung von 20 bis 40 Min.
Sobald die ELRO deaktiviert ist, schaltet auch die Heizung wieder sofort.
Im Logfile, sieht man nur, dass die befehlen an die Heizungen ca. 10 mal raus gehen, eine Schalung erfolgt allerdings nicht.
Stellt sich nun die Frage, ob ich es mit einem 2 CUL nur für 433 Komponenten probiere, oder einfach bei HomeMatic bleibe.
Oder hat jemand einen andere Idee??
ZitatDie Vergabe einer HM ID führt dazu, dass ich keinen der Aktoren mehr ansprechen kann.
Vergabe der HM ID:
Code: [Auswählen]
define CUL1 CUL /dev/ttyACM0@9600 1234
attr CUL1 rfmode HomeMatic
attr CUL1 hmId 123ABC
ja, das ist klar.
Commandref sagt, das OHNE Angabe der HM ID der F1+FHTID verwendet wird. Das steht genau in dem Teil auf den ich verlinkt hatte weiter oben. Du musst bitte schon ... äh... lesen.
Deine HM ID ist also derzeit F11234
Und die ist nun mal anders als 123ABC
Dass die HM Aktoren sich da nicht ansprechen lassen... wundert mich nicht.
Zum neuen Pairing kann ich nichts sagen. Ich gehe davon aus - entschuldige - dass du da was falsch gemacht hast. Hast du die Geräte vor dem Pairen in den Ausgangszustand gebracht (und das alte Pairing dadurch gelöscht)?
Ich glaube aber, dass deine Probleme damit nichts zu tun haben.
ZitatSobald die ELRO deaktiviert ist, schaltet auch die Heizung wieder sofort.
Im Logfile, sieht man nur, dass die befehlen an die Heizungen ca. 10 mal raus gehen, eine Schalung erfolgt allerdings nicht.
Das ist in der Tat alles recht komisch und ich habe keine Idee woran das liegen kann. Du solltest das Problem nochmal im HomeMatic des Forums Bereich ansprechen.
Hallo Zrrronggg!
1) Danke für Dein Interesse, finde ich super
2) Mit dem Lesen hast schlicht recht, mein Fehler hatte nur in die WIKI geschaut
3) Ja ich habe die Aktoren (2 zum Testen) in den Auslieferungszustand gebracht, werde es aber jetzt die Finger davon lassen denn es ist ja nicht wirklich nötig, aber danke. Wenn ich mal ein paar Tage Urlaub habe schaue ich mal.
4) Werde ich mal in HM Posten, vielleicht gab es das ja schon mal
Eventuell setzt ich Fhem einfach neu auf, wenn dann mal alle Aktoren unter einem Dach habe. Aber wann ist man schon fertig :o
ZitatAber wann ist man schon fertig
Nie.
Ich jedenfalls nicht. ;D
Befürchte ich bin auch süchtig 8)
Zitat von: Johannes am 24 Dezember 2013, 13:23:26
Also ich habs jetzt nochmal durchgespielt ohne händisches setzen der Frequenz (Ausgangslage: 868,3).
Resultat: Es passiert nichts mehr, die Elros reagieren nicht.
Bei mir ist definitiv ein setzen der Frequenz (und bWidth) nötig, damit die Elros reagieren.
Im Log auf Verbose 5 war nichts wesentliches zu erkennen. CUL Version 1.57, IT Modul auf neuestem Stand.
Ich werde also bei der "manuellen" Methode bleiben müssen, warum es bei anderen geht bzw. was bei mir falsch laufen soll weiss ich nicht.
Gruß
So, Fehler ist gefunden (nach Suche im Quellcode).
Man muss bei der Definition eines itswitch in der config auf jeden Fall den nicht dokumentierten Parameter ITfrequency setzen, sonst passiert da garnix mit automatischem Frequenzwechsel.
Beispiel:
attr ELRO_WZ_Vitrine ITfrequency 433.920
Damit klappt dann tatsächlich auch die automatische Änderung der Frequenz und ich brauche in meinem Notify nur noch das Device per set an oder ausschalten.
Oder habt ihr , speziell @Zrrronggg! diesen Parameter nicht in Verwendung?
Würde mich wundern...
Ich muss dieses Attribut definitiv nicht spezifizieren ... aber: bei mir läuft der CUL im rfmode slowRF. Vermutlich ist das in dem Fall der entscheidende Unterschied.
Gruß, Peter
ich mach das auch nicht. Für mich gilt aber die selbe Einschränkung wie bei ph1959de.
Trotzdem komisch.
Wir können ja mal den Ersteller des IT Moduls fragen.
ich habe da auch so ein kleines problem in der richtung
ich habe ein COC und der ist auch auf 868 und homematic.
Er kann auch ohne die angabe von ITfrequency 433.920 meine IT-Steckdosen schalten. dies führt jedoch nach einer weile zu komplikationen (spätestens reboot pi so scheint mir) mit den homematic geräten (gehen auf missing ack irgend wann).
martinp876 sagte in einem anderen beitrag:
ZitatHM devics brauchen ein eigenes IO device. Es gibt keines, das einen Mischbetrieb mit HM kann.
und er hatte recht, seit dem ich die switche wieder aus fhem genommmen haben läuft alles stabil
evtl ist es garnicht gedacht das im HomeMatic -Mode andere sachen geschaltet werden, auch wenn es zufällig geht.
Zur Klarstellung: Ich habe den Cul auch im rfmode slowRf.
Woran es jetzt genau liegt, ich weiss es nicht.
Der Code vom IT Modul ist jedenfalls ziemlich eindeutig (falls ich Perl nicht komplett falsch interpretiere :)
## Do we need to change ITfrequency ??
if(defined($attr{$a[0]}) && defined($attr{$a[0]}{"ITfrequency"})) {
my $f = $attr{$a[0]}{"ITfrequency"}/26*65536;
...
Das if und somit das Umschalten wird nur durchgeführt, wenn ITfrequency defined ist.
Vielleicht ist es ja bei euch aus einem anderen Grund defined, ohne das es explizit angegeben wurde. Bei mir aber scheinbar nicht. Weil ich erst wie gesagt nach dem setzen von ITfrequency per attr überhaupt in dieses IF komme...
hallo leute,
falls es noch jemanden interessiert, folgendes zu attr ITfrequency.
mit meinem cul868 kann ich unabhängig vom attr itfrequency it-steckdosen schalten, egal ob homematic- oder slowrf-mode. meine tests mit itfrequency ergeben, dass man die it-standardfrequenz von 433.92 mhz mit diesem attribut zusätzlich noch pro device verändern kann. spasseshalber habe ich mal 433.888 mhz eingesetzt, womit ich folgenden log erhalte. da sieht man dann, dass itfrequency am schluss wieder auf 433.92 zurückgesetzt wird. vor und nach dem it schalten, ist mein cul immer auf 868.300 mhz.
2014.07.16 14:34:59.848 0: Setting ITfrequency (0D,0E,0F) to 10 b0 20 = 433.888 MHz
2014.07.16 14:34:59.851 5: SW:
2014.07.16 14:34:59.863 0: IT set IT01 on
2014.07.16 14:34:59.865 5: SW: isFF0000000FFF
2014.07.16 14:35:00.208 5: CUL/RAW (ReadAnswer): isFF0000000FFF
2014.07.16 14:35:00.211 0: Setting ITfrequency back to 433.92 MHz
2014.07.16 14:35:00.213 5: SW:
das umschalten der standardfrequenzen wird dann wohl in der culfw passieren. da habt ihr dann wohl unterschiedliche versionen gehabt. meine ist v1.58.
gruss frank