Basis:
- Selbstgebaute nanoCUL (nach Wiki), - Aptofun Nano V3 .0 + Neuftech CC1101 Wireless Module RF Transceiver Modul 387-464 MHz
Signalduino: V 3.3.1-RC10 SIGNALduino cc1101 - compiled at Dec 29 2018 01:43:10
FHEM auf RPi 3 - mit aktuellem Update am 17.2.2018.
- Somfy RTS Steuerung von 3 Rollos:
- define Shutter_timer_up DOIF ([{sunrise(0,"08:00","09:00")}])\
(set Shutter1 up)\
(set Shutter2 up)\
(set Shutter3 up)\
setuuid Shutter_timer_up 5c576d43-f33f-5c80-0696-844b46822a0b4324
attr Shutter_timer_up do always
attr Shutter_timer_up room Living_Room
attr Shutter_timer_up wait 0,5,5
Problem:Nach Ausführung des DOIFs, empfängt und sendet der Signalduino nicht mehr korrekt zB Tempsensor/IT Steckdose auf 433.920 MHz .
Auf "get sduino cconf" kommt "ccconf: freq:17.920MHz bWidth:812KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)"Auf "set sduino reset" oder "set sduino C1101_freq" empfängt und sendet der sduino wieder richtig.Mit Verbose 4 (für den sduino) sehe ich keine Fehlermeldung diesbezüglich.
Weitere Details können auf Anfrage gerne geliefert werden.
Bitte teste mal meine V 3.3.2.1-rc8, damit müsste der Fehler weg sein
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554
Gruß Ralf
Vielen Dank Ralf,
Das hat geklappt. Nach Ausführung der Somfy "Shutter_down" empfängt und sendet die Signalduino fröhlich weiter auf 433.920 MHz.
Ich werde noch im Laufe dieser Woche kontrollieren ob es immer so klappt - aber ich gehe davon aus.
Habe ich das richtig verstanden - bis auf weiteres brauche ich die FHEM Entwicklerversion dev-r33 ?.
Ich nehme an dass ich keinen normalen FHEM "Update" machen darf ?
Gruß Colin
Zitat von: CH_ULM am 18 Februar 2019, 10:00:32
Weitere Details können auf Anfrage gerne geliefert werden.
Bist Du dir sicher, dass die Version 3.3.1 RC10 auf dem Arduino gebrannt war?
Dieser Fehler wurde in RC9 behoben.
Das wundert mich nun doch sehr.
Grüße Sidey
ZitatHabe ich das richtig verstanden - bis auf weiteres brauche ich die FHEM Entwicklerversion dev-r33 ?.
Ich nehme an dass ich keinen normalen FHEM "Update" machen darf ?
Ja, momentan ist noch die Entwicklerversion dev-r33 notwendig. Demnächst kommt das dev-r33 ins normale FHEM update "v3.3.3 (stable release 3.3)", dann kann auch das normale FHEM update verwendet werden.
Gruß Ralf
ZitatBist Du dir sicher, dass die Version 3.3.1 RC10 auf dem Arduino gebrannt war?
Ja - ich hatte extra die neueste Version geladen in der Hoffnung dass es das Problem lösen würde.
Gruß Colin
Zitat von: CH_ULM am 18 Februar 2019, 20:26:24
Ja - ich hatte extra die neueste Version geladen in der Hoffnung dass es das Problem lösen würde.
Passiert das auch, wenn Du nur einen Rolladen fährst oder nur wenn Du mehrere über das Doif ansteuerst?
ZitatPassiert das auch, wenn Du nur einen Rolladen fährst oder nur wenn Du mehrere über das Doif ansteuerst?
Das war ok (denke ich) wenn ich nur einen Rolladen fahre - ohne DOIF. Ich hatte überlegt 30 s "wait" Zeit (>Hochfahrzeit) einzubauen - um zu sehen ob das eine Rolle spielt - habe ich aber nicht gemacht weil die Rolladen sollen eigentlich (fast) gleichzeitig hochfahren. (Ohne die 5s "wait", fahren oft nur zwei von drei Rolladen hoch.)
Gruß Colin
Zitat von: CH_ULM am 18 Februar 2019, 10:00:32
- define Shutter_timer_up DOIF ([{sunrise(0,"08:00","09:00")}])\
(set Shutter1 up)\
(set Shutter2 up)\
(set Shutter3 up)\
5
Kannst Du noch Details zur Definition Shutter1 liefern? Somfy Definitionen haben bei mir kein up Befehl.
Grüße Sidey
ZitatKannst Du noch Details zur Definition Shutter1 liefern? Somfy Definitionen haben bei mir kein up Befehl.
Zitatdefine Shutter1 SOMFY 12345F A1 00A1
setuuid Shutter1 5c54810d-f33f-5c80-533a-8e5286f1fd30fc49
attr Shutter1 IODev sduino
attr Shutter1 devStateIcon open:fts_shutter_10 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 down:fts_shutter_100 closed:fts_shutter_100
attr Shutter1 drive-down-time-to-100 23
attr Shutter1 drive-down-time-to-close 24
attr Shutter1 drive-up-time-to-100 4
attr Shutter1 drive-up-time-to-open 26
attr Shutter1 eventMap on:down stop:stop off:up
attr Shutter1 model somfyshutter
attr Shutter1 room Living_Room
attr Shutter1 webCmd down:stop:up
Habe die Definition aus fhem.cfg kopiert - hoffentlich ist das was du sehen wolltest...
Gruß Colin
Ralf,
Bis jetzt funktioniert die Somfy Steuerung weiter ohne Frequenz Probleme.
Eine Frage zu deiner FHEM SW:
ZitatJa, momentan ist noch die Entwicklerversion dev-r33 notwendig.
Kann man auch einen Jeelink (für LaCrosse) damit einbinden ?
Gruß Colin
Nein in die 00_SIGNALduino.pm kann man nur Hardware mit der Signalduino firmware einbinden.
ZitatJa, momentan ist noch die Entwicklerversion dev-r33 notwendig.
Seit heute ist die Entwicklerversion dev-r33 als "v3.3.3 (stable release 3.3)" im normalen fhem update (SVN) drin.
Eine Ursache für den Fehler den Du mit der 3.3.1 RC10 hattest, könnte ein unsauberer Hardwareaufbau sein.
Hast Du den 10K Widerstand von 3,3V auf CSN drin?
Gruß Ralf
Ralf,
ZitatHast Du den 10K Widerstand von 3,3V auf CSN drin?
Danke für den Hinweis.
Nein - nur der Spannungsteiler wie in WIKI Selbstbau CUL.
Ich kann aber die 10K zwischen CSN und 3,3V nachträglich einbauen - und nochmals probieren.
Ich melde mich dann wieder...
Gruß Colin
Ralf
ZitatSeit heute ist die Entwicklerversion dev-r33 als "v3.3.3 (stable release 3.3)" im normalen fhem update (SVN) drin.
Sorry - eine weitere Frage:
Ich sehe in UpdateCheck dass eine neue FHM SW verfügbar wäre.
Welche Signalduino SW soll ich jetzt einbauen :
a) zu testen ob die 10K Pullup was bringt.
b) um auf den neuesten Stand von heute zu sein
?
Danke
Gruß Colin
Zitat von: CH_ULM am 21 Februar 2019, 17:59:48
RalfSorry - eine weitere Frage:
Ich sehe in UpdateCheck dass eine neue FHM SW verfügbar wäre.
Welche Signalduino SW soll ich jetzt einbauen :
a) zu testen ob die 10K Pullup was bringt.
b) um auf den neuesten Stand von heute zu sein
?
Danke
Gruß Colin
Nimm die RC10, mit der habe ich gestern den Fehler nicht nachstellen können. Mein SIGNALduino ist auch ohne Pullup aufgebaut.
Wenn Du den Fehler immer noch hast, brauche ich mehr Details :)
ZitatIch sehe in UpdateCheck dass eine neue FHM SW verfügbar wäre.
Welche Signalduino SW soll ich jetzt einbauen
Du kannst auch die Module vom normalen Fhem update nehmen.
Momentan haben die Module vom normalen Fhem update den gleichen Stand wie die Entwicklerversion.
Gruß Ralf
Hallo Ralf,
seit 2 Tagen habe ich Version 3.3.1 RC10 auf dem Arduino. (Auch mit 10k ohm Pullup Widerstand von CSN auf 3,3V).
Gestern ging es mindestens einmal gut ohne dass die Frequenz verstellt wurde.
Heute morgen sehe ich dass beim Rolladen-hochfahren die Frequenz wieder auf 17.920MHz verstellt wurde.
Soll ich wieder die V 3.3.2.1-rc8 SW hochladen ?
Gruss Colin
Ja Du kannst wieder die V 3.3.2.1-rc8 nehmen, die läuft sehr stabil, mir sind da keine Probleme oder Ausfälle bekannt.
Der Fehler mit der verstellten Frequenz kommt nur sehr selten vor, bis jetzt sind mir erst ca 2-3 Fälle bekannt. Ich denke da passt irgendwas am Hardware aufbau nicht ganz. Vielleicht liegt es auch an Toleranzen oder am verwendeten cc1101 Modul.
Ich habe auch so ein signalduino wo ich diesen Fehler nachvollziehen konnte, dieser ist aber unsauber aufgebaut.
Gruss Ralf
Danke Ralf,
Mein nanoCUL sieht auch nicht hübsch aus - war nur ein "Breadboard" - die Verbindungen sind nicht besonders kurz.
Wenn ich Zeit habe, werde ich den mit möglich kurzen Verbindungen umbauen.
Die die V 3.3.2.1-rc8 war auf jeden Fall zuverlässig.
Läuft es auch weiterhin mit den normalen FHEM Versionen (tägliche Updates) ?
Gruß Colin
Ja, es funktioniert mittlerweile auch mit den normalen FHEM Versionen (tägliche Updates)
@Ralf9
Wenn es an der Hardware liegt, wieso soll die Software dann einen Unterschied machen?
Grüße Sidey
Zitatwieso soll die Software dann einen Unterschied machen
wie meinst Du das?
Meinst Du damit, daß die Software damit nicht zurecht kommen muss, wenn die Hardware unsauber aufgebaut ist?
Ich habe dich so verstanden, dass Du vermutest, dass es an einem "unsauberen" Aufbau der Hardware liegt.
Wenn das so wäre, wieso hat man das Problem dann nicht mit jeder Softwareversion?
Ich würde es so verstehen:
Es kann Unterschiede in der SW geben, die minimale Zeitverschiebungen der HW Ansteuerungen verursachen. So kann es vorkommen dass eine SW Version gut läuft aber eine Andere nicht, wenn zB. Störungen ungünstig aufeinander liegen.
Gruß Colin