Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Dirk]

das sieht so aus, als wenn kein Sleepmodus eingebaut ist.

Doch, Sleepmode ist an.
Ich hatte letztens aber auch einen Sensor der um die 4mA andauernd gezogen hat.
Der Austauschsensor braucht nur ~10-30 µA im Standby.

Nun habe ich einen neuen Satz Batterien vor 2 Wochen eingelegt und ich Zeichne die Batteriespannung auf, aber seht selbst die Bilder der Graphen.

Kannst du mal den Stromverbrauch messen.

Messen kann ich erst nach meinem Urlaub.

Ja, mach das bitte mal.

Das Merkwürdige daran ist, dass die Innensensoren sich bisher hier unauffällig verhalten.
Ich werde das am Wochenende mal analysieren.


Gruß
Dirk

[vbs]

Was ist eure Meinung zu dem häufigen Fehlern bei den Sendeversuchen?

[Dirk]

Hallo

Was ist eure Meinung zu dem häufigen Fehlern bei den Sendeversuchen?

Sorry, ich hatte dein Beitrag übersehen.

Ich bekomme hier ab und zu auch Aussetzer. Aber gefühlt nicht mehr als mit anderen HM-Devices auch.
Ich habe hier auch ein paar Eigenbau-Taster die quasi aus der gleichen Hardware (ohne Sensoren) aufgebaut sind. Auch bei diesen ist der Fall dass man zwei mal drücken muss selten.

Selbst das Einbauen der 3 Retries würde das nicht komplett lösen, da teilweise bis zu 6 Transfers in Folge fehlschlagen.

Der unterschied zwischen deinen Tastern und den Sensoren ist hier ggf. das feste Zeitfenster.
Kann es sein dass du andere Geräte hast die auch im selben / ähnlichen Zeitfenster senden? Dann würde es zwischen den Beiden recht häufig Kollisionen geben. Und dann würde das Ändern des Codes auf 3 Sendeversuche eine Besserung bringen.

Du kannst deinen Versuch ja mal mit der Firmware ..._test.hex wiederholen. Diese senden im 10 Sek. Intervall.

Gruß
Dirk

[UliM]

Hi,
hab den Fred auf Dirks Anfrage wieder geöffnet.
Warum der geschlossen war - keine Ahnung.
Gruß, Uli

[Franz74]

Hi,
hab den Fred auf Dirks Anfrage wieder geöffnet.
Warum der geschlossen war - keine Ahnung.
Gruß, Uli

Vielen Dank!

LG

Franz

[Mr. P]

Vielen Dank!

Bist ja äußerst dankbar.

[Franz74]

Bist ja äußerst dankbar.

Jein --> Mein Tapatalk meinte nach dem Speichern keine Verbindung zum Server bitte Kontaktieren sie... Aber das Speichern hat trotzdem Funktioniert und das sogar mehrfach...

Auch bietet Tapatalk keine Möglichkeit zum Löschen der Doppelposts, das habe ich gerade eben über das web gemacht...

LG

Franz

[vbs]

Ich bin nochmal dem Übertragungsproblem nachgegangen (http://forum.fhem.de/index.php/topic,14140.msg180923.html#msg180923). Kurzfassung: Beim Senden muss ich auch bei Nicht-Burst-Empfänger keinen kurzen "Mini-Burst" schicken, damit der Empfänger (in meinem Fall ein HMLAN) die Nachricht zuverlässig empängt. Der normale Burst wird für 360 ms gesendet. Ich sende jetzt in der Firmware einen 40 ms Burst auch bei Nicht-Burst-Geräten. Damit ist die Übertragung schon recht zuverlässig. Die Fehler, die noch vorkommen, werden dann durch Retries beseitigt. Ich habe damit jetzt keine fehlgeschlagenen Übertragungen mehr.

Ich hab so ziemlich alles probiert, was mir eingefallen ist, um auch ohne Mini-Burst eine stabile Übertragung hinzubekommen. Leider alles erfolglos. Interessanterweise hat sich herausgestellt, dass die Kollegen von der CUL-Firmware unabhängig von mir zu der gleichen Lösung gekommen sind: Punkt 2 hier https://groups.google.com/forum/#!msg/cul-fans/lpMRoqU4F-M/QXSnOexnZBcJ
Die CUL-Firmware sendet nun zumindest einen 10ms-Mini-Burst bei Nicht-Burst-Geräten. Das bringt schon etwas, aber für richtig gute Ergebnisse brauche (zumindest ich) so 30-40 ms (und aufwärts). Das alles mag auch geräteabhängig sein. In dem CUL-Thread wird auch explizit von einem "Problemaktor" gesprochen, mit dem das Problem nur aufgetreten ist. Das Verhalten mag also je nach Sender/Empfänger-Konstellation stark schwanken.

Also ich fürchte, dass das evtl. wirklich der Weg ist, um die Übertragungsproblem zu beseitigen. Mich würde mal interessieren, was genau originale Homematic-Sensoren senden. Machen die das evtl. sogar auch so? Wenn ja, wie lang ist der Burst, den sie verwenden?

[frank]

hallo vbs,

Also ich fürchte, dass das evtl. wirklich der Weg ist, um die Übertragungsproblem zu beseitigen.

ich habe mit meinen hm-devices und ios (cul, hmlan, hmusb) keine kommunikationsprobleme. somit sollte auch ein "normaler" weg für den selbstbau sensor existieren.
ist es nicht so, dass bei burst kommunikation alle burst-devices aufwachen? somit würde man den funkverkehr ja unnötig belasten, meine ich.

die einzigen probleme, die bei mir existieren, kommen durch verzögerungen in fhem. zb bei addlog oder bestimmten netzwerk aktionen. dann kommen timing-sensitive kommunikationen nicht mehr rechtzeitig. hast du bei dir einmal mit apptime oder dem performancemonitor dein system untersucht.

gruss frank

[vbs]

ich habe mit meinen hm-devices und ios (cul, hmlan, hmusb) keine kommunikationsprobleme. somit sollte auch ein "normaler" weg für den selbstbau sensor existieren.

Schwankt scheinbar von Gerät zu Gerät. In dem CUL-Thread ist auch von "Problemaktoren" die Rede. Tritt scheinbar nicht bei allen auf.

ist es nicht so, dass bei burst kommunikation alle burst-devices aufwachen? somit würde man den funkverkehr ja unnötig belasten, meine ich.

Ja das ist schon so. Aber der normale Burst ist 360 ms lang. Bei mir jedoch nur 40 ms. Aber trotzdem: Das ist nicht komplett kostenlos, stimmt schon. Schöner wäre es, komplett ohne Burst.

die einzigen probleme, die bei mir existieren, kommen durch verzögerungen in fhem. zb bei addlog oder bestimmten netzwerk aktionen. dann kommen timing-sensitive kommunikationen nicht mehr rechtzeitig. hast du bei dir einmal mit apptime oder dem performancemonitor dein system untersucht.

Nee nee, es liegt auf jeden Fall an dem Burst. Ich kann das 1:1 reproduzieren: Mit Burst - > geht, ohne Burst -> geht nicht. ("Geht nicht" heisst: ca. 50% der Übertragungen schlagen fehl). Wie gesagt, unabhängig von mir macht die CUL-Firmware schon seit längerem das gleiche... Mit der gleichen Begründung.

[frank]

ohne Burst -> geht nicht

was genau bedeutet geht nicht? message wird gesendet, aber nirgendwo empfangen?

Schwankt scheinbar von Gerät zu Gerät.

für fertige hm-geräte mag das vorgehen ja ok sein. bei selbstbauten, sollte man das doch wohl selber in der hand haben, es zum funktionieren zu bekommen.

[vbs]

was genau bedeutet geht nicht? message wird gesendet, aber nirgendwo empfangen?

Die Nachrichten sind für das HMLAN komplett unsichtbar, also kommen gar nicht an. Je länger ich den Burst mache, desto höher wird die Quote der Nachrichten, die vom HMLAN gesehen werden. Liegt *vermutlich* daran, dass das HMLAN sich bei dem nicht vorhandenen Burst nicht korrekt auf den Anfang der Nachrichten synchronisieren kann. Der Burst ist ja im C1101-Jargon nur eine Sequenz aus 10101...0101 mit beliebiger Länge, die vor den eigentlich Daten gesendet wird.

für fertige hm-geräte mag das vorgehen ja ok sein. bei selbstbauten, sollte man das doch wohl selber in der hand haben, es zum funktionieren zu bekommen.

Das hab ich nicht verstanden. Was da genau funk-technisch hinter steckt, weiss ich nicht genau. Du meinst, es ist ein Fehler (bzw. Schwäche) im (fertigen) HMLAN?

[frank]

Das hab ich nicht verstanden. Was da genau funk-technisch hinter steckt, weiss ich nicht genau. Du meinst, es ist ein Fehler (bzw. Schwäche) im (fertigen) HMLAN?

ich habe dich so verstanden, dass dein hmlan im allgemeinen keine probleme hat, sondern nur mit diesem einen device. daher gehe ich davon aus, dass dein hmlan sich nur mit diesen speziellen messages schwer tut, warum auch immer. da es ein selbstbau device ist, muss man doch die messages des devices ändern können, sodass es auch hier funktioniert.
diverse faktoren einfach mal ändern, wie zb messagelänge, msgtyp, deviceadresse, etc. ich kenne die rawmessage jetzt nicht, aber irgend etwas muss an dieser message ja sein, dass der hmlan sie nicht erkennen kann/will.

passiert das gleiche auch mit cul oder hmusb?

[vbs]

ich habe dich so verstanden, dass dein hmlan im allgemeinen keine probleme hat, sondern nur mit diesem einen device. daher gehe ich davon aus, dass dein hmlan sich nur mit diesen speziellen messages schwer tut, warum auch immer. da es ein selbstbau device ist, muss man doch die messages des devices ändern können, sodass es auch hier funktioniert.

Genau das hab ich ja eigentlich gemacht: ich hab die Präambel (die sowieso vor jeder Nachricht gesendet wird) verlängert. Und dann klappts.

diverse faktoren einfach mal ändern, wie zb messagelänge, msgtyp, deviceadresse, etc. ich kenne die rawmessage jetzt nicht, aber irgend etwas muss an dieser message ja sein, dass der hmlan sie nicht erkennen kann/will.

Wie gesagt, das hab ich alles hinter mir. Ich hab im Endeffekt eine Minimal-Firmware geschrieben, die nichts anderes macht als alle 2 Sekunden immer die gleiche (hardkodierte) Nachricht zu schicken. Hab natürlich auch vorher schon verschiedene Nachricht-Inhalte ausprobiert. Das einzige, was Effekt gezeigt hat, war die Änderungen der Länge der Präambel.
Jetzt wo ich gesehen habe, dass die CUL-Firmware das zufällig ganz genauso macht, denke ich halt, dass das tatsächlich so sein muss.

[trilu]

burst ist nicht präambel

burst heisst im fall von hm nur, dass das funkmodul in den tx modus geht und eben ein trägersignal sendet.
die kommunikation mit burst geräten läuft in etwa so:

das burst gerät schläft und das funkmodul ist im standby (kein rx oder tx)
alle 250ms wacht das gerät auf und schaltet das funkmodul ein, dann wird gelauscht ob ein trägersignal in der luft ist.
findet es kein trägersignal, dann wird das funkmodul wieder in den stand by geschaltet und das gerät schläft weiter.

findet es ein trägersignal, dann wird für weitere 100ms geprüft ob das so bleibt, wenn ja, dann bleibt das gerät an und wartet auf die präambel und den string - falls keiner kommt, geht es nach 1 oder 2 sekunden wieder schlafen.

derzeit schalte ich im "nicht burst mode" das trägersignal für 1 ms ein und sende dann. ich denke wir können hier problemlos auf 10ms hoch gehen. das ganze befindet sich in der cc110x.cpp in der funktion "CC110x::sendData(uint8_t *buf, uint8_t burst)"

Code Auswählen Erweitern

if (burst) { // BURST-bit set?
cmdStrobe(CC1101_STX  ); // send a burst
delay(360); // according to ELV, devices get activated every 300ms, so send burst for 360ms
//Serial << "send burst\n";
} else {
delay(1); // wait a short time to set TX mode
}

einfach das delay(1) auf delay(10) setzen und testen. 40 oder 50ms sind schon verdammt viel. das würde den funktraffic unverhältnismäßig in die höhe treiben....