[gelöst] Selbstbau Cul - a-culfw nach Sendevorgang kein Empfang mehr möglich

[dtavb]

Hi Ihr,

ich lese schon seit einiger Zeit im Forum mit. Ich bastel an einer Heimautomatisierung, relativ einfach Fhem auf Pi3, ein Funksender (billiges Modul) angedockt und los gehts.
Soweit so gut.

Dann habe ich mir eher aus Unwissenheit den TT-C1101 bestellt und erst später realisiert, dass ich einen arduino dazu benötige (zumindest suggerieren mir das die ganzen HowTos).
Ein paar Wochen (China) später und ich habe nodemcus, esp8266, arduino uno.

Mein aktuelles Projekt wäre:
arduino uno r3 mit dem TT-C1101 zu verheiraten, an den pi3 mit fhem anstecken und los gehts mit Schaltung

Soweit habe ich den uno r3 mit dem nanoCUL flashen können.
Es gibt ja in der a-culfw repository noch CUL-Arduino, das schaffe ich allerdings nicht - finde auch nicht wirklich den Hinweis ob ich auf dem richtigen Weg bin überhaupt CUL-Arduino flashen zu müssen.

Jedenfalls mit dem nanoCUL von a-culfw erreiche ich zumindest ein Empfangen und ein Senden. Ziel erreicht, dachte ich.

Leider nicht:
Sobald ich 1x ein Sendenbefehl absetze, stellt der selbstbau Cul seinen Dienst für den Empfangsmodus ein.

Im Log sieht es so aus:
Empfang geht ein
Senden geht raus
Kein Empfang mehr (im Log mit verbose 5 auf Objekt "nanoCul" sowie "IT_1527x6ea11" und Objekt "global")

Bilder:
fenstersensor: Screeni aus Fhem
nanocul: Screeni vom Cul

==========Empfang vom Fenstersensor==================
2017.01.14 13:59:50 5: CUL/RAW: /i6EA11EF1
2017.01.14 13:59:50 4: CUL_Parse: nanoCUL i6EA11EF1 -81.5
2017.01.14 13:59:50 5: nanoCUL: dispatch i6ea11e
2017.01.14 13:59:50 4: nanoCUL IT: message "i6ea11e" (7)
2017.01.14 13:59:50 4: nanoCUL IT: msgcode "" (0) bin = 011011101010000100011110
2017.01.14 13:59:50 5: nanoCUL IT: EV1527 housecode = 1527x6ea11  onoffcode = 1110
2017.01.14 13:59:50 3: nanoCUL IT: IT_1527x6ea11 on->on
2017.01.14 13:59:50 5: Triggering IT_1527x6ea11 (1 changes)
2017.01.14 13:59:50 5: Starting notify loop for IT_1527x6ea11, 1 event(s), first is on

============= Klick auf Symbol für Funktsteckdose =====================================
2017.01.14 13:59:55 4: WEB_192.168.192.109_56536 POST /fhem?cmd.test2=set%20test2%20on&room=all&XHR=1&fw_id=42; BUFLEN:0
2017.01.14 13:59:55 5: Cmd: >set test2 on<
2017.01.14 13:59:55 2: nanoCUL IT_set: test2 on
2017.01.14 13:59:55 5: Triggering test2 (1 changes)
2017.01.14 13:59:55 5: Starting notify loop for test2, 1 event(s), first is on
2017.01.14 13:59:55 5: nanoCUL IT_set: Type=CUL Protocol=V3
2017.01.14 13:59:55 5: SW: is00001111000011110000111111010000
2017.01.14 13:59:55 5: CUL/RAW (ReadAnswer): is0000111100001
2017.01.14 13:59:55 5: CUL/RAW (ReadAnswer): 1110000111111010
2017.01.14 13:59:55 5: CUL/RAW (ReadAnswer): 000

========== keine Ahnung was das ist, vermutlich hängt es noch mit der Steckdose zusammen====================
2017.01.14 13:59:55 5: Triggering nanoCUL (1 changes)
2017.01.14 13:59:55 5: Starting notify loop for nanoCUL, 1 event(s), first is raw: is00001111000011110000111111010000
2017.01.14 13:59:55 5: IT_Set: GetFn(raw): message = is00001111000011110000111111010000 Antwort =   raw => is00001111000011110000111111010000
2017.01.14 13:59:55 4: ITSet: Answer from nanoCUL:   raw => is00001111000011110000111111010000
2017.01.14 13:59:55 4: name: /fhem?cmd.test2=set%20test2%20on&room=all&XHR=1&fw_id=42 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
============= Hier löse ich den Fenstersensor aus  ===================

kein Eintrag im Log/event-Monitor

=============  ich aktualisiere den Event ===================
2017.01.14 14:00:04 4: WEB_192.168.192.109_56536 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2017-01.log; BUFLEN:0
2017.01.14 14:00:04 4: Connection closed for WEB_192.168.192.109_56526: EOF
============= Ende des Tests ===================

Das Empfangsgerät:
Ein Tür/Fenster Sender von Hersteller "keine Ahnung, aus China"
Mit autocreate wird das Objekt auch angelegt: siehe fenstersensor
Mir kommt es jetzt erstmal nur darauf an, überhaupt mal regelmässig was zu empfangen und zu senden.
Das "schön"-machen, kommt später.

Ergebnis bisher:
Starte ich den selbstbau Cul neu, funktioniert der Empfang wieder solange, bis ich wieder einen Sendeauftrag zu einer Steckdose gebe.

komischerweise habe ich das gleiche Verhalten bei a-culfw wie mit der aktuellen culfw.
Empfang geht, solange bis ich mal was sende.

Ich möchte gerne diesen selbstbau Cul anstelle des billigen RF Sender direkt an dem pi3 betreiben.
Ein Transceiver wäre einfach cool mit senden und empfangen.

Kann mir da jemand helfen?

Danke Euch und viele Grüsse,
dtavb



bisheriger Projektumfang:
4 wifi-Steckdosen
4 IT-Steckdosen, selbstlernend
LG WiFi TV
selbstgebastelter PIR Sensor
Terrariumschaltung (nur zeitgesteuert)
Wifi LED Controller aus China an fhem angedockt
Bluetooth Multisystem an pi3 angedockt, aber noch nichts sinnvolles damit getrieben
snmp-gets ausgearbeitet um pi3 den DHCP-Server abzufragen ob zB mein Smartphone im Netz ist (aber noch nichts mit der Info weitergemacht)

[bjoernh]

Hast du bei den Dosen das it repeat verändert?

Gesendet von meinem Mobile Device.

[dtavb]

Oo , musste gerade mal schnell gucken was Du meinen könntest,evt.  ITrepetition?
Also bewusst habe ich nichts in diese Richtung verändert verändert.

bzw. ich benutze einen Test-Fhem auf einem 2. pi3.
Den "produktiven" pi3 mit billig-RF Sender belasse ich erst mal solange bis ich das im Labor hinbekomme

Die Logs und Settings sind demnach aus meinem "Labor" pi3, aktuelles jessie image: 1 IT Dose, 1 Uno R3 und den C1101 mit Antenne.

Eine neue IT Dose habe ich versucht mit dem selbstbau CUL zu steuern, das klappt auch nicht.
Sehe zwar LEDs (RX/TX) auf dem Uno R3 leuchten, die Dose reagiert aber nicht.
Das ist auch gar nicht tragisch, Fokus liegt auf dem Verhalten mit dem Empfang und Senden.
Das mit der neuen IT Dose bekomme ich noch hin...

Als Screeni habe ich aber auch mal das Objekt der Dose hinzugefügt. Diese wurde von mir von Hand angelegt:
define test2 IT 00001111000011110000111111 0 0000
attr test2 IODev nanoCUL
attr test2 model itswitch
Zuerst hatte ich es mit dem autocreate getestet (IT Fernbedienung gedrückt und Fhem hat via autocreate alles automatisch gemacht).
Beim hin und her testen was wohl besser ist, dann bemerkt dass der Empfang nicht mehr geht.
Seitdem habe ich mich auf den Empfang konzentriert und das mit den Test-Dose auf Prio2 gesetzt.

[bjoernh]

Oo , musste gerade mal schnell gucken was Du meinen könntest,evt.  ITrepetition?
Also bewusst habe ich nichts in diese Richtung verändert verändert.

bzw. ich benutze einen Test-Fhem auf einem 2. pi3.
Den "produktiven" pi3 mit billig-RF Sender belasse ich erst mal solange bis ich das im Labor hinbekomme

Die Logs und Settings sind demnach aus meinem "Labor" pi3, aktuelles jessie image: 1 IT Dose, 1 Uno R3 und den C1101 mit Antenne.

Eine neue IT Dose habe ich versucht mit dem selbstbau CUL zu steuern, das klappt auch nicht.
Sehe zwar LEDs (RX/TX) auf dem Uno R3 leuchten, die Dose reagiert aber nicht.
Das ist auch gar nicht tragisch, Fokus liegt auf dem Verhalten mit dem Empfang und Senden.
Das mit der neuen IT Dose bekomme ich noch hin...

Als Screeni habe ich aber auch mal das Objekt der Dose hinzugefügt. Diese wurde von mir von Hand angelegt:
define test2 IT 00001111000011110000111111 0 0000
attr test2 IODev nanoCUL
attr test2 model itswitch
Zuerst hatte ich es mit dem autocreate getestet (IT Fernbedienung gedrückt und Fhem hat via autocreate alles automatisch gemacht).
Beim hin und her testen was wohl besser ist, dann bemerkt dass der Empfang nicht mehr geht.
Seitdem habe ich mich auf den Empfang konzentriert und das mit den Test-Dose auf Prio2 gesetzt.

Eigentlich ist es unlogisch.  Das senden hat mit dem empfangen nichts zu tun.
Schalte mal den cul auf raw X25 wenn er nichts empfangen tut.  Es müssten dann Ausgaben erscheinen.

Gesendet von meinem Mobile Device.

[dtavb]

Hi, ne mit X25 geschieht gar nichts, fhem ist gestoppt. Weder via mini screen oder minicom erhalte ich bei X25 etwas zurück.
Wenn ich V eingebe, erhalte ich die Firmware. Demnach geht die Konsole mal grundsätzlich.
Tippe ich einen unbekannten Befehl ein, kommt auch die entsprechende Meldung.
Ausser V geht nicht wirklich viel, was mich schon stutzig macht.
Habe Gestern noch etwas getestet und gespielt, nachdem ich die Referenz zum CUL gelesen hatte.

Mit den UnoR3 habe ich kein Problem oder?
Habe zur Sicherheit mal den nano bestellt, man weis ja nicht.
Laut Vergleichsseiten, unterscheiden sich die beiden in den analogen Eingängen und Frequenz - wegen Verkabelung denke ich.

Kurios ist das Verhalten, vor allen Dingen dieser "schöne" Zustand nach Restart des selbstgebastelten CUL

[dtavb]

Hoi,
nachdem ich einen nano benutzt habe, funktioniert das System einwandfrei.
In der Tat lag es am Uno R3.
Grüsse,
dtavb

[Trinidad]

Halle ich auch mal. Ich denke es hatte was mit Fehlspannungen zu tun. Deswegen habe ich meine Selbstbau CUL spannungstechnische optimiert. Hier mein Blogbeitrag dazu: http://tips-und-mehr.de/cul-selbstbau-spannungstechnisch-auf-der-sicheren-seite/