Fensterdrehgriffkontakt selber bauen

[papa]

OTA mit Batterie hat bei mir nicht funktioniert. Erst am ArduinoISP hat es geklappt.

Was heisst nicht funktioniert ? Wurde das Image komplett übertragen ? Gab es Fehler während der Übertragung ? Auch wenn der Vorgang dann weiter geht, muss meistens der Vorgang wiederholt werden. Manchmal braucht es auch ohne Fehler 2-3 Versuche, ehe es dann geht. Das ist zumindest meine Erfahrung.

[habeIchVergessen]

es gab zu viele Fehler während der Übertragung (flash-ota). Spätestens nach Block 30 war Schluss (missing ack).

Ich habe auch versucht, per fhem zu flashen (hatte nur den Bootloader per ISP geflasht). ist das beschriebene Vorgehen richtig?

Code: [Auswählen]

define <device> CUL_HM <HM0000>
attr <device> model HM-SEC-RHS
attr <device> serialNr RHS0000000
attr <device> subType threeStateSensor

set <device> fwUpdate onlyEnterBootLoader
set <device> fwUpdate avr_HM_SEC_RHS_201706132157.eq3


[UweH]

Kannst Du nach dem Auswechseln der Firmware bitte nochmal neu pairen.

Habe ich gemacht, es kam aber einmal (bei mehreren Versuchen) vor, dass auch da nach dem ersten Schalten der Kontakt wieder abbrach. Nach erneutem pairen funktionert es nun seit gestern.
Aber generell ist es so, dass ich die Register vor dem ersten Schalten ändern muss. Das betrifft im Moment aber (wahrscheinlich) nur mich, daher irrelevant für die Allgemeinheit.
Da es aber prinzipiell funktioniert, ignoriere ich das erst mal.

Manchmal braucht es auch ohne Fehler 2-3 Versuche, ehe es dann geht. Das ist zumindest meine Erfahrung.

Die Erfahrung habe ich nun nach gefühlt 100maligem OTA-flashen auch gemacht. Wie im Wiki beschrieben, spielt die Entfernung zwischen Griff und CUL eine Rolle (ich habe die meisten Griffe in einer Entfernung von ca. 1 1/2m zum CUL flashen können, einer brauchte 4m Entfernung...).
Bei manch einem musste ich bis zu 10x ansetzen, um die Firmware übertragen zu können. Ein Grund mehr, das Ding komplett per ISP brennen zu können

Gruß
Uwe

[papa]

Ein Grund mehr, das Ding komplett per ISP brennen zu können

Oder HMUART umzusteigen

[Wzut]

Ich benötige mal etwas Hilfe von einem HM Guru.... Habe eine bestückte Platine von Joschi2009 bekommen auf der die FW schon drauf war.
Mein Versuch diese bei mir einzubinden :
Meine VCCU  in Paiiring Modu gebracht und config gedrückt - keine Reaktion , bzw. kein neues HM Device
Nächster Versuch : die VCCU direkt mit der serial FHEM200001 gepairt - Erfolg , Device vorhanden.
Danach noch ein paar mal den Config Taster gedrückt bis keine CMDs mehr pending waren.
Wenn ich jetzt VCC mit A0 oder A1 verbinde/löse blinken kurz die LEDs und in FHEM wird das Device als alive angezeigt, soweit gut , aber :
Ich bekomme keinen STATE (nur 3 Fragezeichen) Hier mal das list :

Code: [Auswählen]

Internals:
   CFGFN
   CUL_Cube_MSGCNT 12
   CUL_Cube_RAWMSG A0E2F80101FFFF12309600100000000::-79.5:CUL_Cube
   CUL_Cube_RSSI -79.5
   CUL_Cube_TIME 2017-07-01 19:45:25
   DEF        1FFFF1
   HmUART_MSGCNT 12
   HmUART_RAWMSG 0501003C2F80101FFFF12309600100000000
   HmUART_RSSI -60
   HmUART_TIME 2017-07-01 19:45:25
   IODev      HmUART
   LASTInputDev CUL_Cube
   MSGCNT     24
   NAME       Fenster1
   NOTIFYDEV  global
   NR         545
   STATE      ???
   TYPE       CUL_HM
   lastMsg    No:2F - t:10 s:1FFFF1 d:230960 0100000000
   protLastRcv 2017-07-01 19:45:25
   protSnd    6 last_at:2017-07-01 19:45:25
   protState  CMDs_done
   rssi_at_CUL_Cube avg:-77.58 min:-79.5 max:-74 lst:-79.5 cnt:12
   rssi_at_HmUART avg:-57.41 min:-60 max:-55 lst:-60 cnt:12
   Helper:
     Dblog:
       Activity:
         Log_db:
           TIME       1498931124.79896
           VALUE      alive
       D-firmware:
         Log_db:
           TIME       1498931124.79896
           VALUE      1.8
       D-serialnr:
         Log_db:
           TIME       1498931124.79896
           VALUE      FHEM200001
       R-cyclicinfomsg:
         Log_db:
           TIME       1498930437.04678
           VALUE      off
       R-eventdlytime:
         Log_db:
           TIME       1498930437.21836
           VALUE      0 s
       R-paircentral:
         Log_db:
           TIME       1498930437.04678
           VALUE      0x000000
       R-sign:
         Log_db:
           TIME       1498930437.21836
           VALUE      off
   Readings:
     2017-07-01 19:45:24   Activity        alive
     2017-07-01 19:45:24   D-firmware      1.8
     2017-07-01 19:45:24   D-serialNr      FHEM200001
     2017-07-01 19:45:24   PairedTo        0x000000
     2017-07-01 19:33:57   R-cyclicInfoMsg off
     2017-07-01 19:33:57   R-eventDlyTime  0 s
     2017-07-01 19:33:57   R-pairCentral   0x000000
     2017-07-01 19:33:57   R-sign          off
     2017-07-01 19:45:24   RegL_00.          02:01 0A:00 0B:00 0C:00 09:00 14:06 16:01 00:00
     2017-07-01 19:45:25   RegL_01.          08:00 20:6C 21:00 22:64 30:00 00:00
   Helper:
     HM_CMDNR   47
     cSnd       012309601FFFF101040000000001,012309601FFFF10103
     mId        0030
     peerIDsRaw ,00000000
     rxType     4
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +1FFFF1,00,00,00
       nextSend   1498931125.42477
       rxt        0
       vccu       VCCU
       p:
         1FFFF1
         00
         00
         00
       prefIO:
         HmUART
     Mrssi:
       mNo        2F
       Io:
         CUL_Cube   -77.5
         HmUART     -60
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_cul_cube:
         avg        -77.5833333333333
         cnt        12
         lst        -79.5
         max        -74
         min        -79.5
       At_hmuart:
         avg        -57.4166666666667
         cnt        12
         lst        -60
         max        -55
         min        -60
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HmUART
   IOgrp      VCCU:HmUART
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.8
   model      HM-SEC-RHS
   peerIDs    00000000,
   room       CUL_HM
   serialNr   FHEM200001
   subType    threeStateSensor was IMHO nicht in Ordung ist :
PairedTo        0x000000  und R-pairCentral   0x000000
hier müsste ja eigenlich meine HM ID stehen ?
Irgend eine Idee was ich noch tun kann ?

[habeIchVergessen]

Die Erfahrung habe ich nun nach gefühlt 100maligem OTA-flashen auch gemacht.

Wenn die Spannung (5V)  via ISP kommt, habe ich keine Probleme. Flashen klappt beim ersten Versuch. C6 habe ich "nur" auf 1 von 3 Platinen verbaut.

[habeIchVergessen]

hier müsste ja eigenlich meine HM ID stehen ?
Irgend eine Idee was ich noch tun kann ?

ja, da sollte die HM-ID stehen. Nach meinen Erfahrungen mit HM (eher bescheiden) ist das nicht ungewöhnlich, dass das Pairen nicht zuverlässig funktioniert.
Da hilft nur ständiges Wiederholen, bis das gewünschte Ergebnis eintritt.

PS: ich paire mit dem CUL. Nicht dem CUL_HM!

[Wzut]

Da hilft nur ständiges Wiederholen, bis das gewünschte Ergebnis eintritt.

Ich habe solange wiederholt bis ich ein sichtbares Loch im Finger hatte Aber immer das Gleiche , egal ob mit meinem MAX! Cube oder dem HmUART oder eben der VCCU.
Irgendwie macht es für mich auch keinen Sinn direkt ein Hardware Device zu nehmen , dazu ist doch die VCCU da ?
Anyway, das Prob ist inzwischen gefixt. Ich habe mit dem flash-ota die FW avr_HM_SEC_RHS_201705292247.eq3 übertragen.
Danach die VCCU in den Pairing Modus und nach 3x Config Taster drücken war alles so wie es sein soll.
 

[papa]

Ich habe die Zeit, bis eine Antwort zu einer Nachricht eintreffen muss, mal auf 600ms verdoppelt. Bitte mal testen, ob das im Zusammenspiel mit dem CUL besser läuft.

[habeIchVergessen]

habe die Version 02.07.2017 getestet.
hmPairForSec + config-Button funktioniert sehr zuverlässig (mit älteren Versionen nicht weiter getestet).
hmPairSerial funktioniert leider nicht sehr zuverlässig.

[Wzut]

@papa, ich habe deine neuste Version jetzt auch auf dem Sorgenkind drauf, war leider wieder so ein Kampf bis die 224 Blocks fehlerfrei durch waren. Was mich etwas wundert ist das obwohl es nun schon die dritte FW Version auf dem Ding ist das Reading firmware immer noch bei 1.8 bleibt.
Änderst du die in deinen verschiedenen Version nicht immer mit ?   

[papa]

Ich ändere die Versionsangabe nicht, da ich nicht weiß, ob FHEM oder CCU irgendwelche Funktionen/Eigenschaften/? damit verbinden. Wir emulieren ja genau diese Version der originalen Firmware.

Wenn wir eigene Versionen wollen, brauchen wir auch ein eigenes Device und damit ein extra Modul für FHEM und eine extra XML für die CCU.

[Wzut]

Wir emulieren ja genau diese Version der originalen Firmware.

Ahh ok, wieder was gelernt

[PeMue]

Hallo,

Der Quarz und die zugehörigen Kondensatoren werden nicht benötigt.

wie schickt die Firmware dann den Atmega328p schlafen? Oder andersherum gefragt: Was passiert, wenn ich den Quarz bzw. die Kondensatoren bestücke (außer dass ich ggf. Geld zum Fenster hinauswerfe?).
Ist der Quarz dann für Firmwareerweiterungen vorgesehen?

Danke + Gruß

Peter

[papa]

wie schickt die Firmware dann den Atmega328p schlafen? Oder andersherum gefragt: Was passiert, wenn ich den Quarz bzw. die Kondensatoren bestücke (außer dass ich ggf. Geld zum Fenster hinauswerfe?).

Die Firmware benutzt ausschließlich den Watchdog zum Schlafen. Das ist leider nicht besonders genau. Sollte aber für die regelmäßigen "ich-lebe-noch" Meldungen reichen. Wenn wir doch noch genaueres Timing brauchen sollen, können wir den Timer2 mit externen Quarz als RTC mit Sekundentakt nutzen. Das braucht dann aber auch wieder mehr Strom.

Ist der Quarz dann für Firmwareerweiterungen vorgesehen?

Die Platine ist eigentlich als "Universal-HM-Base" gedacht. Dort gibt es dann Anwendungen, wo es auf sehr genaues Timing ankommt (z.B. das Wetter-Event des HM-WDS10-TH-O). Hierfür ist der Quarz vorgesehen.
Ich bin gerade dabei "Erweiterungsboards" für die Platine zu machen. Ich mach demnächst mal nen extra Beitrag dazu auf.