Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Dirk]

Hi Frank,

das eigentliche fhem problem ist, dass der bootloader auf die cb-message wartet, aber fhem keine sendet.

Klingt nach einem FHEM-Problem?

AskSin OTA Bootloader V0.7.2

Jetzt bin ich mir unsicher.
V0.7.2? Da hab ich wohl was verpasst.
Also doch ggf. ein Problem vom Bootloader?
Was hat sich in 0.7.2 gegenüber 0.7.0 noch verändert?

# fehler: hier fehlen mehrere blöcke mit hmusb - kann man wohl nichts machen

FHEM und HM-USB?

Ich hatte das "damals" mit HM-USB und CUL und flash-ota, HM-USB und die Windows-SW und mit der CCU2 getestet.
Da müsste man mal weiter überprüfen. Vielleicht gibt es hier Probleme beim Timing?

Gruß
Dirk

[frank]

Klingt nach einem FHEM-Problem?

nee, leider nicht. kurz gesagt, martin sagte einmal:

ah - ok - es geht "nur" um die selbstgebaute FW.
HM wartet NICHT auf eine weitere CB.

Wird die "private" fw angepasst an HM? Oder ist das nicht zu schaffen?

in dem thread http://forum.fhem.de/index.php/topic,23329.msg211972.html#msg211972 hatte ich auch versucht martin wegen den verzögerungen der ersten ack zu kontaktieren. er hatte sich aber nicht gemeldet.

mist. jetzt sehe ich gerade, dass es meinen post von vorhin zerschosasen hat. die vorschau hatte funktioniert, speichern ging wohl daneben. da fehlt auch was.

ich habe meine bootloader-version mit cul und hmusb über fhem getestet. allerdings mit dem sw1pbu mit alternativer fw und 8k-bootloader. eventuell sind meine änderungen für 4k zu viel. grundsätzlich lief es dann mit dem cul zuverlässiger. als nächstes wollte ich damals eigentlich debug-messages in cc.c einbauen, um zu schauen, ob die ersten ack-messages vom bootloader auch wirklich rechtzeitig gesendet werden, oder ob fhem die verzögerungen verursacht. leider konnte ich die debug ausgaben nicht ohne weiteres integrieren. da hätte ich dann wohl mehr umbauen müssen. somit gab es dann den entwicklungsstillstand.

Was hat sich in 0.7.2 gegenüber 0.7.0 noch verändert?

das ist meine private version.    aus deiner hervorgegangen.

[Dirk]

nee, leider nicht. kurz gesagt, martin sagte einmal:
ah - ok - es geht "nur" um die selbstgebaute FW.
HM wartet NICHT auf eine weitere CB.

Naja. Das update mit CCU2 und HM-LAN-SW funktioniert mit dem Bootloader. Und natürlich mit flash-ota auch.
Also macht FHEM hier noch was anders. Nur warum?

das ist meine private version.    aus deiner hervorgegangen.

Ah, dachte ich mir fast. Allerdings hatte ich da 0.7.1 erwartet

Also muss man hier noch etwas weiter "forschen"

Gruß
Dirk

[frank]

Nur warum?

homematic-philosophie. ausserdem klappt es ja mit allen anderen fw-updates über fhem. lies den thread.   

Allerdings hatte ich da 0.7.1 erwartet

du warst damals so schnell mit updates, da dachte ich, da habe ich mehr zeit. 

Also muss man hier noch etwas weiter "forschen"

genau. => warum bekommt fhem die ack von den ersten übertragenen blöcken nicht rechtzeitig mit?

oder es liegt an meiner fhem umgebung.

gruss frank

[Dirk]

homematic-philosophie. ausserdem klappt es ja mit allen anderen fw-updates über fhem. lies den thread.   

So, hab mr das jetzt auch mal durchgelesen.  Die Hauptdiskussion war noch vor meiner Zeit mit dem Bootloader
Somit werde ich mir das demnächst wohl noch mal vornehmen.

Gruß
Dirk

[Poquito]

Hallo Dirk,

Ich belästige Dich äußerst ungern mit meinen trivialen Problemen, aber ich komme einfach nicht weiter.
Nachdem Du mir den Link für die aktuelle Asksin Version geschickt hast, kann ich nun endlich die Software für den Wettersensor selbst compilieren. Das Compilieren und Hochladen funktioniert sowol für die V0.14 und V0.15. Das Programm scheint auch auf meinem Arduino Mini Pro zu laufen, aber ich bekomme es nicht korrekt mit FHEM gepairt.
Kann es sein, dass das Programm nicht mehr mit dem orginal Bootloader vom Arduino funktioniert, sondern nur noch mit dem OTA-Bootloader mit dem Ihr den Wettersensor betreibt?
Die Datei HMConfig_SenTHPL.pm habe ich ins FHEM-Verzeichnis Auf dem RaspberryPi kopiert und die Variable USE_ADRESS_SECTION wie beschrieben in Wettersensor.h und AskSinMain.h auf 0 gesetzt, aber die Variablen DEVICE_TYPE, DEVICE_SERIAL und DEVICE_ADDRESS scheinen nicht korrekt übernommen zu werden, denn in FHEM erhalte ich nach dem pairen folgende Einträge unter Attributes für CUL_HM_ID_6967_212120

IODev              CUL_1
autoReadReg    4_reqStatus
expert              2_full
firmware           6.6
model              unknown
room               CUL_HM
serialNr            mode BUR

Hast Du eine Idee was ich falsch mache oder was mir noch fehlt?

Gruß
Helmut

[Dirk]

Hallo Helmut,

Kann es sein, dass das Programm nicht mehr mit dem orginal Bootloader vom Arduino funktioniert, sondern nur noch mit dem OTA-Bootloader mit dem Ihr den Wettersensor betreibt?

Auch der "normale" Ardunio Bootloader sollte funktionieren. Da müssen Seriennummer, HM-ID und Type aber dann in der FW gesetzt werden. Das hast du ja schon gemacht.

Hast du auch die HMConfig_SenTHPL.pm ins FHEM-Verzeichniss kopiert?

Falls du selber den Bootloader flashen kannst, hier ist übrigens ein angepasster Arduino-Serial-Bootloader bei dem du Seriennummer usw. im Bootloader setzen kannst: https://github.com/kc-GitHub/Wettersensor/tree/v0.12/Tools/Bootloader/Arduino_Serial

Gruß
Dirk

[betateilchen]

Ich blicke grade überhaupt nicht mehr durch, wie ich meinen Sensor v0.12 auf 0.14 updaten könnte, um (hoffentlich) das 49-Tage-Problem zu lösen...

Gibts denn das Update-Paket in der Form wie früher (als cmd Datei) gar nicht mehr?

[Dirk]

Gibts denn das Update-Paket in der Form wie früher (als cmd Datei) gar nicht mehr?

Wenn ich mich recht erinnere hast du noch den seriellen BL?

Ich wollte den seriellen Bootloader eigentlich als separates Repo anlegen.
Bis dahin ist das Script noch im 0.12er Zweig zu finden:
https://github.com/kc-GitHub/Wettersensor/tree/v0.12/Tools/Firmware

Das 0.14er Hexfile ist im 0.14er Firmware-Release:
https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release-Ordner

Gruß
Dirk

[Gernott]

Hallo Dirk

Habe eben 3 Sensoren mit flash-ota mit der neuen Firware versehen. Das Update ist ohne Probleme durchgelaufen. Allerdings war bei 2 Sensoren das Pairing verloren. Außerdem gibt es Problem mit dem Lesen der Konfiguration. Die Firmware wird aber in den Readings korrekt mit 0.14 angezeigt.

Im state steht: RESPONSE TIMEOUT:RegisterRead

Model und Subtype sind auch leer. Ist da etwas schiefgegangen?
************
Update: Ja, das hier:

Code Auswählen Erweitern

2015.03.12 22:11:19 1: Error loading file: ./FHEM/HMConfig_SenTHPL.pm:
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 55 at ./FHEM/HMConfig_SenTHPL.pm line 12, <$fh> line 72.

Ich hatte die Datei direkt mit wget aus dem git in das FHEM-Verzeichnis geholt. Das geht wohl so nicht?

Gruß
G.

[Dirk]

Ich hatte die Datei direkt mit wget aus dem git in das FHEM-Verzeichnis geholt. Das geht wohl so nicht?

Doch. Du musst aber den RAW-Link benutzen:
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Contrib/FHEM/HMConfig_SenTHPL.pm
Ansonsten hast du HTML-Code im PM-File

Gruß
Dirk

[Gernott]

Doch. Du musst aber den RAW-Link benutzen:
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Contrib/FHEM/HMConfig_SenTHPL.pm
Ansonsten hast du HTML-Code im PM-File

Schöner Mist, habe ich auch gerade gesehen. Kaum macht man es richtig, schon geht es.
Danke für den Hinweis und die neue Firmware. Jetzt schaue ich, ob es mit dem Thermostat besser läuft.

Gruß
G.

[Gernott]

Ich bin es nochmal. Jetzt läuft die Messung wieder. Ich hatte aber Mühe, mit getConfig die Register einzulesen. Nach mehrfacher Wiederholung + Knöpfchen drücken ging es irgendwann. Was aber bisher völlig fehlschlägt, ist das Einlesen der Peerlist.

Hier kommt immer: RESPONSE TIMEOUT:PeerList

Was kann ich noch machen?

Gruß
G.

[vbs]

Probier mal, das Knöpchen mehrfach zu drücken, nach dem getConfig gestartet wurde.

[Gernott]

Probier mal, das Knöpchen mehrfach zu drücken, nach dem getConfig gestartet wurde.

Danke, das ging dann. Da muß man erst mal drauf kommen.

Viele Grüße
G.