Intertechno Steckdose ITR-1500 Unit 0001 an Signalduino schaltet nicht immer

[venice]

Hallo zusammen,
dieses ist mein erster Post in diesem Forum, deshalb als erstes ein "Hallo an Alle" 
und Danke für die tolle Software, macht riesig Spaß.

Ich nutzte das Intertechno Funksteckdosen Set IT-1500 mit FHEM 5.7 & Signalduino v3.3.0 und habe zwecks separater Nutzung
von Sender (ITT-1500) und Steckdosen (ITR-1500) den Steckdosen einen eignen Systemcode beigebracht.
Zwei (Unit 0000 und 0010) der drei Steckdosen funktionieren ohne Probleme, nur eine (Unit 0001) mag nicht immer.
Ca. 50% der FHEM Schaltvorgänge kommen nicht an.
Erst dachte ich das liegt an der räumlichen Position, das war's aber nicht.
Dann habe ich die Steckdosen mit dem Sender angelernt und die "Autocreate"ed FHEM Schalter des Senders getestet, auch hier zickt die Unit 0001.
Die beiden anderen funktionieren ohne Probleme.   

Zum weiteren testen habe ich der "zickigen" Steckdose einen weiteren zusätzlichen Systemcode als Unit 0000 angelernt, damit schaltet die Steckdose ohne Probleme.
Ich habe die Steckdosen zusätzlich noch mit meinen alten PI1 und einem GPIO Sender mit Pilight getestet, auch hier, keine Probleme.

FHEM habe ich vor dem Post nochmals geupdatet und den Signalduino frisch von 3.2.0b12 auf 3.3.0 geflasht.
Ich hatte das Gefühl das mit dem update des Signalduino das Verhalten der zickigen Steckdose besser geworden wäre.

Vielleicht kennt ja jemand das Problem oder hat eine Idee ?!
Man könnte ja z.B. allen Steckdosen einen eigenen Systemcode als Unit 0000 verpassen.

Viele Grüße
Lars

[Sidey]

Wie bringt man denn den Steckdosen einen eigenen Systrmcode bei, dann Stelle ich das mal nach.

Grüße Sidey

[venice]

Hi Sidey,
erst einmal Danke für die ganze Mühe die Du Dir machst.

Ich bin über Pilight und Pimatic zu FHEM gekommen.
In Pilight werden die Systemcodes (oder ID) Dezimal abgebildet.
Wenn ich diese Codes dann als 26 stellte Binärzahl darstelle passt das auch mit FHEM.
Ich habe meine Steckdosen mit pilight-send "bespielt".
=intertechno]https://wiki.pilight.org/doku.php/arctech_switch_v7_0?s[]=intertechno
Dazu bietet pilight-send bei dem "intertechno_switch" Protokoll die Option "-l" fürs anlernen.

Aktuell nehme ich dazu meinen alten PI1 mit einem 433Mhz Sender am GPIO.

Ich schick später ein paar Bespiele.
Danke
Lars

[venice]

...und hier meine Beispiele.
Die Nummer hinter -i hab ich mir einfach ausgedacht.

Code Auswählen Erweitern


Training --on -l zum lernen
pilight-send -p intertechno_switch -i 31577822 -u 0 --on -l
pilight-send -p intertechno_switch -i 31577822 -u 1 --on -l
pilight-send -p intertechno_switch -i 31577822 -u 2 --on -l

Training --off -l zum vergessen
pilight-send -p intertechno_switch -i 31577822 -u 0 --off -l
pilight-send -p intertechno_switch -i 31577822 -u 1 --off -l
pilight-send -p intertechno_switch -i 31577822 -u 2 --off -l

Meine neuer Code für Unit 1 (2a bei FHEM) weil Unit 1 (0001 bei FHEM) nicht geschaltet wird
pilight-send -p intertechno_switch -i 34533366 -u 0 --on -l


Viele Grüße
Lars

[skydns]

Hey Venice,
ich habe das gleiche Problem. Um deinen Beitrag zu finden musste ich lange suchen. Bei mir funktionierte mit pilight auch alles wunderbar und mit dem Signalduino habe ich genau das von dir
beschriebene Problem mit den Codes die mit 0001 enden.
Ich habe 4 Steckdosensets von IT1500 im Einsatz.

Hast du inzwischen eine Lösung für das Problem gefunden?

Ich behelfe mir aktuell mit dem mehrfachen Senden des Befehls um die Zuverlässigkeit zu erhöhen, glücklich bin ich mit der Lösung jedoch nicht.
Ich habe den Fehler etwas eingrenzen können und bin nun soweit zu sagen, das es nicht an der Hardware liegt. Sondern ein Fehler in der Firmware sein könnte oder ein Parametrierfehler.

Auch die anderen beiden Codes mit 0000 und 0010 schalten nur zu 95% zuverlässig.

Ich habe vorher z.B. den Code D1 zum schalten benutzt über den CUL868
für die Weihnachtsbeleuchtung. Das hat im Winter zu 100% funktioniert und die Steckdosen ließen sich sogar damit anlernen.

Den Fehler den du beschreibst hab ich beim senden mit 2 Signalduino, sowie mit dem CUL868. Fehlerbild ist jeweils identisch, daher will ich an dieser Stelle die Hardware ausschließen.

Gruß Marco

[venice]

Hi Marco,

ich habe das gleiche Problem. Um deinen Beitrag zu finden musste ich lange suchen. Bei mir funktionierte mit pilight auch alles wunderbar und mit dem Signalduino habe ich genau das von dir
beschriebene Problem mit den Codes die mit 0001 enden.
Ich habe 4 Steckdosensets von IT1500 im Einsatz.

Hast du inzwischen eine Lösung für das Problem gefunden?

Ich behelfe mir aktuell mit dem mehrfachen Senden des Befehls um die Zuverlässigkeit zu erhöhen, glücklich bin ich mit der Lösung jedoch nicht.
Ich habe den Fehler etwas eingrenzen können und bin nun soweit zu sagen, das es nicht an der Hardware liegt. Sondern ein Fehler in der Firmware sein könnte oder ein Parametrierfehler.

Auch die anderen beiden Codes mit 0000 und 0010 schalten nur zu 95% zuverlässig.

...eine Lösung hab ich nicht gefunden aber einen Workaround.

Ich habe einfach der Steckdose mit dem Unitcode 0001 einen zusätzlichen eigenen Systemcode mit Unitcode 0000 angelernt.
Klappt mit Signalduino FW 3.3.0 ohne Probleme bei mir.

Noch besser funktionieren die Steckdosen mit einem NanoCul 433 Mhz den ich mit der normalen FW im Einsatz habe.
Auch die mit dem Unitcode 0001 

Viele Grüße
Lars

[skydns]

Lang ist es her, doch das Thema hat mich einfach nicht in Ruhe gelassen. Ich bin nun auf den SelbstbauCUL / nanoCUL umgestiegen. Nachteil ist das ich nun die Temperaturen der Wetterstationen nicht mehr empfange aber das Senden ist mir wichtiger.

EDIT: Ich habe jetzt die a-culfw geflasht (V 1.24.02 a-culfw), nun Empfange ich meine Wetterstation auch wieder.

Nach dem ich mir den SelbstbauCUL gebaut habe, funktionierte das Senden zu 99,9%. Nachdem ich dann meine Einstellungen vorgenommen habe lag die Zuverlässigkeit wieder nur bei 80% wie beim Signalduino. Merkwürdig und ich weiß auch keine Begründung dafür, habe aber herausgefunden woran es zumindest beim SelbstbauCUL liegt.
Ein interessantes Phänomen, ich konnte das Problem wie folgt lösen:
(Hat nur beim SelbstbauCUL geholfen nicht beim Signalduino, da habe ich es dann auch gleich noch mal getestet.)

Da mich das regelmäßige Blinken der LED stört habe ich es mit set nanoCUL raw l01 abgeschaltet. Ich will ja schließlich nur sehen, wenn etwas gesendet oder empfangen wird. Danach funktionieren die Steckdosensignale nur noch zu 80%.
Wenn man nun wieder set nanoCUL raw l00 sendet ist die Zuverlässigkeit wieder bei 99,9%. Das regelmäßige Blinken ist trotzdem aus.

Bei mir hat es geholfen, ich habe es mit zwei SelbstbauCUL getestet.

Gruß Marco

[KölnSolar]

finde ich interessant Deine Analyse. Könnte so manch einem bei Empfangsproblemen helfen bzw. zu einer notwendigen Änderung in culfw/aculfw führen.

Hab Dich aber auch noch nicht zu 100% verstanden:
00: Set LED off  -  alles OK
01: Set LED on  -  Empfangsprobleme
02: The LED will blink once a second   - alles OK ??

culfw kannst Du ja leider nicht zum Vergleich testen, weil damit kein ITV3 Empfang geht 

Eigentlich ist der winzige Unterschied zw. l00 u. l01, dass in der receive.h in Zeile 370 die LED vor der Analyse von bereits empfangenen Paketen eingeschaltet wird. Nun spekuliere ich, dass die LED dem Empfänger etwas Strom "wegnimmt" oder zu solch einer Verzögerung führt, dass die wiederholten Pakete nicht mehr empfangen/als solche erkannt werden ==> beschriebene Symptomatik.

Du könntest mal die aculfw ohne Zeile 370 compilieren und/oder den nanoCUL über eine stabilere Spannungsversorgung sprich aktiver USB-Hub versorgen, um der Ursache näher zu kommen.

[as57]

Moin
bin neu dazugestoßen - FHEM erscheint sehr vielversprechend aber auch seeehr Freizeit neutralisierend.
Ich hänge mich mal an diese Herausforderung dran, da sie auch meine ist.
Habe nach tagelanger Fehlersuche und diverser Hardwareevaluierung diesen Beitrag und weitere gefunden u.a.:
https://forum.fhem.de/index.php/topic,79019.msg710073.html
https://github.com/RFD-FHEM/RFFHEM/issues/109
eine Lösung des Problems ist scheinbar nicht angedacht!?
Da ich mehrere FB ITT-1500 mit je drei Kanälen in mehreren Szenarien verwende ist der workaround suboptimal.
Kann man den Entwicklern irgendwie helfen? z.B. beim Testen
Gruß
Andreas

[Sidey]

Hi bezüglich des Bugs im Signalduino, wenn es denn einer ist....

Wenn Du mir sagst, wie ich eine Funksteckdose auf genau den fehlerhaften Code konfiguriere dann kannst Du mir helfen

Bislang kann ich den Fehler einfach nicht nachstellen


Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

[skydns]

Moin Moin,

der Code, der die meisten Probleme macht ist bei mir dieser:
00010111111111100010001010 0 0001
Das entspricht auf der Fernbedienung dem B-Kanal. Interessant ist auch, das die Fernbedienung selbst manchmal nicht erkannt wird.
Ich denke drüber nach das Set einfach zu Ersetzen...
Ich habe noch zwei weitere IT-1500 Sets, bei denen läuft es sauber. Hier viel Zeit in die Fehlersuche zu stecken scheint mir überflüssig.
Gruß Marco

[as57]

Moin

Danke für die Antworten und die tolle Community.

meine fehlerhaften Codes, die ich zur Hand habe:
00011000010011100000101110 0 0001
00010100011110110100100010 0 0001   
enden auf 1
Habe mein System umgestellt, um das zu vermeiden.
Die mittlere ON-Taste meiner ITT-1500 (FB) senden einen Code, der auf 1 endet!
Auch von meinem ITZ-500 (Timer/FB) werden solche Codes gesendet.
Thema für mich erledigt. Danke.

Gruß
Andreas