Arduino Asksin library

[viegener]

Hi,

ich habe mir zwei Arduino Nanos geholt inkl. zwei echten 868 Funkmodulen. Pin 25 und 26 habe ich verbunden. HM_LC_SW4_BA_PCB auf den einen culf-520-trunk auf den anderen. Nach ein wenig hin und her hat das Pairing geklappt.

Manuelles Schalten der Zustände am HM_LC_SW4_BA_PCB inkl. korrekte Übertragung auf den CUL868 und FHEM klappt tadellos. Allerdings funktioniert die andere Richtung nur selten. Sprich schalten an FHEM resultiert in einen Schaltzustand am HM_LC_SW4_BA_PCB nur selten.

Wenn ich den CUL868 resette, sprich abziehe und wieder anstecke, dann funktioniert der erste Befehl eigentlich immer. Was auch immer funktioniert sind manuelle Schaltzustände an HM_LC_SW4_BA_PCB, die an den CUL868 übertragen werden.


Hat jemand einen Tipp für mich?

Wie hast Du denn den Sketch für den HM_LC_SW4_BA_PCB erzeugt?
Ich habe mich da ja auch nur eingelesen, deshalb kann ihc nur mit meinen begrenzten Erfahrungen helfen...

Aus dem Log seiht es so aus als ob auch das Senden des Status an FHEM von Deinem Device fast immer in einen Timeout läuft.
Ich habe jetzt die Schaltbefehle aus FHEM im Log noch nicht gesehen, so dass ich nicht erkennen kann, warum die nicht ankommen.

Hast Du mal das funktionierende Beispiel HM_LC_SW1_BA_PCB bei Dir mit diesen Funkmodulen zum Laufen bekommen?
Wenn das ebenfalls muckt, dann stimmt vielleicht doch etwas mit den Funkmodulen nicht?
Generell scheint er aber zu Senden und zu Empfangen (Sonst hätte ja auch das Pairing nicht geklappt)

[MBHG]

Hi Viegener,

Das sw4 habe ich so erzeugt wie hier in dem Thread beschrieben. Beim Dimmer Beispiel habe ich dasselbe Verhalten. Ich habe die neueste a-culf Version 1.20.

Kurios ist, dass beim Pairen b0meistens der CUL868 abstürzt. Die Leds blinken dann unglaublich schnell und er ist nicht zu erreichen. Funkübertragung ist ordentlich RSSI bei -40.

Beide Arduinos sind neu und lassen sich auch sauber flashen. Beide Funkmodule auch. Das sieht nach einem Softwarefehler aus. Warum sollte immer der erste Befehl klappen und die anderen nicht?

Seltsam. Erinnert mich an

http://forum.fhem.de/index.php/topic,44578.msg364031.html#msg364031

Dieselbe Library anderer Arduino, anderer cc1101, fast dasselbe Verhalten. Nur die Logfile Entries werden nicht 10000 fach gemacht.

Gruss

[viegener]

Hi Viegener,

Das sw4 habe ich so erzeugt wie hier in dem Thread beschrieben. Beim Dimmer Beispiel habe ich dasselbe Verhalten. Ich habe die neueste a-culf Version 1.20.

Kurios ist, dass beim Pairen b0meistens der CUL868 abstürzt. Die Leds blinken dann unglaublich schnell und er ist nicht zu erreichen. Funkübertragung ist ordentlich RSSI bei -40.

Beide Arduinos sind neu und lassen sich auch sauber flashen. Beide Funkmodule auch. Das sieht nach einem Softwarefehler aus. Warum sollte immer der erste Befehl klappen und die anderen nicht?

Seltsam.

Gruss

Das der erste Befehl klappt liegt häufig daran, dass der Homematic Device nicht aktiv auf eingehende Befehle wartet. Bei Sensoren z.B. ist häufig ein Modus vorhanden, dass sie zwar senden wenn etwas passiert aber Kommandos nur entgegennehmen, wenn der Prog-Button gedrückt ist. Die Erklärung wie hier im Forum beschrieben hilft da jetzt nicht wirklich weiter.

Deshalb meine Frage hat es mit dem Example-Sketch funktioniert?

Das der CUL schnell blinkt lässt darauf schliessen, dass der Watchdog (also die Überwachung ob der Arduino hängt) den Arduino neustartet. Bei Arduino-Nanos (aus China ?) führt das häufig dazu, dass diese nicht mehr Starten, das liegt wohl am Bootloader, aber das ist jetzt hier off-topic.

Achso: Der Dimmersketch ist nicht als Working markiert, ich habe ihn zwar bei mir zum Laufen bekommen, aber es gibt verschiedene Einschränkungen.

[MBHG]

Hallo Viegener,

vielen Dank. Ich habe mal den SW1 Beispielsketch geladen und gepairt. Beim Pairing hängt sich der CUL868 auf, sprich fängt an zu blinken und bleibt in diesem Status. Kann über FHEM nicht erreicht werden. Beim 2. Pairingversuch hat sich FHEM dann auch aufgehängt musste mit /etc/init.d/fhem stop abgeschossen werden.

Und ganz kurios: setze ich den CUL nicht in Pairingmodus stürzt er mir auch nicht ab. Das Device wird aber angelegt. Das ist wiederholbar.

Hier die Logs mit dem CUL in Pairingmodus:


Log des SW1

Code Auswählen Erweitern

HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMode: 0
initRly: 1

....
CC.
12...................................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00

<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1938)
<- 1A77
<- 1A 01 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (241737)
<- 1A77
<- 1A 01 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (397559)
10 77 E3 BE 6B 6F 4C 70 6F B4 90 69 45 21 FD D9 B0
x> 10 01 B0 01 F1 28 07 58 23 FF 00 05 00 00 00 00 00 (473517)
<- 0A77
<- 0A 01 80 02 58 23 FF F1 28 07 00 (473526)
10 77 E3 BE 6B 6F 4C 70 6F B4 90 69 45 21 FD D9 B0
x> 10 01 B0 01 F1 28 07 58 23 FF 00 05 00 00 00 00 00 (475153)
<- 0A77
<- 0A 01 80 02 58 23 FF F1 28 07 00 (475162)
10 77 E3 BE 6B 6F 4C 70 6F B4 90 69 45 21 FD D9 B0
x> 10 01 B0 01 F1 28 07 58 23 FF 00 05 00 00 00 00 00 (475469)
<- 0A77
<- 0A 01 80 02 58 23 FF F1 28 07 00 (475478)





List von HM_5823FF

Code Auswählen Erweitern

Internals:
   DEF        5823FF
   IODev      CUL_1
   NAME       HM_5823FF
   NR         98
   NTFY_ORDER 50-HM_5823FF
   STATE      ???
   TYPE       CUL_HM
   Readings:
     2016-01-25 19:15:22   D-firmware      1.0
     2016-01-25 19:15:22   D-serialNr      XMS1234567
     2016-01-25 19:15:22   R-pairCentral   set_0xF12807
   Helper:
     HM_CMDNR   1
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +5823FF,00,00,00
       prefIO
       rxt        0
       vccu
       p:
         5823FF
         00
         00
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
Attributes:
   IODev      CUL_1
   autoReadReg 4_reqStatus
   expert     2_full
   room       CUL_HM

[viegener]

Dazu fällt mir leider erstmal auch nichts ein.
Interessant wäre es ob der CUL868 denn mit Original-Homematic-Devices funktioniert (auch im Pairing)?

Johannes

[farion]

Hi,

gibt oder wird es ein Beispiel für den HM-LC-Sw1PBU-FM geben. Ich würde gerne die alternative Firmware austauschen. Mir geht es in erster Linie um AES, aber auch darum selbst das Verhalten ändern zu können. Z.B. möchte ich auf die Strommessung verzichten.

Gruss Frieder

[MBHG]

@Johannes,

danke. Original HM Aktoren habe ich leider nicht, aber folgendes herausgefunden:

1. wenn ich den nanoCUL mit 9600 Baud setze, funktioniert das Pairing deutlich besser
2. ich komme sogar soweit, dass ich bei SW4 die einzelnen Schalter schalten kann, wobei irgendwann der nanoCUL insofern aussetzt, dass er keine Kommandos mehr sendet
3. bei 38400 Baud passiert Punkt 2 viel schneller
4. Punkt 2 läßt sich durch abziehen des nanoCUL und wieder anstecken beheben, im Falle von 38400 Baud nur für 2 - 3 Befehle, im Fall 9600 auch schon mal für 10 Befehle
5. vor dem r-paircentral bekomme ich das set_ nicht weg

Code Auswählen Erweitern

switchRly: 4, 200
<- 0E5F
<- 0E 29 80 02 58 23 FF F1 28 07 01 04 C8 00 71 (570688)
0E 5A 86 73 BE B2 89 3D 3A E9 C7 A2 B6 92 B0
m> 0E 2C B0 11 F1 28 07 58 23 FF 02 01 C8 00 00 (669482)
switchRly: 1, 200
<- 0E5A
<- 0E 2C 80 02 58 23 FF F1 28 07 01 01 C8 00 6B (669496)
0E 5B 87 72 BF B3 88 3C 3B E8 C6 A0 B4 90 B0
m> 0E 2D B0 11 F1 28 07 58 23 FF 02 02 C8 00 00 (671884)
switchRly: 2, 200
<- 0E5B
<- 0E 2D 80 02 58 23 FF F1 28 07 01 02 C8 00 6A (671898)
0E 58 84 71 BC B0 8B 3F 38 EB C5 A2 B6 92 B0
m> 0E 2E B0 11 F1 28 07 58 23 FF 02 03 C8 00 00 (674315)
switchRly: 3, 200
<- 0E58
<- 0E 2E 80 02 58 23 FF F1 28 07 01 03 C8 00 6A (674329)
0E 59 85 70 BD B1 8A 3E 39 EA C4 A3 7F 5B B0
m> 0E 2F B0 11 F1 28 07 58 23 FF 02 03 00 00 00 (676266)
switchRly: 3, 0
<- 0E59
<- 0E 2F 80 02 58 23 FF F1 28 07 01 03 00 00 6A (676279)
0E 46 92 7F AA AE 8D 31 2E F5 D3 AD 89 65 B0
m> 0E 30 B0 11 F1 28 07 58 23 FF 02 02 00 00 00 (677851)
switchRly: 2, 0
<- 0E46
<- 0E 30 80 02 58 23 FF F1 28 07 01 02 00 00 6A (677864)
0E 47 93 7E AB AF 8C 30 2F F4 D2 AF 8B 67 B0
m> 0E 31 B0 11 F1 28 07 58 23 FF 02 01 00 00 00 (680037)
switchRly: 1, 0
<- 0E47
<- 0E 31 80 02 58 23 FF F1 28 07 01 01 00 00 6A (680050)
0E 44 90 7D A8 AC 8F 33 2C F7 D1 A9 85 61 B0
m> 0E 32 B0 11 F1 28 07 58 23 FF 02 04 00 00 00 (682313)
switchRly: 4, 0
<- 0E44
<- 0E 32 80 02 58 23 FF F1 28 07 01 04 00 00 6B (682326)
0E 45 91 7C A9 AD 8E 32 2D F6 D0 A8 4C 28 B0
m> 0E 33 B0 11 F1 28 07 58 23 FF 02 04 C8 00 00 (684121)
switchRly: 4, 200
<- 0E45
<- 0E 33 80 02 58 23 FF F1 28 07 01 04 C8 00 6A (684135)


Gruss Marc

[viegener]

@Marc: Ich denke all das was Du beschreibst klingt danach, dass es nicht (unbedingt) ein Softwareproblem ist. Vielleicht ist doch etwas bei Deinen Komponenten / Hardware defekt. Wenn die Arduinos aussetzen, würde ich mal versuchen, einen davon durch ein anderes Modell aus einer anderen Quelle zu erstzen. Ebenso das Funkmodul, wenn der Arduino nicht das Problem ist. Vielleicht gibt es auch ein Problem mit der Stromversorgung?

Wie gesagt alles eigentlich nur Spekulation, aber wenn es sowohl Probleme beim nanoCUL wie beim Asksin-Device gibt, dann würde ich die Teil einzeln versuchen auszutauschen, um das problem einzugrenzen/Teile auszuschliessen

Johannes

[MBHG]

@Johannes

danke für Deinen Input. Systematisches Vorgehen ist immer gut, niemals mehr als eine Komponente ändern.

Ich bin an dem Thema seit Mitte November dran, mit 8 wöchiger Auszeit wg. Lieferdauer der Komponenten, alles in allem bestimmmt 100 Stunden. Ich hatte schon verschiedene Arduinos / CC1101 im Einsatz, unter anderem einen UNO und einen CC1101 (868/433) und aktuell einen Nano mit einem echten CC1101 868. Alle Komponenten haben eigentlich eines gemeinsam: beim Pairing stürzt der CUL ab, in einem Fall sogar FHEM

http://forum.fhem.de/index.php/topic,44578.msg364031.html#msg364031

Als Software habe ich a-culfw wie culfw gestestet. Als Hardware habe ich einen Linux Recher und auf der Asksin / SW4 Seite einen Windows Rechner.

Ich muss mich nochmal daransetzen, wenn ich wieder Zeit habe....

Gruss Marc

[viegener]

@Marc: Ich verstehe den Frust, wenn man Stunden und Tage investiert und keinen Schritt einer Lösung näherkommt!

Wenn Du bei einem der Usertreffen in KA/FRA bist, könnte man mal versuchen Komponenten auszutauschen oder sogar lokal Tests mit anderen Komponenten zu machen.

[MBHG]

@Johannes,

danke. Super Idee mit dem Usertreffen.

Hatte gestern ein wenig Zeit. Habe nochmals alle Verbindungen nachgelötet und alles geprüft. Das Verhalten des nanoCULs auf FHEM Seite ist eigentlich ziemlich simpel:

- Beim Pairen hängt sich der nanoCUL auf, sprich, schnelles Blinken der LED. Es hilft nur ausstecken und wieder einstecken. Es waren wohl noch ein paar Befehle in der Queue, da er nach dem Einstecken den Pairingversuch weiter fortgesetzt hat
- SW4 hat die Masterid akzeptiert und reagiert auch auf Schaltbefehle. Diese werden auch bestätigt und vom nanoCUL verarbeitet. Manchmal hängt sich der nanoCUL nach dem Schalten (!) aber auf (schnelles Blinken der LED), die Bestätigung kann er nicht mehr verarbeiten.

Bin fast versucht einen neuen Bootloader drauf zu setzen, behandelt aber aus meiner Sicht nur ein Symptom.

Gruss

[viegener]

Das schnelle Blinken spricht für watchdog oder brownout
Also neuer Bootloader löst vermutlich wirklich nicht das Problem, denn dann würde er vermutlich nur nach dem Reset wieder hochkommen...

Weisst Du zufällig wie die Fuses am Arduino für Unterspannung gesetzt sind?
Kann es sein, dass die Spannungsversorgung ein Problem macht (oder hatten wir das schon behandelt)?

Johannes

[Dirk]

Hallo zusammen,

aus Zeitgründen hab ich mich die letzte Zeit etwas zurück gehalten.
Ich werde aber auch in Karlsruhe sein. Ggf. können wie uns dann etwas austauschen.

Viele Grüße
Dirk

[MBHG]

Hi Johannes,

danke. Hatte in den letzten Tagen einiges zu tun. Spannungsversorgung vermutlich nicht, das hatten wir schon, ein anderer CUL 433 läuft an demselben USB Port seit Monaten ohne Probleme. Melde mich in 1 1/2 Wochen.

Gruss

Marc

[borney]

Hallo,

beim Lesen des Threads ist mir die Frage nach der Verwendung eines analogen Eingangs aufgefallen, für die ich keine Antwort gefunden habe. Mich würde interessieren, ob jemand eine Lösung gefunden, bzw. etwas entwickelt hat, womit ein oder mehrere analoge Eingänge abgefragt werden können. Ich habe noch ein paar Panstamps ohne Aufgabe, die ich gerne im Gartenhaus zur Spannungsüberwachung des Solarpanels und des daran angeschlossenen Akkus verwenden würde. Auch habe ich daran gedacht, einen modifizierten HM-WDS30-OT2-SM Differenz-Temperatur-Sensor zu verwenden, aber die nicht lineare Kennlinie der Temperatursensoren machen die Umsetzung schwierig. Leider blicke ich nicht genug bei der Asksin lib durch um eine eigene Idee zu kreieren.

Grüße

Borney