Hallo Zusammen,
ich möchte euch mein erstes produktives Device vorstellen, einen selbstgebauten WDS10 Wettersensor mit zusätzlicher Luftdruckmessung.
Basis für das ganze ist ein Panstamp Modul, wobei ein Arduino Pro Mini mit CC1101 Modul auch gehen würde.
Als Sensoren habe ich einen SHT10 für Temperatur und Luftfeuchte und einen BMP180 für Luftdruck verwendet, beide habe ich freundlicherweise
von Dirk bekommen. Martin876 hat den verlängerten String in FHEM integriert, so dass mit einer aktuellen FHEM HM Version dem Empfang nichts
im Wege steht.
Die Schaltung besteht im Wesentlichen aus einem Panstamp, den beiden Sensoren, einem Config Taster, einem Kondensator und zwei Batterien.
Der SHT10 ist an Pin A0 (data) und Pin A1 (clock) angeschlossen, sowie VCC und GND
Der BMP180 ist ein i2c Sensor und folglich an Pin A4 und A5 angeschlossen.
Der 100nF Kondensator hängt zwischen dem Programmieranschluss (DTR) und dem Reset Pin des Panstamp, so dass man den Panstamp auch mit
einem FTDI Adapter programmieren kann.
Die Dual Led hängt an Pin D7 und D6 und zeigt die verschiedenen Zustände des Sensors an, also ob ein ACK kam, wann gesendet wird, usw...
Softwareseitig ist auch eine Low Batterie Erkennung eingebaut, die Schaltschwelle lässt sich im Source Code setzen: "hm.battery.setVoltage(30);"
Derzeit ist sie zu Testzwecken auf 3,0 Volt gesetzt, ich denke das das Modul bis runter auf 2,7 Volt zuverlässig arbeiten sollte. Die Tests stehen aber
noch aus.
Das Timing habe ich von hier: "http://forum.fhem.de/index.php/topic,17485.0.html"
Ob es so passt und sich der Temperaturfühler mit dem HM-CC-RT-DN koppeln lässt, kann ich leider nicht sagen, da ich keinen HM-CC-RT-DN besitze.
Die gesendeten Messages sehen dann so aus, in Klammern seht ihr das Timing (milli Sekunden Systemzeit Arduino):
0E 01 A2 70 6F B7 4C 63 19 63 00 D6 2E 03 FE (l:15)(59359)
0A 01 80 02 63 19 63 6F B7 4C 00 (l:11)(59480)
0E 02 A2 70 6F B7 4C 63 19 63 00 D2 2E 03 FE (l:15)(202407)
0A 02 80 02 63 19 63 6F B7 4C 00 (l:11)(202528)
0E 03 A2 70 6F B7 4C 63 19 63 00 CD 2F 03 FE (l:15)(398872)
0A 03 80 02 63 19 63 6F B7 4C 00 (l:11)(398993)
0E 04 A2 70 6F B7 4C 63 19 63 00 C9 2F 03 FE (l:15)(579913)
0A 04 80 02 63 19 63 6F B7 4C 00 (l:11)(580034)
0E 05 A2 70 6F B7 4C 63 19 63 00 C6 30 03 FE (l:15)(745398)
0A 05 80 02 63 19 63 6F B7 4C 00 (l:11)(745519)
0E 06 A2 70 6F B7 4C 63 19 63 00 C4 30 03 FE (l:15)(895094)
0A 06 80 02 63 19 63 6F B7 4C 00 (l:11)(895215)
0E 07 A2 70 6F B7 4C 63 19 63 00 C2 31 03 FE (l:15)(1029429)
0A 07 80 02 63 19 63 6F B7 4C 00 (l:11)(1029548)
0E 08 A2 70 6F B7 4C 63 19 63 00 C0 31 03 FE (l:15)(1217157)
0A 08 80 02 63 19 63 6F B7 4C 00 (l:11)(1217277)
0E 09 A2 70 6F B7 4C 63 19 63 00 BF 31 03 FE (l:15)(1389287)
0A 09 80 02 63 19 63 6F B7 4C 00 (l:11)(1389408)
0E 0A A2 70 6F B7 4C 63 19 63 00 BE 31 03 FE (l:15)(1545744)
0A 0A 80 02 63 19 63 6F B7 4C 00 (l:11)(1545865)
0E 0B A2 70 6F B7 4C 63 19 63 00 BD 32 03 FE (l:15)(1686865)
0A 0B 80 02 63 19 63 6F B7 4C 00 (l:11)(1686984)
Kurze Erklärung zu den gesendeten Messages.
0E 0B A2 70 6F B7 4C 63 19 63 00 BD 32 03 FE
0E - Länge des Strings in Byte
0B - Messagecounter
A2 - Message flags
70 - Weather Event (Art der Message)
6F B7 4C - eigene HM ID (kann in der Register.h gesetzt werden)
63 19 63 - meine Zentrale (wird beim pairen gesetzt)
00 BD - Temperatur in zehntel Grad, hier also 18,9 Grad
32 - Luftfeuchtigkeit in %, Hex 32 ist 50% in Decimal
03 FE - Luftdruck, 1022 hPa NN, also über Meeresspiegel
Die eigene Höhe über Meeresspiegel muss derzeit im Sourcecode gesetzt werden, und zwar so:
"sensTHP.config(A0, A1, 0, &sht10, &bmp085, 570);"
Ich werde versuchen das ganze noch in einen, von FHEM veränderbaren, Register Wert zu gießen, so das die Konfiguration in
Zukunft variabel ist.
Ich hatte das Modul auch noch nicht im Tiefkühlschrank, ob die Minus Werte passen, weiß ich folglich nicht.
Das Gehäuse, bzw. die Öffnung für den Temperaturfühler, ist auch noch Verbesserungsfähig. Hier werde ich die Tage mal den Baumarkt
besuchen und schauen was es für Verschraubungen gibt 8)
Dirk hat auch angekündigt eine Platine für die Sensoren entwerfen zu wollen - zusätzlich wird es dann auch noch einen Helligkeitssensor geben...
Der Sensor lässt sich mit FHEM und auch der Original HM Config Software pairen und verhält sich (hoffentlich) wie der Originale...
Die Sourcen zum Sensor liegen hier: "https://github.com/trilu2000/AskSin"
Zum Schluss noch ein paar Bilder...
Hi trilu,
Super Arbeit.
Leider bin ich noch nicht zum Testen gekommen.
ZitatDirk hat auch angekündigt eine Platine für die Sensoren entwerfen zu wollen
Die Platine wird, laut aktuellem Stand sowohl als Shield für einen Arduino-Pro-Mini dienen können, als auch direkt mit einem Atmega328 zu bestücken sein.
Der Helligkeitssensor wird hier auch schon mit vorgesehen.
Das erste Layout bereite ich grade für dieses Gehäuse vor:
http://static3.tme.eu/katalog_pics/5/4/4/54492c6918313ffc888d3ded8d3a76ea/box-sens-white.jpg
Gruß
Dirk
Danke, wobei das Lötgefädle nicht wirklich schön ist ;)
Aber Heisskleber wird es schon richten....
Hallo trilu. Meinen Glückwunsch zu dieser tollen Software.
Den HM_LC_SW1_BA_PCB habe ich schon nachgebaut (Mit TRX868 und Pro Mini 3,3V ).
http://www.aliexpress.com/item/5pcs-lot-Pro-Mini-328-Mini-ATMEGA328-3-3V-8MHz-Free-Shipping-Dropshipping/1545115091.html
Jetzt bestelle ich die Sensoren für den HM_WDS10_TH_O.
Mit welchen Project geht es denn weiter? Ich würde gerne einen R.W.E Zwischenstecker oder einen Max! Zwischenstecker auf Asksin und FHEM umstellen. Das müsste doch gehen. Die Zwischenstecker können ja nicht ausgelesen werden und müssen komplett gelöscht werden. Nur welchen Bootloader nehme ich dann. Mit einem mkII Flashadapter habe ich schon mal getestet.
PS
Ein Arduino Uno lässt sich auch auf 3,3V umstellen. Ich habe es aber noch nicht mit dem TRX868 getestet.
http://learn.adafruit.com/arduino-tips-tricks-and-techniques/3-3v-conversion
@robbi24
Das lohnt ja nicht wirklich, der MAX Zwischenstecker kostet ja auch 40 Euro, da kann man ja den Originalen von HM auch kaufen :o
Grundsätzlich müsste sich der "HM_LC_SW1_BA_PCB" Sketch schon eignen um eine eigene Firmware für so ein Ding zu generieren.
Relay Class und Register Settings existieren ja schon. Die Pins müssen dann halt noch an die HW angepasst werden.
Hast du einen Schaltplan für den RWE oder MAX Zwischenstecker, so dass man sehen kann an welchen Pins die LED und das Relais hängen.
Und vielleicht eine Frage vorab, welche CPU ist in den Dingern? Meine Lib ist derzeit für Arduino, dass heisst es werden jede Menge Atmel CPU's
supportet. Bootloader brauchst du eigentlich nicht, schau mal hier, da hat Jan die Lib auf eine 644 CPU portiert...
http://forum.fhem.de/index.php/topic,18071.0.html
Als nächstes möchte ich mich an eine Dimmer Class setzen, so dass man seine eigenen LED Dimmer basteln kann...
Die Frage war eigentlich grundsätzlich gemeint:"Lassen sich Geräte von Max! oder R.W.E SH auf Homematic umrüsten". Es gibt viele Devices von R.W.E günstig bei Ebay und die sehen alle schick aus. Da gibt es viele mit AVR 328 und CC110x-Modul die fast baugleich mit Homematic sind. Die kommen fast alle von EQ3.
.. wurde schon öfter angedacht siehe hier:
https://github.com/ccier/openhm/wiki/Devices ( mit RSH ist R.W.E gemeint )
oder hier
https://code.google.com/p/busware/source/browse/trunk/Dudette/board.h
Da wurde ein R.W.E PSS ( Zwischenstecker) umgeflasht.
Hi Robbi24,
Wenn die RWE Stecker eine AVR und ein CC110x-Modul beherbergen, dann sollte man die mit ein Paar wenigen Änderungen an der Lib auch umflashen können.
Gruß
Dirk
Hallo Dirk !
Zitat von: Dirk am 23 Februar 2014, 12:44:18
Die Platine wird, laut aktuellem Stand sowohl als Shield für einen Arduino-Pro-Mini dienen können, als auch direkt mit einem Atmega328 zu bestücken sein.
Auf was für eine Funkmodul setzt Du denn dabei auf ? Immer erst einen MAX Fensterkontakt oder andere MAX/HM Komponenten auszuschlachten, würde mich eher in Richtung Panstamp treiben. Allein die Versandkosten verhageln einem die Panstamps ....
Gruß, Marc
Hi Marc,
ZitatAuf was für eine Funkmodul setzt Du denn dabei auf ?
auf diese hier:
http://www.aliexpress.com/item/2PCS-LOT-CC1101-868MHz-wireless-module-free-shipping/1282890043.html
Diese würde ich auch im Layout so vorsehen.
Gruß
Dirk
Wobei es die Module auch günstiger gibt...
http://www.aliexpress.com/item/5PCS-LOT-CC1101-wireless-module-Frequency-range-300-1000-MHz-free-shipping/1095240213.html
Das einzig nervige ist die Wartezeit. Aber bei den Preisen kann man auch vorrausschauend bestellen.
Hi !
Leider hat dieses Modul scheinbar etwas andere Maße. Weiterhin scheinen VCC und GND im Vergleich zu dem anderen Modul
vertauscht zu sein. Da Dirks Platinen ja im Regelfall Maßanfertigungen sind, wird man wohl das erstgenannte Modul bestellen müssen,
das aber immer noch billiger ist, als ein MAX Fensterkontakt ;)
Zitat von: trilu am 24 Februar 2014, 06:49:19
Wobei es die Module auch günstiger gibt...
http://www.aliexpress.com/item/5PCS-LOT-CC1101-wireless-module-Frequency-range-300-1000-MHz-free-shipping/1095240213.html
Das einzig nervige ist die Wartezeit. Aber bei den Preisen kann man auch vorrausschauend bestellen.
Gruß, Marc
Hi Marc,
Ich bin mir fast sicher, dass Dirk das zweite Modul hat. Wir hatten darüber mal im AskSin Thread geredet. Zusätzlich habe ich ihm ein Modul geschickt, da seine noch nicht geliefert waren...
Viele Grüsse
Horst
Wäre es möglich auf der Platine einen Anschluss für einen Bewegungsmelder vorzusehen?
Der AtMega müsste doch noch freie Pins haben.
Dann könnte man mit einem Bauteil einen Raum komplett überwachen.
Nico
Hier nochmal ein Link mit 5 Modulen. Die sind dann etwas günstiger:
http://www.aliexpress.com/item/5pcs-lot-CC1101-868MHz-wireless-module-distance-for-300m-Free-shipping/1104732817.html
Ich, und bestimmt auch Trilu haben bestimmt noch ein Paar Module übrig.
Hier der Beitrag wo ich die Module für meine Taster verbaut hatte. Da kann man die Module mal im Einsatz sehen:
http://forum.fhem.de/index.php/topic,19657.msg132656.html#msg132656
Man kann grundsätzlich auch andere Module mit dem CC110x nehmen. Aber in der Regel sind die Module aus China auf 433Mhz abgestimmt.
Man kann die Frequenz zwar ändern, allerdings hat man dann eine geringere Reichweite.
Ich habe beide Module, die für 868Mhz und die für 433Mhz getestet. Und erwartungsgemäß ist das Modul was auch hardwareseitig für 866Mhz ausgelegt war, sende- und empfangsseitig besser gewesen.
Zitat von: santalaus am 24 Februar 2014, 20:58:18
Wäre es möglich auf der Platine einen Anschluss für einen Bewegungsmelder vorzusehen?
Was für einen Bewegungsmelder schwebt dir hier denn vor?
Planmäßig ist die Platine bei den Abmessungen für das Gehäuse unten, mit Batteriehalter, Steckplatz für Arduino, für den alternativen Atmega328, CC1101-Modul, Temp/Feuchte-, Luftdruck- und Helligkeitssensor schon gut ausgefüllt.
@Trilu
Ich habe mir das Datenblatt des Helligkeitssensors mal angeschaut.
Dieser hat einen Konfigurierbaren Interrupt welcher selber bei entsprechenen Helligkeitsänderungen auslöst.
Die Schwelle kann man programmieren. Dann muss man den Sensor nicht pollen und kann Helligkeitsänderungen auch at hoc versenden.
Ich habe den Int im derzeitigen Entwurf der Platine an A0 vorgesehen.
Nur falls du das schon mal testen willst :)
Gruß
Dirk
Hallo,
also mir würde der Bewegungsmelder aus den Airwick Modulen vorschweben ;)
Ich denke aber das es ggf auf der Platine am sinnvollsten sein könnte einfach ein 3-Pin 2,54 Kontakt vorzusehen und den Sensor via Kabel anzuschliessen.
Nico
Bewegungsmelder würde mich auch interessieren, aber wäre das nicht ein eigenes Gerät?
Wobei, solange man nicht alles Bestücken muss und die Platine klein genug bleibt, wäre es auch ok.
Hat jemand einen HM Bewegungssensor und könnte mal die Register auslesen?
Was für einen PIR Sensor haben die original HM Geräte drin?
So wie ich es sehe, werden beim Airwick sowie den China Modulen die Schaltschwelle per Poti eingestellt,
um ehrlich zu sein, hätte ich das aber gerne per Software :-)
@Dirk: Kannst du auf der Platine bitte auch einen Anschluss für einen FTDI Programmieradapter vorsehen?
Viele Grüße
Horst
Update: Habe gerade mal ein wenig bei Aliexpress geschaut, die meissten PIR Sensoren sind per Poti oder Festwiderstand verstellbar.
Bei Einigen lässt sich die Schaltdauer zusätzlich über Poti einstellen, wobei das Käse ist, wenn ein Arduino dran hängt. Da reicht mir der Impulsausgang.
Spannungsversorgung ist ab 4,5 Volt angegeben, hier stellt sich die Frage ob die einen Spannungsregler onboard haben und vielleicht mit 3 Volt zu betreiben sind. Preislich absolut interessant, starten ab 1 Euro. Stromverbauch ideal <60uA. Damit könnte man so einen Sensor in jedes Zimmer packen und die Heizung und Licht schalten lassen.
ZitatBewegungsmelder würde mich auch interessieren, aber wäre das nicht ein eigenes Gerät?
Währ ich auch dafür.
Module gäbe es auch sehr günstig bei Ali:
http://www.aliexpress.com/item/Free-Shipping-HC-SR501-Adjust-Infrared-IR-Pyroelectric-Infrared-PIR-module-Motion-Sensor-Detector-Module-We/1564561530.html
Mit der Empfinglichkeitseinstellung müsste man sich dann noch was überlegen.
Ich finde aber auch hier ein ansprechendes Gehäuse wichtig (WAF). Daher währ die andere Idee bei einem günstigen fertigen Melder "nur" die Elektonik zu tauschen?
http://www.pollin.de/shop/dt/MjE3NzY0OTk-/Lichttechnik_Leuchtmittel/Diverse_Zubehoer/Bewegungsmelder/Infrarot_Bewegungsmelder_IRB_180I.html
Zitat@Dirk: Kannst du auf der Platine bitte auch einen Anschluss für einen FTDI Programmieradapter vorsehen?
Ist schon drauf. Im aktuellen Entwurf ist auch ein ISP-Header mit drauf.
Gruß
Dirk
pir module wie aus dem ersten link gibt es bei ebay noch günstiger.
und ja. das ansprechende gehäuse ist ist wirklich ein problem. das von dir verlinkte finde ich zum beispiel genau nicht ansprechend :).
auf der jeelabs web seite gab es vor einiger zeit mal die idee den sensor so in eine zimmerdecke zu setzen das eine dreieckige abdeckung als 'gehäuse' reicht. ich finde etwas in der art würde am aller besten aussehen.
gruss
andre
ps: an einer hand voll platinen wäre ich auch interessiert wenn es so weit ist. auch wenn ich die dinger mit einem SWAP sketch betreiben werde.
Zitatpir module wie aus dem ersten link gibt es bei ebay noch günstiger.
Günstiger als 0,75€ pro Stück?
Zitatund ja. das ansprechende gehäuse ist ist wirklich ein problem. das von dir verlinkte finde ich zum beispiel genau nicht ansprechend :).
Da gebe ich dir recht. Das was das ansprechendste was ich gefunden habe :)
Gruß
Dirk
ggf. könnte man sich auch bei den Gehäusen für Innenraum-Überwachungskameras umschauen. Da gibts designmäßig wahrscheinlich hübschere Lösungen.
ZitatGünstiger als 0,75€ pro Stück?
ups... bei der stückzahl nicht aufgepasst :)
ich finde grad keinen link zur nur dreieck version. aber die dies geht in diese richtung: http://jeelabs.org/2010/01/ (http://jeelabs.org/2010/01/) wenn man das von der verarbeitung und material richtig macht finde ich es ziemlich gut.
gruss
andre
ich habe gerade mal ein wenig datasheet geschmökert - http://www.ladyada.net/media/sensors/BISS0001.pdf
in den sensormodulen ist der BISS0001 verbaut, blöderweise wird das timing und die empfindlichkeit über RC glieder gemacht,
geht also nicht direkt zum ansteuern über einen atmel.
spontan fallen mir zwei lösungen ein - dac über widerstandsnetzwerk, oder so einen kleinen i2c widerstandsreglerchip
gibts noch andere ideen?
so wie es aussieht ist auf den modulen ein spannungsregler drauf, der chip arbeitet auch bei 3 volt, zumindest das ist schon mal eine gute nachricht....
auch eine ganz gute seite zum thema: http://www.instructables.com/id/PIR-Motion-Sensor-Tutorial/?ALLSTEPS
Hi Trilu,
spitze was du da gebaut hast.
Ist das sehr schwierig? Ich würde das ja gern auch bauen (bräuchte 8 Stück dieser Sensoren), habe aber noch nie gelötet. Gibts sowas auch als "Steckbaukasten"!? Was kosten die Teile zusammen? Könntest du evtl. eine Liste aller Bauteile posten? Was wenn man den Luftdrucksensor weglässt? Mit der Software sehe ich keine Anwendungsprobleme, aber bei der Hardware bzw. eben dem Löten sehe ich grosse Probleme für mich. Ich hab ja noch nicht mal einen Lötkolben! :-) Feinmechanisch dürfte es nicht schwierig werden, da ich als Zahntechniker fummelei mit dem Mikroskop gewohnt bin. Sind die Teile sehr hitzeempfindlich? Zum Einstieg in die Löterei ist das wohl weniger geeignet, oder?
bye
Klaus
Zitataber die dies geht in diese richtung: http://jeelabs.org/2010/01/ wenn man das von der verarbeitung und material richtig macht finde ich es ziemlich gut.
Das sieht auf alle Fälle interessant aus.
Zitatspontan fallen mir zwei lösungen ein - dac über widerstandsnetzwerk, oder so einen kleinen i2c widerstandsreglerchip
Das waren auch meine Ideen. Der AD5258 währ so ein Digitalpotentiometer. Je nach Anbieter 1-2€
Zitat von: Alaska am 25 Februar 2014, 12:49:42
Ich würde das ja gern auch bauen (bräuchte 8 Stück dieser Sensoren)
Nicht so schnell :)
Wir sind grade beim entwerfen des Sensors.
Bis das Layout fertig ist und die Platinen des ersten Prototypen da sind, dauert es bestimmt noch 2 Wochen.
Gruß
Dirk
Hallo Dirk,
achso, ich dachte das Setup aus dem ersten Post könnte man anhand der Materialliste nachbauen... :-)
Wenn ich irgendwie helfen kann, dann gerne...und wenns nur als Betatester ist. Wie hoch würden die Kosten grob geschätzt auf so einen Sensoren kommen?
Hi Klaus,
Danke für die Blumen!
Ich dachte man muss als Zahntechniker auch löten können, zumindest ist in meinen Kronen jede Menge Metall :-)
Das Zeug gibt es eigentlich alles Steckbrett tauglich, die Frage sind nur die Kosten. Und wenn du sagst, du brauchst 8 Stück davon, dann gehe ich von einem produktiven Einsatz aus, da ist dann Steckbrett nicht sonderlich hübsch.
Vielleicht wartest du einfach bis die Platinen bei Dirk verfügbar sind, dann findet sich bestimmt jemand der dir die 8 Dinger lötet.
Kostenmäßig halt sich das Teil sehr in Grenzen. In meinen Bildern ist das teuerste der Panstamp. Aber der kommt in der Platinenversion nicht zum Einsatz.
Arduino Pro Mini - ca. 3 Euro
Funkmodul - ca. 5 Euro
SHT10 - ca. 5 Euro
BMP180 - ca. 3 Euro
Platine????
Gehäuse???
PIR Sensor - supergünstig <1 Euro
Viele Grüße
Horst
Spannend!
Ich versuche auch etwas ahnliches aufzubauen, allerdings mit einem rfm12b und attiny84.
Verrückt, aber das Schwierigste scheint ein schönes und bezahlbares Gehäuse zu sein...
Wenn man schon das gesamte Innenleben selbst zusammen bastelt, könnte man bei Gehäuse genauso vorgehen.
Was haltet ihr von einem Gehäuse aus dem 3d Drucker? Der große Vorteil wäre, dass man das Gehäuse genau an die Bedürfnisse anpassen könnte. :)
ZitatGehäuse aus dem 3d Drucker
Vielleicht...
Kostenpunkt? ...und wer könnte das disignen?
ZitatWas haltet ihr von einem Gehäuse aus dem 3d Drucker?
Wenn man sich die Drucker mit Schmelzschicktverfahren ansieht, möchte ich mir davon aktuell noch kein Gehäuse an die Wand hängen :)
Das Gehäuse aus meinem Link unten finde ich eigentlich ganz schick.
Am Donnerstag habe ich das hier. Dann kann ich ein "Echtfoto" davon hier reinstellen.
Zitat von: trilu am 25 Februar 2014, 13:03:39
Arduino Pro Mini - ca. 3 Euro
Funkmodul - ca. 5 Euro
SHT10 - ca. 5 Euro
BMP180 - ca. 3 Euro
Platine????
Gehäuse???
PIR Sensor - supergünstig <1 Euro
Leerpatine ~ 3-5€
Gehäuse aus dem Link unten ~ 2-3€
Gruß
Dirk
Hallo,
ich dachte auch mehr das in HW vorzusehen und nutzen kann dann jeder was er möchte ;)
z.B. Finde ich ein Luftdrucksensor macht normal in jedem Raum keinen Sinn.
Da reicht einer.
Aber für Temp, Luftfeuchte, Helligkeit und Bewegung hätte ich schon Ideen die auch sinnvoll in jedem Raum zu nutzen sind. Zudem noch eine Outdoor Variante.
Zum 3D Drucker: Auch wenn div Bekannter immer mal wieder einen Anschaffen wollen sehe ich den Sinn noch nicht. Das Connair Gehäuse war ganz schön hässlich ;)
Nico
ZitatDas Connair Gehäuse war ganz schön hässlich
Du meinst das vom Bewegungsmelder? Ja ist nicht so schön.
Da wir hier aber im Tread vom Temperatur / Feuchte / Luftdruck / Helligkeitssensor sind, meine ich dieses Gehäuse hier:
http://static3.tme.eu/katalog_pics/5/4/4/54492c6918313ffc888d3ded8d3a76ea/box-sens-white.jpg
Zitatz.B. Finde ich ein Luftdrucksensor macht normal in jedem Raum keinen Sinn.
Nein, den muss man auch nicht jedesmal bestücken. Da ich aber keine x verschiedenen Playtinenlayouts machen möchte, ist der Footprint auf der Platine trotzdem vorgesehen.
Gruß
Dirk
ZitatGehäuse aus dem Link unten ~ 2-3€
Habe ich den Link übersehen, oder wo kann man das kaufen?
Danke für die Antworten.
@trilu
ja, wir Zahntechniker löten, aber nur mit Flamme, hoher Temperatur und eher flächig bzw. verbinden wir eher Flächen miteinander, keine kleinen Punkte, so wie in der Elektrotechnik gebraucht. Leider ;-)
@Dirk
Also die Kosten halten sich ja wirklich sehr in Grenzen.....auf jeden Fall kommt man um etliches günstiger im Vergleich zu den originalen Homematic Temp-/Feuchtesensoren. Vor allem wenn ich 8 Stück brauche! Gehäuse könnte sich jeder selber fräsen, usw. lassen, z.B. hier: http://www.shapeways.com/ Man bräuchte "nur" eine STL Datei oder dergleichen.
Da ich bisher noch keine Homematic Komponenten besitze, bräuchte ich auch keinen HM-Lan-Adapter, oder? Ein CUL reicht mir dann voll aus, wenn ich das bisher richtig verstanden habe?
bye
Klaus
Zitat von: Dirk am 25 Februar 2014, 13:52:22
http://static3.tme.eu/katalog_pics/5/4/4/54492c6918313ffc888d3ded8d3a76ea/box-sens-white.jpg
Das Gehäuse sieht doch optimal aus. Da lohnt es sich nicht ein eigenes zu erstellen.
Zitat von: trilu am 25 Februar 2014, 13:03:39
Kostenmäßig halt sich das Teil sehr in Grenzen. In meinen Bildern ist das teuerste der Panstamp. Aber der kommt in der Platinenversion nicht zum Einsatz.
Arduino Pro Mini - ca. 3 Euro
Funkmodul - ca. 5 Euro
SHT10 - ca. 5 Euro
BMP180 - ca. 3 Euro
Platine????
Hat ein XinoRF von Ciseco (35€) eigentlich nicht alles benötigte on board außer den Sensoren?:
http://www.exp-tech.de/Mainboards/Arduino/XinoRF-Arduino-UNO-R3-based-dev-board-with-radio-transceiver.html (http://www.exp-tech.de/Mainboards/Arduino/XinoRF-Arduino-UNO-R3-based-dev-board-with-radio-transceiver.html)
Es gibt dann auch eine kompaktere Version für 20€, ist aber nichts für's Prototyping:
http://www.exp-tech.de/Shields/Wireless/Funk/RFu-328-Arduino-ATMega-328-compatible-radio-transceiver-RFu-328.html
Gefunden!
http://www.tme.eu/de/details/box-sens-white/gehause-fur-alarmgerate-und-sensoren/supertronic/#
oder (IMHO weniger schön):
http://www.tme.eu/de/details/abs-84/gehause-fur-alarmgerate-und-sensoren/#
@himtronics
Die erste Version ist (viel) zu groß und zu teuer, die zweite ist schon besser, aber auch doppelt so teuer, wie eigenbau. Mit den Sensoren hat man den Preis von HomeMatic.
Außerdem: wo bleibt der Spaß? ;)
Zitat von: hexenmeister am 25 Februar 2014, 14:02:39
oder (IMHO weniger schön):
http://www.tme.eu/de/details/abs-84/gehause-fur-alarmgerate-und-sensoren/#
Daher habe ich für die Platienenabmessungen das andere Gewählt :)
Als Farben stehen dann noch Elfenbein und Schwarz zur Verfügung.
Zitat von: himtronics am 25 Februar 2014, 14:01:15
Es gibt dann auch eine kompaktere Version für 20€, ist aber nichts für's Prototyping:
Auf den ersten Blick würde ich sagen dass das Tranceiver-Modul hier nicht mit dem CC1101 kompatibel ist.
Also müsste man zumindest die Firmware von Trilu dafür speziell anpassen.
Gruß
Dirk
hallo allerseits,
mein respekt für euer projekt. da wird man ja förmlich "gezwungen" nach zu bauen.
die temperatur/luftfeuchte variante wäre in verbindung mit einer einfachen eingabemöglichkeit auch als thermostat ganz schön. eventuell nur ein poti oder mehrfachschalter, um die solltemperatur einzustellen.
aber last euch nicht stören.
gruss frank
ZitatAlso müsste man zumindest die Firmware von Trilu dafür speziell anpassen.
Auch wenn, man bräuchte dann noch ein Empfänger. Das hier soll doch mit HMLAN oder CUL funktionieren.
ZitatAuch wenn, man bräuchte dann noch ein Empfänger. Das hier soll doch mit HMLAN oder CUL funktionieren.
Daher müsste man das dann ja anpassen, damit das Teil dann auch "Homematic spricht".
Der Aufwand lohnt sich vermutlich aber nicht.
@dirk Nein, ich meinte schon das vom connair, da das wohl 3d gedruckt war.
http://wiki.simple-solutions.de/de/products/Conn_Air
Ich hatte das Teil zuhause, um meine ELROs zu schalten, bevor ich zu fhem gewechselt bin.
Ein anderes 3D Druckstück hatte ich noch nicht in der Hand.
Ich finde das Gehäuse Das Du hattes OK, zumal ich nicht weiss ob man für den Preis einen 3D Druck hinbekommt.
Wenn noch Pinne frei sind, könnte man ja auch noch einen Eingang für Schalter vorsehen. ggf via Widerstand-Matrix. Um das Teil auch noch als Fenster-/Tür Kontakt zu nutzen.
Oder Anschlüsse am AnalogPort um einen Feuchtigkeitsmesser für Pflanzen zu bauen.
bzw um, wie schon vorgeschlagen, mittels Poti die Temperatur am Sensor zu regeln.
Ich bin gerade dabei und versuchte den JeeLink-Airwick nachzubauen und hatte mir da Gedanken um solche "Erweiterungen" gemacht. Ich würde das Einstellen und auf Homematic gehen, um auch direkt koppeln zu können.
Nico
Welcher Sensor ist eigentlich für die Helligkeit gedacht (habe beim Durchbättern nicht finden können...)?
Ich selbst spiele gerade mit BH1750 rum. Geht eigentlich ganz gut...
Zitat von: santalaus am 25 Februar 2014, 14:22:40
@dirk Nein, ich meinte schon das vom connair, da das wohl 3d gedruckt war.
Achso, wobei das Bild aus deinem Link gar nicht so schlecht aussieht. Vermutlich ist das aber nur das 3D-Modell.
Zitat
Wenn noch Pinne frei sind, könnte man ja auch noch einen Eingang für Schalter vorsehen. ggf via Widerstand-Matrix. Um das Teil auch noch als Fenster-/Tür Kontakt zu nutzen.
Der Sensor soll ja keine "eierlegende Wollmilchsau" werden.
Ich werde als nächstes aber ein einfaches Shield für den Arduino layouten nur mit dem CC1101-Modul. Da werden dann alle Ports mit rausgeführt. Sicher macht es dann noch Sinn gleich ein Paar freie Lötpads da mit drauf zu machen.
Zitat von: hexenmeister am 25 Februar 2014, 14:28:14
Welcher Sensor ist eigentlich für die Helligkeit gedacht (habe beim Durchbättern nicht finden können...)?
Ich selbst spiele gerade mit BH1750 rum. Geht eigentlich ganz gut...
Auf dem Layout habe ich aktuell den TSL2561 vorgesehen.
Vorteil gegenüber den BH1750:
Der TSL2561 kann bei Helligkeitsänderungen Interrupts auslösen. Somit muss der nicht ständig gepollt werden.
Gruß
Dirk
Gruß
Dirk
@hexenmeister
kannst du mal ein get regList von deinem HM-Sen-MDIR-O posten?
Zitat von: Dirk am 25 Februar 2014, 14:08:59
Auf den ersten Blick würde ich sagen dass das Tranceiver-Modul hier nicht mit dem CC1101 kompatibel ist.
Also müsste man zumindest die Firmware von Trilu dafür speziell anpassen.
Ist ein CC1110, im Prinzip ein CC1101 mit 8051 CORE und einem serial port. Aber stimmt schon,
die Firmware müsste man anpassen.
Zitatein get regList von [...] HM-Sen-MDIR-O
Klar doch ;)
fhem> get UM_VH_HMBL01.Eingang regList
list: register | range | peer | description
0: pairCentral | 0 to 16777215 | | pairing to central
1: brightFilter | 0 to 7 | | brightness filter - ignore light at night
1: captInInterval | literal | | capture within interval options:on,off
1: evtFltrNum | 1 to 15 | | sensitivity - read each n-th puls
1: evtFltrPeriod | 0.5 to 7.5s | | event filter period
1: ledOnTime | 0 to 1.275s | | LED ontime
1: minInterval | literal | | minimum interval in sec options:240,60,120,30,15
4: peerNeedsBurst | literal | required | peer expects burst options:on,off
ZitatDer TSL2561 kann bei Helligkeitsänderungen Interrupts auslösen. Somit muss der nicht ständig gepollt werden.
Den kenne ich (noch) nicht, muss mir ansehen bezüglich Daten/Verfügbarkeit/Preis.
Kann man da die Schwelle einstellen? ansonsten ändert sich der Wert öffter, als ich polle ;)
Ich sehe das nicht als Problem, der µC muss je immer mal wieder aufwachen. Bei mir werden Sensoren (BMP085, DHT22, BH1750) komplett abgeschaltet (stromlos) und nur einmal pro Minute zur Messung wieder 'geweckt'.
Bei BH1750 gefällt mir die Möglichkeit, durch Registermanipulation die Empfindlichkit so zu regeln, dass man sowohl Werte um die 0,1 (richtig dunkel, draußen eig. nicht zu erreichen) als auch über 100.000 (direkte Mittagssonnne im Sommer bei wolkenlosem Himmel) messen kann. Damit die Empfindlichkeit automatisch geregelt wird, musste ich zwar einen Treiber selbst schreiben, dies ist aber bei den Dingern ja nicht wirklich schwer (hier, evtl. kann jemand gebrauchen: https://github.com/hexenmeister/AS_BH1750) ;)
Zitat von: hexenmeister am 25 Februar 2014, 18:08:56
Kann man da die Schwelle einstellen? ansonsten ändert sich der Wert öffter, als ich polle ;)
Ja. Aus dem Datasheet: "Programmable Interrupt Function with User-Defined Upper and Lower Threshold Settings" und "Programmable Analog Gain and Integration Time Supporting 1,000,000-to-1 Dynamic Range"
ZitatIch sehe das nicht als Problem, der µC muss je immer mal wieder aufwachen. Bei mir werden Sensoren (BMP085, DHT22, BH1750) komplett abgeschaltet (stromlos) und nur einmal pro Minute zur Messung wieder 'geweckt'.
So könnte man aber sofort bei bestimmten Helligkeitsänderungen eine Nachricht an FHEM verschicken. Bei Temperatur/Feuchte und Luftdruck sollte es ausreichen alle 2-3 Min. zu pollen. Spart noch etwas mehr Energie.
Den "Treiber" des BH1750 in das Sketch einzubauen dürfte aber auch nicht viel Aufwand sein.
Der DHT22 fängt halt erst bei 3,3 Versorgungsspannung an. Da wird eine Energieversorgung mit nur 2 Zellen schwierig. Und der CC1101 geht nur bis Max. 3.6V.
Also bräuchte man hier immer einen Spannungsregler für die 3,3 V Komponenten. Dieser macht bei batteriebetriebenen Sensoren einen nicht unerheblichen Teil des Energieverbrauches aus.
Gruß
Dirk
Scheint ein gutes Device zu sein ;) (und ist bei ALi recht günstig)
"Treiber" ist natürlich etwas übertrieben, die Dinger sind ja sehr einfach gestrickt.
Der DHT22 funktioniert praktisch ab etwa 3V. Und RFM12B bis etwas über 4V.
Einen Regler möchte ich natürlich auch nicht haben, daher versorge ich mein Prototyp mit einem 3,7 Lithium-Akku.
Mit einem vollgeladenen Akku (18650 mit 4,5Ah) läuft es schon seit 2.2.14 und die Spannung fiel von 4,096 auf aktuell 4,022.
Das dürfte über einen Jahr durchhalten ;) Später gedenke ich 1-2 Stück von 14500er (1,6Ah) benutzen. Sind billig und brauchen nicht zu viel Platz.
Ich muss aber gestehen, Deine Hardware gefällt mir noch besser, werde bestimmt auch nachbauen ;)
Moin !
Vielleicht wäre es in Sachen Bewegungsmelder keine schlechte Idee, sich einfach mal günstige
Melder am Markt anzuschauen. Ggf. gibt es ja einen günstigen, bei dem man schlicht nur das
Innenleben erweitern oder austauschen muss (analog, zu Dirk's Taster Projekt).
Mir würde allerdings im ersten Schritt eine anständige FW für den HM-Sen-MDIR-O reichen. Die
originale finde ich ziemlich mies, da man z.B. das Versenden der Helligkeitwerte nicht deaktivieren
kann. Nicht jeder braucht das, aber man kann diesen zyklischen Elektrosmog nicht abschalten >:(
Gruß, Marc
Hallo Dirk !
Zitat von: Dirk am 24 Februar 2014, 21:32:49
Hier nochmal ein Link mit 5 Modulen. Die sind dann etwas günstiger:
http://www.aliexpress.com/item/5pcs-lot-CC1101-868MHz-wireless-module-distance-for-300m-Free-shipping/1104732817.html
Ich, und bestimmt auch Trilu haben bestimmt noch ein Paar Module übrig.
Danke für die Infos ! Ich habe mir mal präventiv fünf Stück geordert.
Gruß, Marc
ZitatNicht jeder braucht das, aber man kann diesen zyklischen Elektrosmog nicht abschalten >:(
Ich denke nicht, dass beim Abschalten von Helligkeitsmeldungen eine messbare Verringerung der durchschnittlichen Belastung nachgewiesen werden kann.
Dann muss man schon komplett auf HomeMatic (Handy, WLAN, Staubsauger, Mixer, El. Zahnbürsten, Microwellen- und Ceranherde und vieles andere) verzichten und in ein Beton/Stahl/Blei-Bunker umzihen. Dann könnte ein empfindliches Gerät (vielleicht) eine Veränderung anzeigen. ;)
Spaß bei Seite, wäre in so einem Fall nicht ein drahtgebundenes Gerät besser geeignet?
Grüße,
Alexander
ZitatIch denke nicht, dass beim Abschalten von Helligkeitsmeldungen eine messbare Verringerung der durchschnittlichen Belastung nachgewiesen werden kann.
Ich schon ;D
Die Frage ist ja, wie wird der Helligkeitswert versendet, ist es ein oder zwei Byte mehr in einer Message vom Bewegungsmelder, dann ist die Ersparnis marginal.
Eben nur der Unterschied von 15 Byte zu 13 Byte, 8%
Wird er in einer eigenen Message versendet, dann ist das erheblich....
1: brightFilter | 0 to 7 | | brightness filter - ignore light at night
1: captInInterval | literal | | capture within interval options:on,off
1: evtFltrNum | 1 to 15 | | sensitivity - read each n-th puls
1: evtFltrPeriod | 0.5 to 7.5s | | event filter period
1: minInterval | literal | | minimum interval in sec options:240,60,120,30,15
Die Flags sind ja nicht selbsterklärend - Kannst du die ein wenig beschreiben?
Mit "brightFilter" kann man vermutlich einen Helligkeitswert definieren ab dem der PIR Sensor arbeitet?
0 ist unabhängig von Helligkeit, 7 ist keine Reaktion bei Nacht?
"evtFltrPeriod" wenn ein Impuls gesendet wurde, wird die Zeit x gewartet bis wieder einer gesendet wird?
Bei den anderen Werten fällt mir nicht wirklich was ein...
Für die Belastungt des HomeMatik-FunkBandes - vielleicht, für die Gesamtbelastung im ganzem EM-Spektrum - wohl kaum. Das wird kaum ein Bruchteil einer Promille ausmachen, daher würde ich mit Elektrosmog nicht argumentieren. aber Schwamm drüber... ;)
Das Gerät liefert bei mir alle 4 Minuten (einstellbar) einen Helligkeitswert. Bei erkannten Bewegungen kommen Meldungen meines wissens sofort.
ZitatDie Flags sind ja nicht selbsterklärend - Kannst du die ein wenig beschreiben?
Wegen 'nicht selbsterklärend' kann ich sie auch nur teilweise erklären ;)
minInterval - ist wohl klar
brightFilter - s. hier: http://forum.fhem.de/index.php/topic,10226.msg57438.html#msg57438
(grob - eliminiert die Helligkeitsschwankungen durch Durchschittsberechnungen)
(und PIRSensor arbeitet immer unabhängig von Helligkeit. Diese wird wohl von dem gepairten Gerät ausgewertet)
evtFltrNum und evtFltrPeriod - kann ich nur raten. Stehen bei mir beide auf 1. Ich vermute, dies bedeutet, dass in einem Interval von <evtFltrPeriod> Sekunden <evtFltrNum>-Stück einzelner Messungen aufsummiert werden. oder so ähnlich...
captInInterval - keine Ahnung.
Es gibt noch R-ledOnTime und R-pairCentral, die nicht mit regList geliefert werden. Beide sind jedoch selbsterklärend.
Hi !
Mir ist schon klar, das die Belastung minimal ist. Wir leben aber in einer Welt, in der man ständig, von allen Seiten
und über eine weites Frequenzspektrum hinweg EM-Feldern ausgesetzt ist. Da ist es legitim zu fordern, dass man
wenigstens die Anteile - und seinen sie noch so klein - die überflüssig sind auch abschalten kann. Ich habe derzeit
drei HM-Sen-MDIR-O, welche dreimal die gleiche Information liefern, was vollkommen überflüssig ist. Abgesehen
davon, werden die Batterien unnötig belastet, da das maximale Intervall der Übertragung 3 Minuten beträgt.
Prinzipiell nutze ich bei Sensoren, die zyklisch Messwerte liefern, 1w Sensoren, nur die drei Bewegungsmelder
sind noch nicht ersetzt. Wie auch immer, es wäre halt schön, wenn man es abklemmen könnte ....
Der Artikel zum HM-Sen-MDIR-O ist übrigens bei ELV kostenlos verfügbar (eigenartig, sonst kostet das immer ein
paar Cent ...): http://www.elv-downloads.de/bilder/journal/2013_02/03/130377_hm_sen_mdir_o.pdf
Leider liefert er keine weitergehenden Erkenntnisse zu den Registern, aber zumindest den Schaltplan Ein paar
Informationen hatte Martin schon einmal zur Verfügung gestellt: http://forum.fhem.de/index.php/topic,12266.msg73109.html#msg73109
Und der bereits erwähnte Thread liefert die Information zum brightFilter, der einen in den Wahnsinn treibt, wenn man
die Erklärung nicht kennt !
Gruß, Marc
Hallo zusammen
heute habe ich die Gehäuse bekommen.
Anbei mal ein Bild auch vom Innenleben mit "ausgedruckter Platine" und Batteriehalter.
Ich wollte mal sehen ob das ganze da so reinpasst.
Der Batteriehalter nimmt 2 AA-Batterien auf. Dadurch sollte ein mehrjähriger Betrieb des Sensors mit einer Batterieladung möglich sein.
Anbei auch schon mal der Schaltplan und das Platinenlayout vom Sensor. Vielleicht hat der eine oder andere noch Verbesserungsvorschläge.
Auf der Platine kann entweder ein Arduino-Mini-Pro bestückt / Aufgesteckt werden, oder alternativ ein Atmega328 mit entsprechender Außenbeschaltung bestückt werden.
Die Sensoren für Feuchte/Temperatur, Luftdruck und Helligkeit können alle oder auch nur einzeln bestückt werden.
Aus Platzgründen sind Sie Sensoren ohne Adapter direkt auf der Platine zu bestücken.
Da nicht jeder SMD löten kann und vor allem der BMP180 nur Sinnvoll mit Reflow oder Heisßluft gelötet werden kann, würde ich euch die entsprechenden Sensoren schon auf die Platine bestücken.
Somit ist dann "nur" noch der Arduino und das Funkmodul zu bestücken.
Für jemand der gar nicht löten möchte / kann, finden wir bestimmt auch eine Lösung :)
Den Wettersensor2 den ich geplant habe, ist für das "Gehäuse2". Da dieses Wasser und somit auch Luftdicht verschlossen werden kann ist es perfekt für den Außeneinsatz.
Daher habe ich hier auch "nur" den Helligkeitssensor und den Luftdrucksensor gepant. Der I2C-Bus ist hier allerdings auf einen Stecker geführt, so dass man ggf. noch externe I2C-Sensoren anschließen kann.
Um den Luftdrucksensor sinnvoll zu benutzen ist es hier dann aber erforderlich ein kleines Loch in das Gehäuse zu bohren. Wenn man das an der Unterseite macht, dann ist das Gehäuse immer noch Spritzwasserdicht.
Da das Gehäuse etwas kleiner ist, passt hier nur ein Batteriehalter mit 2 AAA-Zellen rein.
Viele Grüße
Dirk
Update:
Der Helligkeitssensor macht im Gehäuse1 natürlich nur Sinn, wenn der auch etwas Licht abbekommt.
Meine Idee ist daher ein kleines Loch im Deckel in einer Art "Lichtleiter". Ein kleiner 3 mm Acrylstab sollte da funktionieren.
Update2:
Update: Schematic gelöscht. Überarbeitet Version ist hier:
http://forum.fhem.de/index.php/topic,20620.msg143914.html#msg143914
Na, das sieht ja schon super aus!
Hast Du schon eine Vorstellung, was so eine halbbestückte Platine kosten soll?
Grüße,
Alexander
ZitatHast Du schon eine Vorstellung, was so eine halbbestückte Platine kosten soll?
Noch nicht. Das wird dann auch davon abhängen welche Sensoren da alle bestückt werden.
Vielleicht organisiere ich auch eine Sammelbestellung dann muss nicht jeder alles selber bestellen.
Ich werde das die Tage mal durchrechnen.
Luftdruck z.B. wird jeder in der Regel nur einmal benötigen.
Gruß
Dirk
ZitatLuftdruck z.B. wird jeder in der Regel nur einmal benötigen.
Oh! Schade, ich wolle sie in meinem Raumschiff einsetzen. Bei den luftdichten Schleusen möchte ich den Druck in jedem Raum wissen ;D
Spaß beiseite, ich finde eine Sammelbestellung eine gute Idee.
Wenn man die Platine je in offen steckt, wäre dann nicht sinnvoll in jedem fall den atmel mit draufzubacken?
ProMini ist schon relativ klobig und die Power-LED muss auch noch runter...
(http://s6z.de/cms/images/content/arduino/Board_ProMini_03_k.png)
ZitatOh! Schade, ich wolle sie in meinem Raumschiff einsetzen. Bei den luftdichten Schleusen möchte ich den Druck in jedem Raum wissen ;D
Dafür gibt es dann die Space-Edition :)
ZitatWenn man die Platine je in offen steckt, wäre dann nicht sinnvoll in jedem fall den atmel mit draufzubacken?
So ist das geplant. Der eine oder andere will aber sicher was selber machen. Daher habe ich beide Bestückunsvarianten vorgesehen.
Zitat... und die Power-LED muss auch noch runter...
Ja, entweder so, oder die entsprechende Leiterbahn durchtrennen.
ZitatDafür gibt es dann die Space-Edition
Sehr gut, bin ungemein beruhingt! Aber bitte auch einen vernünftigen Fluxkompensator miteinplanen!
;D
Zitatoder die entsprechende Leiterbahn durchtrennen.
fummelig auf dem kleinen raum... ich habe immer den dazugehörigen widersand ausgelötet, erscheint mir einfacher...
Zitat von: hexenmeister am 27 Februar 2014, 18:47:32
Sehr gut, bin ungemein beruhingt! Aber bitte auch einen vernünftigen Fluxkompensator miteinplanen!
Und einen Heisenbergkompensator! Dann bin ich auch dabei 8)
Hallo Dirk,
Ich bin begeistert , tolle Sache das.
Würde mich mit Interesse an 2 -4 Platinen mich anmelden mit
SMD Bestückung den Rest zu löten trau ich mir dann doch zu.
Gruß und Respekt
Stefan
Hallo,
finde ich auch super.
Ich habe Interesse an 8 Stück wobei ich nur 1* den Luftdruck brauchen würde, aber SMD löten wäre nicht das Problem.
Wenn ich das richtig gesehen habe, sind ja alle Pinne des verlöteten ATMega auf die ProMini Leisten verbunden, dann könnte ich damit basteln und ggf meine Erweiterungen anschliessen.
Ich möchte Versuchen mit einem Sensor pro Raum hinzukommen. Mal sehen.
Zunächst denke ich an Bewegung, wie erwähnt und mehrere Temperaturen zu messen.
(Bewegung in jedem Raum, die Temepraturen dachte ich in der Küche Raum/Kühlschrank/Froster)
Nico
ZitatWenn ich das richtig gesehen habe, sind ja alle Pinne des verlöteten ATMega auf die ProMini Leisten verbunden ...
Das ist korrekt. Somit kann die Platine etwas universeller eingesetzt werden. Das Teil ist dann Kompatibel zum Arduino-Pro-Mini. Mit ein paar kleinen Ausnahmen. Somit sollten auch andere Arduino-Erweiterungen hier passen.
Der Reset-Pin unten (JP7-10) entspricht dem DTR. Denn die Pinreihe an der Seite gibts hier nicht. TXD, RXD und VCC sind aber an den anderen Pinreihen verfügbar.
Der Spannungswandler, die LED der Resettaster und der Quarz sind ebenfalls nicht vorhanden weil für die geplante Anwendung nicht benötigt.
Falls jemand im Schaltplan bzw. in den Layouts Fehler findet bzw. noch Ideen hat, dann her damit.
Ich plane gegen Anfang / Mitte der Woche die Platinen un die Produktion zu geben.
Vermutlich erst einmal ein 10'er Packt als Prototyp. Wenn dann alles funktioniert wie es soll dann mehr.
Gruß
Dirk
Ich bin auch sehr interessiert und könnte 8 oder eher 10 Stück gut gebrauchen. Kommt aber auch stark auf den Preis an. Ich muss noch entscheiden, ob ich meine (noch halbfertige, aber schon recht gut funktionierende und vor allem sehr günstige) JeeLink-basierte Lösung absetze. :-\
echt geil was ihr hier baut!!! RESPEKT.....
Wie schon mal geschrieben: 8 Stück können schon für mich reserviert werden :-)
Zahle auch gern ein paar Euro mehr wenn mir jemand die Lötung macht.....habe heute versucht bei einem Bekannten ein paar kaputte Teile auf eine Platine zu löten - ohje.....das Lot war überall, nur nicht da wo es hin sollte....die Platine war im Eimer...zum Glück war es nur ein Test.
ZitatWie schon mal geschrieben: 8 Stück können schon für mich reserviert werden :-)
von welcher Version?
Anbei übrigens das Layout für das Außengehäuse aus dem Beitrag:
http://forum.fhem.de/index.php/topic,20620.msg143214.html#msg143214
Dieses hat wie, schon geschrieben "nur" die Sensoren für Luftruck/Temperatur und Helligkeit an Bord.
Über ein den externen I2C-Bus kann man ggf. noch andere Sensoren anschließen. z.B. einen nach außen gelegten Temperatur/Feuchte Sensor.
In diesem Gehäuse wird man wohl keine sinvollen Temperatur/Feuchte-Werte bekommen.
Gruß
Dirk
Update:Anhang gelöscht. Überarbeitet Version ist hier:
http://forum.fhem.de/index.php/topic,20620.msg143914.html#msg143914
seid ihr schon bei der Sammelbestellung? ich nehme auch 8 wenn es schon so weit ist.
Hi,
wenn es das ist, was ich glaube, dann bin ich erstmal (zum Ausprobieren) mit 2 Stück dabei. Wenn es gut funktioniert, dann später so ungefähr 20. (Mein Haus hat ein paar Zimmer...) Falls das so möglich wäre.
Die Dinger sind ja anscheinend sogar kleiner als die "Originale" und sehen mit den Gehäusen wesentlich besser aus. Echt eine geniale Arbeit!
Ich habe aber ein bisschen den Überblick verloren, was hier genau sammelbestellt werden soll. Es ist klar, dass es um eine Platine geht, die mit entsprechender Software mit Homematic reden kann. Anscheinend sind zwei Versionen geplant:
1. Mit Bestückung der SMD-Teile
2. Ohne alles
Außerdem gibt es möglicherweise zwei unterschiedliche Gehäuse. Je nach Sensor muss man noch ein kleines Loch bohren und/oder einen kleinen Acrylstab reinstecken.
Dann war da noch der Controller. Zuerst war der Plan, dass man den selbst draufstecken/löten muss, dann war im Gespräch, dass das Ding gleich mit draufgebacken wird.
Zu den Sensoren: Möglich scheint zu sein: Temperatur, Feuchte, Luftdruck, Helligkeit, Bewegung. Sind die Dinger dann gleich mit drauf oder bestellt man die sich dann selbst? ...oder Sammelbestellung und dann selber löten.
Bezüglich selber löten: Durch praktisch gesammelte Erfahrung weiß ich, dass meine Geschicklichkeit bei etwa 2,54mm Rastermaß endet. Wird das reichen?
Danke&Gruß,
Thorsten
Hi Dirk,
das sieht ja richtig klasse aus - sehr professionell.
Kannst du schon abschätzen wann du die ersten Prüfmuster haben wirst und was so eine Platine etwa kosten wird?
Macht es Sinn das ich mir schon mal ein paar Gehäuse bestelle?
Was ich mir auch gerade überlegt habe, eigentlich könnte man den Bewegungsmelder mit in so ein Gehäuse packen, ist ja nur ein Loch
so dass der PIR Sensor rein passt...
Viele Grüße
Horst
Hallo Dirk,
da die Orderwut langsam ausbricht kann ich dir meine Unterstützung bei der, Kommissionierung, Verpackung und Versand anbieten. Habe hier im Haus einen Hermes Paketshop.
Ich will mich nicht aufdrängen, nur ein Vorschlag zu deiner Entlastung.
Gruß
Stefan
hallo,
wie sieht es eigentlich mit der "leistungsfähigkeit" des atmega328 aus?
da ich auch gerne 5-10 stück ordern würde ;), diese aber gegebenenfalls zu thermostaten mit sollwerteingabe und eventuell display erweitern möchte, stellt sich mir die frage: wieviele funktionen kann man denn in diesen atmega überhaupt reinpacken?
das ist wahrscheinlich alles sehr spekulativ, da das gute stück noch nicht wirklich existiert. vielleicht gibt es aber schon hinweise, wie ausgelastet zb der speicher sein wird, wenn das device alle geplanten funktionen enthält.
desweiteren habe ich grosses zutrauen in die community, dass irgendwann die möglichkeit des firmware updates per funk realisiert wird! :) diese funktion würde ich dann natürlich gerne in den devices integrieren wollen.
kann man zb beim vergleich mit dem prozessor des rt (STM8L152) spekulieren, dass ein funkupdate eventuell gar nicht mit dem atmege328 gehen kann?
vielleicht hat ja jemand vage vermutungen zu meinen spekulativen fragen! 8)
gruss frank
Wie war das mit dem Fell des unerlegten Bären? ;)
Lasst doch Dirk erstmal bauen!
Momentan ist der 328 schon ziemlich voll mit den Temperatur/Luftfeuchte/Luftdruck Modul. 86% Flash sind dicht.
Ich versuche das ganze Zeug auch noch ein wenig zu optimieren, aber unter 70% werden wir nicht kommen.
Ein Textdisplay würde dann auch Text Strings voraussetzen, die passen dann vermutlich nicht mehr in den Flash.
Man könnte sie aber in ein serielles EEprom packen.
Allerdings ist einen Thermostat zu basteln eine ganz andere Nummer als ein paar Sensorwerte zu übertragen.
In einem Thermostat müssen Regelfunktionen und solche Sachen, da wird kaufen vermutlich einfacher :-)
Das was Dirk hier in HW baut, wird nicht mehr als ein Sensorbaustein! Updatefunktionalität wäre relativ einfach,
allerdings dann nicht HM Kompatibel. Wenn es Kompatibel sein soll, dann ist es derzeit unmöglich, da das Protokoll,
die Verschlüsselung, etc noch nicht bekannt sind.
Bitte überfrachtet den Sensor nicht gleich mit Wunschfunktionen - Lasst uns schauen das wir Licht/Temp/Luft/Druck und
Bewegung hinbekommen...
Viele Grüße
Horst
Zitat von: Dirk am 28 Februar 2014, 00:02:57
von welcher Version?
Anbei übrigens das Layout für das Außengehäuse aus dem Beitrag:
http://forum.fhem.de/index.php/topic,20620.msg143214.html#msg143214
Dieses hat wie, schon geschrieben "nur" die Sensoren für Luftruck/Temperatur und Helligkeit an Bord.
Über ein den externen I2C-Bus kann man ggf. noch andere Sensoren anschließen. z.B. einen nach außen gelegten Temperatur/Feuchte Sensor.
In diesem Gehäuse wird man wohl keine sinvollen Temperatur/Feuchte-Werte bekommen.
Gruß
Dirk
Mir würden 7 Temperatur- und Feuchtesensoren und 1 Temp-/Feuchte-/Luftdrucksensor reichen.
Nochmal zum löten: Wie schwer ist es wirklich, mit dem richtigen Werkzeug die Platine mit Sensoren zu bestücken?
Den Arduino bekommst du bestimmt gelötet, der hat Rastermaß 2,54 mm, das geht relativ einfach, schafft sogar mein 12 jähriger Sohn.
Die Sensoren sind SMD, das ist etwas heftiger, setzt in meinem Alter eine Lupe und feines Lötzinn voraus.
Aber Dirk hat ja schon geschrieben, er überlegt ob er die Sensoren nicht direkt lötet und gegen "Bier" für den Rest eine Lösung findet :-)
Ich denke, am Löten wird es nicht scheitern...
Zitat von: hexenmeister am 28 Februar 2014, 12:47:07
Wie war das mit dem Fell des unerlegten Bären? ;)
Lasst doch Dirk erstmal bauen!
Hi,
ich hoffe, dass Dirk (und auch trilu, sorry wenn ich noch jemanden vergessen habe) das alles nicht als Drängelei oder so auffassen, sondern als Ausdruck dessen, dass die da was richtig Gutes bauen. Es scheint dafür doch einigen Bedarf zu geben.
Ich hoffe auch, dass sie sich dadurch nicht verrückt machen lassen, und einfach wie geplant weitermachen.
Gruß,
Thorsten
Hallo Zusammen,
Wow, da sind die Brötchen ja schon alle bevor sie im Ofen sind :)
Ich hoffe die Prototypen erfüllen die Erwartungen.
Ich habe eure Vorbestellungen aber schon mal notiert. Ich hoffe ich habe keinen vergessen:
Porky666 ca. 4
santalaus 8
hexenmeister 8
Alaska 8
martinp876 8
Pferdekaemper ca. 20
trilu ?
Prototypen vom Innensensor werde ich dann erstmal 5-10 Stück haben
Vom Aussensensor etwa 5
Ich habe mal ganz grob Kalkuliert. Ich schätze das man mit ca. 20-30€ für ein Modul rechnen kann.
Je nach bestückten Sensorchips und Bestückungsgrad.
Dabei währen dann aber Platine, Gehäuse, Batteriehalter usw. schon mit eingerechnet.
Zitat von: Thorsten Pferdekaemper am 28 Februar 2014, 09:28:43
Je nach Sensor muss man noch ein kleines Loch bohren und/oder einen kleinen Acrylstab reinstecken.
Wenn man im Innengehäuse den Lichtsensor mit installiert, muss dieser noch Licht abbekommen. Dafür hatte ich den Acrylstab geplant.
In der Hoffnung dass das auch so funktioniert. Das Außengehäuse hat einen transparenten Deckel. Da braucht man das nicht.
ZitatDann war da noch der Controller. Zuerst war der Plan, dass man den selbst draufstecken/löten muss, dann war im Gespräch, dass das Ding gleich mit draufgebacken wird.
Die Platine lässt beide Möglichkeiten zu. Mit aufgelötetem Controller hat man ggf. ein paar mehr Möglichkeiten, da dann freie Pins noch anderweitig benutzt werden können.
ZitatZu den Sensoren: Möglich scheint zu sein: Temperatur, Feuchte, Luftdruck, Helligkeit, Bewegung.
Der Bewegungssensor war im Gespräch ist im geplanten Layout aber noch nicht dabei. Das währ dann so ein Zusatzmodul was man auf die freien Steckleisten stecken kann.
ZitatSind die Dinger dann gleich mit drauf oder bestellt man die sich dann selbst? ...oder Sammelbestellung und dann selber löten.
Je nach dem. Da die Sensoren aus Platzgründen aber alle SMD sind, wird es auch bestückte bzw. teilbestückte Platinen geben.
ZitatBezüglich selber löten: Durch praktisch gesammelte Erfahrung weiß ich, dass meine Geschicklichkeit bei etwa 2,54mm Rastermaß endet. Wird das reichen?
Bei den Kleinteilen wie Widerständen und Kondensatoren sicherlich. Bei den Senoren und dem Atmega könnte es eng werden.
Zitat von: trilu am 28 Februar 2014, 09:35:34
Kannst du schon abschätzen wann du die ersten Prüfmuster haben wirst und was so eine Platine etwa kosten wird?
Wenn ich nächste Woche die ersten Platinen machen lasse, dann etwa 1-2 Wochen später.
Ich hoffe die SHT's kommen in der Zwischenzeit auch.
ZitatMacht es Sinn das ich mir schon mal ein paar Gehäuse bestellen?
Kannst du machen. Da ich vermutlich eh noch einige Sachen bestellen muss, kann ich das auch mit übernehmen. Spart etwas Versand
ZitatWas ich mir auch gerade überlegt habe, eigentlich könnte man den Bewegungsmelder mit in so ein Gehäuse packen, ist ja nur ein Loch
so dass der PIR Sensor rein passt...
Das kannst du machen. Bei der Version mit direkt aufgelötetem Atmega328 währen die Anschlussleisten und somit noch einige Ports frei
Zitat von: Porky666 am 28 Februar 2014, 10:08:09
da die Orderwut langsam ausbricht kann ich dir meine Unterstützung bei der, Kommissionierung, Verpackung und Versand anbieten. Habe hier im Haus einen Hermes Paketshop.
Ich will mich nicht aufdrängen, nur ein Vorschlag zu deiner Entlastung.
Klingt gut Das werde ich mir merken :)
Zitat von: frank am 28 Februar 2014, 11:53:13
wie sieht es eigentlich mit der "leistungsfähigkeit" des atmega328 aus?
Wie Trilu schon Sagte könnte das da eng werden.
Falls du mit deinem "Thermostat" aber nur eine Solltemperatur setzen möchtest, z.B. per Incrementalgeber, FHEM dann aber die Regelung vornimmt, könnte das noch rein passen.
Zitatdass irgendwann die möglichkeit des firmware updates per funk realisiert wird!
Ich würde fast sagen, dass man bei unseren Lösungen nicht unbedingt das Update per Funk einspielen muss.
Das kann man auch sehr einfach mit einem USB->Serial Adapter machen. So ist das auf den Platinen auch vorgesehen.
Und das sollte dann hoffentlich nicht so oft vorkommen müssen :)
Zitat von: Alaska am 28 Februar 2014, 13:44:18
Nochmal zum löten: Wie schwer ist es wirklich, mit dem richtigen Werkzeug die Platine mit Sensoren zu bestücken?
Kommt drauf an was schwer für dich bedeutet :)
Den Luftdruck Sensor wird man ohne Heißluft oder Reflow nur schwer bestücken können. Denn der hat die Anschlüsse unter dem Gehäuse.
Daher würde ich das übernehmen. Alles andere bekommt man aus meiner Sicht recht einfach gelötet. Du kannst des an einem Sensor ja vorher ausprobieren.
Zitat von: Thorsten Pferdekaemper am 28 Februar 2014, 13:55:27
ich hoffe, dass Dirk (und auch trilu, sorry wenn ich noch jemanden vergessen habe) das alles nicht als Drängelei oder so auffassen, sondern als Ausdruck dessen, dass die da was richtig Gutes bauen. Es scheint dafür doch einigen Bedarf zu geben.
Nö. :)
Gruß
Dirk
Hi Dirk,
das ist ja eine schöne Zusammenfassung ;D
Ich hätte schon Bedarf für 5 oder 6 Platinen, so genau weiss ich das aber noch nicht. Bauen wir den PIR mit rein, brauche ich mehr als ohne ...
Ich bräuchte aber für den Anfang mal einen oder zwei Prototypen, damit würde sich leichter entwickeln lassen. Deshalb die Bitte mir zumindest einen
der Prototypen zu reservieren.
Zum PIR Sensor habe ich mal ein bischen Datenblatt zum BISS0001 geschmökert, vielleicht brauche ich mehr als einen Pin um das Ding anzusteuern.
Es scheint möglich als könnte ich direkt an den Chip um die Empfindlichkeit unabhängig von einem Widerstandsnetzwerk zu steuern.
Viele Grüße
Horst
Hi Horst,
ZitatBauen wir den PIR mit rein, brauche ich mehr als ohne ...
Ich würde den PIR aktuell als Erweiterungsplatine sehen. Bei der Bestückungsversion ohne Arduino, also mit Atmega328 direkt bestückt kann man den PRI quasi als Arduino-Shield bauen und drauf stecken.
Der BISS0001 startet erst bei 3V Versorgungsspannung. Da sollte man bei 2-Zellen-Versorgung wohl noch einen StepUp-Regler davor bauen.
Der MAX1722 währ dafür da ganz interessant. Der braucht nur 1,5 µA im Leerlauf. Der BISS0001 genehmigt sich ja allein schon gut 50 µA bei 3V.
Aber selbst bei 100 µA Dauerbelastung sollte man eine Laufzeit bei angenommenen 1000 mAh Batteriekapazität von gut einem Jahr hinbekommen.
ZitatDeshalb die Bitte mir zumindest einen der Prototypen zu reservieren.
Du bist der erste der einen Prototypen bekommt :)
Gruß
Dirk
Ich habe mich noch ein wenig bei Ali umgesehen, um den BISS kommen wir wohl nicht drum rum, die einzige Alternative wäre, den Operationsverstärker, etc vom HM Schaltplan nachzubilden.
Das halte ich aber aus Gründen Aufwand und Kosten für übertrieben.
Der Besagte Max Spannungsregler würde vermutlich so oder so Sinn machen, dann können wir die zwei AA Batterien wirklich bis zum Rest auslutschen. Funkmodul und Arduino würden ja sonst bei 2.6 Volt schlapp machen. Mit dem Max können wir bis auf 1.x Volt runter...
Damit wäre der Mehrverbrauch mehr als kompensiert.
Viele Grüsse
Horst
2,6V bedeuten 1,3 Pro Zelle. Dabei ist die Batterie noch mehr als halbvoll. Daher würde ich einen StepUp-Wandler sehr begrüßen.
Alternativ könnte man 3,7V Lithiumakkus verwenden. Gibts sehr günstig in der Bucht ;)
Nachteil: frischegeladen liefern sie eine Zeit lang bis zu 4,2V. Da muss man möglicherweise den Funkchip irgendwie schützen. Die Schlussspannung liegt dann bei 2,75V.
Bei der Idee mit dem Acrylstab bin ich etwas skeptisch. Warum nicht den Lichtsensor (auf einer exra-Platine) einfach auf den Deckel kleben? Ein Kleines Loch dafür kann man auf der Rückseite mit einer Folie oder so zukleben. Oder eben ein Acryl-Fensterchen 'reinkleben'.
Mir gefällt die Idee mit dem Acrylstab. Das verfälscht sicherlich das Messergebnis, aber auf der anderen Seite reduzieren wir die Messung auf 1 Byte. Dafür ist der Sensor fest verlötet und wird keine Kontaktprobleme oder so haben.
Lithiumzelle halte ich im Aussenbereich für kritisch, die Akkus vertragen keine Kälte...
Viele Grüsse
Horst
Hi Horst,
ZitatFunkmodul und Arduino würden ja sonst bei 2.6 Volt schlapp machen. Mit dem Max können wir bis auf 1.x Volt runter...
Der CC1101 ist bis 1,8V spezifiziert, der BMP180 auch der TSL2561 geht "nur" bis 2,7V, der SHT10 bis 2,4V und der AVR@10Mhz ist auch bit 2,7V angegeben.
Ich bin grade am überlegen ob wir jetzt schon den MAX einsetzen müssen.
Kannst du die Lib auf 1Mhz Systemtakt umschreiben? Dann Ist der AVR bis 1,8V spezifiziert. Dann währ "nur" noch der Lichtsensor für ein frühzeitiges "Ableben" der Batterie verantwortlich.
Wenn ich mir die Typische Entladekurve einer Alkali-Mangan-Zelle bei 100 mA ansehe (http://commons.wikimedia.org/wiki/File:Aa-alkaline-100_c-v.png), dann sollte man aus dieser ca. 500 mAh entnehmen können, bis ca. 2,7V erreicht sind. Bei einer Entladung von wenige µA die wir anstreben sollten es noch mehr sein.
Ich habe dann mal noch etwas gerechnet.
Angenommen der Sensor sendet ca. alle 2,5 Min. die aktuellen Werte (Wie lange dauert ein HM-Packet mit Ack? eine Sekunde?) dann würde der Sensor etwas mehr als ein Jahr mit 500 mAh auskomen.
Mit dem MAX vermutlich doppelt so lange, da diese bei Verbrauchern im µA-Bereich nur noch ca. 50% Wirkungsgrad hat.
Jetzt die Frage an alle:
Sollte ich den MAX hier schon vorsehen? Das würde ca. 2-3€ Mehrpreis ausmachen?
Vorteil währ, dass andere Sensoren hier auch ggf. auch 3,3 V bekommen könnten
Zitat von: hexenmeister am 28 Februar 2014, 19:29:22
Bei der Idee mit dem Acrylstab bin ich etwas skeptisch. Warum nicht den Lichtsensor (auf einer exra-Platine) einfach auf den Deckel kleben? Ein Kleines Loch dafür kann man auf der Rückseite mit einer Folie oder so zukleben. Oder eben ein Acryl-Fensterchen 'reinkleben'.
Hinter dem Acrylstab wird der Sensor sicher deutlich weniger Licht abbekommen, das würde ich dann in der Software mit einem entsprechenden Abgleich machen. Für den Prototyp würde ich das Ganze aber erst mal so lassen wollen.
Sollte sich das dann als problematisch herausstellen werde ich die Idee mit der Zweitplatine aufgreifen.
Aktuell ist der Lichtsensor im Innengehäuse direkt in der Nähe der Luftschlitze geplant. Daher könnte ich mir vorstellen dass der Sensor dort bereits genügend Licht abbekommt um auf den aktuellen Helligkeitswert im Raum zu schließen.
Gruß
Dirk
Ich wäre für den Einbau von MAX von Anfang an. 2-3 Euro dürften kaum jemanden ernsthaft stören. Die Vorteile überwiegen IMHO deutlich. Man könnte auch mit nur einer Zelle arbeiten, spart Platz.
Sensoren auslesen, senden und ACK braucht max 300ms im Moment. Allerdings muss der Arduino alle 250ms kurz aufwachen um das Timing fürs senden zu halten. Kommt von der Kompatibilität zum Heizungsthermostat.
Er bleibt alle 250ms damit kleiner 1ms bei 5ma wach. Dann etwa alle 3 Minuten für 300 ms bei 25ma.
Könnte man den Max variabel machen, wieviel braucht der außen rum?
Eigentlich macht der Max ja nur Sinn bei PIR, da haben wir auch mit erhöhtem Stromverbrauch zu kämpfen.
Die Lib könnte man schon jetzt bei 1Mhz betreiben. Die meisste Zeit verbringt der Arduino in der Loop und checkt ob er was zu tun bekommt.
Viele Grüsse
Horst
ZitatKönnte man den Max variabel machen, wieviel braucht der außen rum?
Ja, wenn der nicht bestückt wird, muss man den nur überbrücken. Mit dem MAX wird die Messung der Batteriespannung etwas aufwändiger. Zwei zusätzliche Widerstände und zwei zusätzliche Pins am AVR.
ZitatEigentlich macht der Max ja nur Sinn bei PIR, da haben wir auch mit erhöhtem Stromverbrauch zu kämpfen.
Wenn man den Helligkeitssensor nutzen möchte bin ich mir da grade nicht mehr ganz sicher.
Wenn ich mir die Entladekurve der Batterien so ansehe, dann sind die 1,35V recht schnell erreicht.
ZitatDie Lib könnte man schon jetzt bei 1Mhz betreiben. Die meisste Zeit verbringt der Arduino in der Loop und checkt ob er was zu tun bekommt.
Dann würde ich das fast so machen. Dann ist der AVR noch etwas genügsamer und kann bis 1,8V sicher versorgt werden.
ZitatEigentlich macht der Max ja nur Sinn bei PIR,
Naja, PIR macht ihn zwingend notwendig, Sinn macht er auch ohne.
P.S. Für mich wäre PIR schon ganz wichtig.
Noch was: Wären 2 LEDs (rot/grün) nicht eher HomeMatic-like? (unwichtig)
Stimmt. Leds wären schön :-)
In der Lib ja Dank Dirk schon vorhanden...
Zitatwenn der [MAX] nicht bestückt wird, muss man den nur überbrücken.
wäre auch eine interessante Option für mich. Ich würde einige meiner 1wire-Sensoren dadurch ersetzen, da könnte ich doch gleich die 5V-Versorgung (mit einem LM1117 oder so) weiterverwenden. :)
Zitat von: hexenmeister am 28 Februar 2014, 20:43:04
Noch was: Wären 2 LEDs (rot/grün) nicht eher HomeMatic-like? (unwichtig)
Die Led hat außer zum Anzeigen des Config-Modes keine weitere Aufgabe.
Daher sollte eine hier reichen. Eine Bestätigung nach jedem Telegram mus man hier sicher nicht optisch anzeigen.
Wenn ich mir die anderen Sensoren von HM so ansehe, haben diese auch nur die eine LED.
Somit währ das dann trotzdem noch HomeMatic-Like :)
Zitat von: hexenmeister am 28 Februar 2014, 20:53:00
Ich würde einige meiner 1wire-Sensoren dadurch ersetzen
Du willst eine Kabelgenundene Lösung durch Funk ersetzen? Wieso das?
Naja ungerne, aber...
mit 1wire habe ich derzeit nur die Temperatur, alles andere wird dort recht schnell teuer.
Homematic habe ich je im Einsatz, daher wäre schön, die Anzahl der verschiedenen Techniken zu reduzieren. Meine ganzen 1wire Sensoren den FHEM schon merklich.
Ich werde aber nicht alles ersetzen, sonder nur paar Teile, wo die Kabellängen schon etwas 'anstrengend' sind ;)
Zuerst wollte ich einen Arduino als zwischen-Knoten einsetzen (und per RS485/Modbus ans Raspi anbinden), habe die Idee aber zunächst verworfen. Meine Tests an diesen Standorten (mir RFM12b) waren sehr gut. Daher... warum nicht?
So, Ich habe die Layouts geändert:
Optional ist der MAX1724 mit an Bord. Diese Liefert dann 3,3V für die gesamte Schaltung.
Somit Können dann auch Sensoren angeschlossen werden welche erst ab 3 V funktionieren.
Mit dem Jumper J1 kann der MAX überbrückt werden, so dass er nicht bestückt werden muss.
Im Layout habe ich J1 mit einer Leiterbahn standardmäßig überbrückt. Bei der Bestückungsversion mit MAX1724 muss diese Brücke also getrennt werden.
Weil die komplette Schaltung über den MAX versorgt wird, funktioniert die Batteriespannungsmessung mit der Internen Bandgapreferenz im AVR nicht mehr, da diese immer 3,3 V messen würde. Daher sind Zusätzlich noch R5 und R6 dazu gekommen. Über diesen Spannungstreiler kann dann die anliegende Batteriespannung gemmesen werden. Während der Messung wird ADC2 auf Low geschaltet und der ADC an ADC1 aktiviert. Die restliche Zeit würde ich diese Pins floaten lassen oder auf High setzen, dann wird durch den Spannungsteiler keine Energie verbraucht.
Zusätzlich habe ich einen kleineren Config-Taster eingeplant. Dadurch kann im "Sensor P/L" das CC11101-Modul auch auf der Top-Seite bestückt werden.
@Trilu:
Kannst du mal schauen ob die Beschaltung der Ports für die Lib für dich so ok sind (Taster, LED, Spannungsteiler CC1101 usw.)
Gruß
Dirk
Update:
Angang gelöscht. Aktuelle Version ist hier:
http://forum.fhem.de/index.php/topic,20620.msg144693.html#msg144693
Zitat von: Dirk am 01 März 2014, 09:52:01
So, Ich habe die Layouts geändert:
Gruß
Dirk
Hallo,
da man den Luftdruck auch per gds abfragen kann:
_dataSource Quelle: Deutscher Wetterdienst
2014-03-01 12:03:17 c_pressure-nn 1003.3
2014-03-01 12:03:16 c_stationName Frankfurt/M-Flh.
Und falls man in einer größeren Entfernung zur Messtation
lokalisiert ist, kann man ja auch zwischen zwei (oder mehr)
Messstationen interpolieren.
Meine Empfehlung:
Man sollte den Platinenplatz für andere Sensoren verwenden
und den Drucksensor nur optional vorsehen.
Gruss,
Joachim
Hi Dirk,
sieht gut aus. Du hast die Pins vom SHT mit auf den I2C Bus gepackt, das hatte ich in meinem Prototyp nicht,
sollte aber theoretisch gehen.
Funkmodul passt auch - ist frei gegeben :-)
Viele Grüße
Horst
@Joachim
Very helpful - Wir könnten auch die Sensoren von LaCrosse verwenden, dann bräuchten wir gar nicht basteln...
Wetterdienst ist unsportlich 8)
Aber natürlich kann man alle Daten auch in den Nachrichten hören ;D
Zitat von: trilu am 01 März 2014, 13:18:41
@Joachim
Very helpful - Wir könnten auch die Sensoren von LaCrosse verwenden, dann bräuchten wir gar nicht basteln...
Zunächst mal: ich beobachte eure Arbeit mit sehr grossem Interesse.
Sehe ich das richtig, dass Lacrosse nicht bidirektional ist.
In diesem Fall kommt das für mich - aus Zuverlässigkeitsgründen - nicht in Frage.
Gruss,
Joachim
Zitat von: jjf am 01 März 2014, 12:30:10
Man sollte den Platinenplatz für andere Sensoren verwenden
und den Drucksensor nur optional vorsehen.
Der alle Sensoren können optional bestücht werden. Was für Sensoren schweben dir noch vor?
Gruß
Dirk
die lacrosse sensoren sind nicht bidirektional.
allerdings kann man darüber streiten ob ein temperatur und fechte sensor der alle paar sekunden sendet wirklich zuverlässiger wird wenn das ganze bidirektional ist oder nur unnötig der funk raum mit acks gefüllt wird.
bei einem bewegungsmelder ist das natürlich anders.
gruss
andre
Zitat von: Dirk am 01 März 2014, 14:10:47
Der alle Sensoren können optional bestücht werden. Was für Sensoren schweben dir noch vor?
Gruß
Dirk
Der Platienenplatz für den Drucksensor ist wirklich klein.
Also ziehe ich meine Bemerkung angesichts des Platzes
für die Batterien zurück.
Wir in Hessen haben bald (oder schon) Rauchmelderpflicht.
Luftgüte, Wasseralarm fällt mir spontan ein.
Joachim
Zitat von: justme1968 am 01 März 2014, 14:11:33
allerdings kann man darüber streiten ob ein temperatur und fechte sensor der alle paar sekunden sendet wirklich zuverlässiger wird wenn das ganze bidirektional ist oder nur unnötig der funk raum mit acks gefüllt wird.
gruss
andre
Meine Erfahrung: drahtgebundene Sensoren sind sehr zuverlässig.
Deshalb gefällt mir ja die Platine gut:
Rx und Tx sind noch frei: -> RS485 oder 1W wäre möglich,
falls man die Verkabelung realisieren kann.
Gruss,
Joachim
wenn kabel liegen würde ich nichts anderes verwenden.
wobei mich bei 1wire das pollen stört und ich das nicht mehr über das haupt fhem system mache würde wenn die anzahl der sensoren zweistellig wird.
Zitat von: justme1968 am 01 März 2014, 14:56:50
wenn kabel liegen würde ich nichts anderes verwenden.
wobei mich bei 1wire das pollen stört und ich das nicht mehr über das haupt fhem system mache würde wenn die anzahl der sensoren zweistellig wird.
Ich habe 15 Temperatursensoren DS18B20 am Avr-Net-IO. Mehr sind geplant.
Zur Info: hier die aktuelle Messungen von heute.
https://dl.dropboxusercontent.com/u/18713924/SVG_BoilerTemperatur.svg
https://dl.dropboxusercontent.com/u/18713924/SVG_BoilerAnschluesseTemperatur.svg
Als Perl-Übung habe ich gerade die im Warmwasserspeicher befindliche Wärmemenge
berechnet und in eine dummy-Variable geschrieben.
An die fleissigen: weitermachen, das Interface kann man später auch noch anders gestalten.
Joachim
TME hat mich mit der Schnelligkeit überrascht. Gestern bestellt, heute hat Post die Gehäusen gebracht. Sind IMHO echt brauchbar :)
Zum Thema MAX1724:
Guter Preis bei eBay:
http://www.ebay.de/itm/5PCS-MAX1724EZK33-Maxim-IC-REG-BOOST-SYNC-3-3V-TSOT23-5-NEW-GOOD-QUALITY-R3-/300980076349?pt=LH_DefaultDomain_0&hash=item4613cf7f3d
Oder, wenn man eine größere Sammelbestellung zusammenbringt:
http://www.ebay.de/itm/50PCS-MAX1724EZK33-Maxim-IC-REG-BOOST-SYNC-3-3V-TSOT23-5-NEW-GOOD-QUALITY-R3-/300980075344?pt=LH_DefaultDomain_0&hash=item4613cf7b50
Kennt jemand noch bessere Quelle?
(Bei Ali habe ich auch schon geguckt, keinen besseren Preis gefunden.)
Zitat von: trilu am 01 März 2014, 13:18:41
Du hast die Pins vom SHT mit auf den I2C Bus gepackt, das hatte ich in meinem Prototyp nicht,
sollte aber theoretisch gehen.
Wie hattest du den SHT10 aktuell angeschlossen?
Zitat von: jjf am 01 März 2014, 14:36:10
Wir in Hessen haben bald (oder schon) Rauchmelderpflicht.
Luftgüte, Wasseralarm fällt mir spontan ein.
Luftgüte finde ich auch interessant.
Hast du hier einen bestimten Sensor im Sinn?
Über die Steckleisten kann man die geplante Platine recht gut erweitern. Da sollte auch ein Wassersensor machbar sein.
Zitat von: jjf am 01 März 2014, 14:40:15
Rx und Tx sind noch frei: -> RS485 oder 1W wäre möglich,
falls man die Verkabelung realisieren kann.
Da ich mich parallel noch mit HM-Wired (RS485) beschäftige hatte ich hier auch eine RS485-Version vorgesehen.
Der Vorteil zu 1Wire, HM-Wired muss man nicht pollen.
Gruß
Dirk
Zitat von: hexenmeister am 01 März 2014, 20:47:18
Zum Thema MAX1724:
Kennt jemand noch bessere Quelle?
Nein. Eine Alternative wäre TPS61097.
Aber auch nicht preiswerter.
Joachim
@Dirk
laut Datenblatt ist der SHT10 kein wirkliches I2C Device. Das Protokoll ist ähnlich, aber das Ding hat keine Adresse.
Ich wollte möglichst Fehler ausschliessen und bin ja auch etwas faul, deshalb hatte ich ihn an Pin A0 (data) und Pin A1 (clock)
angeschlossen...
Falls du weiterhin freie Pins hast, wäre das die bevorzugte Alternative. Ansonsten bin ich mir aber fast sicher, das wir
den Sensor auch über A4 und A5 ans laufen bekommen.
Viele Grüße
Horst
Zitat von: trilu am 01 März 2014, 21:25:30
laut Datenblatt ist der SHT10 kein wirkliches I2C Device. Das Protokoll ist ähnlich, aber das Ding hat keine Adresse.
Achso, ja das hatte ich fast vergessen, weil ich mich hierauf verlassen hatte:
Zitat"however, the sensor can be connected to an I2C bus without interference with other devices connected to the bus. The controller must switch between the protocols."
ZitatFalls du weiterhin freie Pins hast, wäre das die bevorzugte Alternative.
Ok, dann schaue ich mal ob ich da was machen kann. Die Ports sind kein Problem. Langsam wird es aber voll auf der Platine :)
Genau das war der Satz den ich auch gelesen hatte. Wir könnens ja testen ;D
danke für die einschätzungen.
ZitatMomentan ist der 328 schon ziemlich voll mit den Temperatur/Luftfeuchte/Luftdruck Modul. 86% Flash sind dicht.
Ich versuche das ganze Zeug auch noch ein wenig zu optimieren, aber unter 70% werden wir nicht kommen.
ZitatAllerdings ist einen Thermostat zu basteln eine ganz andere Nummer als ein paar Sensorwerte zu übertragen.
In einem Thermostat müssen Regelfunktionen und solche Sachen, da wird kaufen vermutlich einfacher :-)
ZitatFalls du mit deinem "Thermostat" aber nur eine Solltemperatur setzen möchtest, z.B. per Incrementalgeber, FHEM dann aber die Regelung vornimmt, könnte das noch rein passen.
da ich die regler in den "echten" thermostaten nicht verwenden kann, um mein heizungssystem umzusetzen, benötige ich eigentlich nur einen sollwertgeber und eine temperaturmessstelle. der regler wird in fhem durch pid20 realisiert, der dann über ein virtuelles hm-cc-tc das ventil hm-cc-vd steuert. ausserdem sind meine hm-cc-tc thermostate nicht einmal in der lage "nur" den sollwert verlässlich bereit zu stellen.
aus euren antworten entnehme ich: wenn ich ein reduziertes sensormodul (firmware -> T/H) verwenden würde, sollte ich auf alle fälle den sollwertgeber und eventuell noch ein display integrieren können. dann werde ich mich demnächst wohl mal mit der asksin library beschäftigen und versuchen ein io-modul zu integrieren. eventuell dieses: http://www.aliexpress.com/item/Free-Shipping-1602-LCD-Keypad-Shield-Duemilanove-UNO-MEGA2560-MEGA1280-in-stock/701995021.html (http://www.aliexpress.com/item/Free-Shipping-1602-LCD-Keypad-Shield-Duemilanove-UNO-MEGA2560-MEGA1280-in-stock/701995021.html)
daher sieht meine wunschvorbestellung wie folgt aus (oder vergleichbare ausführungen):
1x indoor-komplett (gehäuse,batteriehalter,platine,atmega,max,T/H,druck,licht)
5x indoor-T/H (gehäuse,batteriehalter,platine,atmega,max,T/H)
gruss frank
Hi Horst,
Ich hab mir das noch mal angesehen.
Ich könnte dem SHT10 für den Sensor1 eigene Pins spendieren.
Beim zweiten Layout habe ich aber nur den I2C-Bus zusätzlich nach außen geführt. Da sollte ein optional angeschlossener SHT10 über die I2C-Pins laufen. Daher, lass uns den SHT10 am I2C-Bus lassen. Dann kann man die Sensoren alle einheitlich verbauen.
Die Änderungen an deiner Lib sollten doch nicht so umfangreich ausfallen?
Kannst du deinen Prototypen dahin entsprechend umbauen und testen ob das so einfach funktioniert bevor ich die Platinen in Auftrag gebe?
Gruß
Dirk
@Dirk
Ich habe mir das Schema bezüglich Spannungsmessung mit MAX1724 angesehen. Mit den angegebenen Widerständen beträgt die Stromstärke maximal 1,5V/570k=2,63µA=0,00263mA. Wenn die Batterie ca. 1000mAh hat, dann reicht sie bei diesem Verbrauch für ca. 380000 Stunden. Das sind zwar nur etwa 43 Jahre ;) Aber lohnt es sich dabei überhaupt einen Pin zum Abschalten dieser Schaltung zu spendieren? Wenn ja, warum dann nicht auch einige Sensoren zwischendurch abzutrennen?
Oder habe ich mir verrechnet?
Hi hexenmeister,
Deine Rechnung stimmt so etwa. Ich hab mit 3,3V gerechnet und komme da auf ~5,8µA.
In Zusammenhang mit dem MAX ist das recht wenig, da die Batterie ziemlich gut ausgenutzt wird.
Ein Paar µA für die Sensoren, AVR, CC1101 kommen auch noch dazu. Und periodisch aufwachen muss der AVR auch noch. Somit bekommen wir hier bestimmt keine 44 Jahre hin. Über 2-4 Jahre sollten das aber dennoch werden.
Für die Version ohne MAX sieht es etwas anders aus, da der Lichtsensor Laut Datenblatt min. 2,7 V möchte.
Bei der Reihenschaltung von 2 Zellen a 1,5V liegt die Spannung hier schon recht früh unter den 2,7V. Laut Entladekurve, die ich ein paar Beiträge weiter vorne gepostet hatte, kann man den AA-Zellen bis dahin ca. 500 mAh entnehmen. Knapp 1/5tel der Nennkapazität.
Daher wollte ich so viel es geht an Energie sparen. Aber auch hier sollte man eine Betriebszeit von 1-2 Jahren erreichen können.
Zitatwarum dann nicht auch einige Sensoren zwischendurch abzutrennen?
Den Helligkeitssensor könnte man abklemmen, dann muss man diesen aber auch pollen. Ansonsten kann der, entsprechend mit Schwellwerten programmiert, eigenständig Events an den AVR senden.
Hier mal eine Liste der Standbyverbräuche bei 3,3V
SHT10: ca. 0,6 µA.
TLS2561: ca. 3,2 µA
BMP180: ca. 0,1 µA
CC1101: ca. 0,5 µA
Atmega32: ca 0,1 µA
In Summe sind das nur etwa 4,5 µA für alles zusammen.
Mit dem abgeschalteten Spannungsteiler sparen wir also über 50% Energie in der Standby-Zeit.
Ich wollte den Pin für das Enablen des Spannungsteilers aber noch verlegen.
Eine andere Idee währ noch, dass sich Spannungsteiler und Config-Taster einen Pin teilen.
Während der Spannungsmessung muss der Pin für ein paar ms auf Output-Low konfiguriert werden. Ansonsten ist er auf Input-High konfiguriert.
Was haltet ihr davon? Spart einen Pin und trotzdem Energie.
Gruß
Dirk
Moin !
Zitat von: Dirk am 01 März 2014, 21:08:55
Da ich mich parallel noch mit HM-Wired (RS485) beschäftige hatte ich hier auch eine RS485-Version vorgesehen.
Der Vorteil zu 1Wire, HM-Wired muss man nicht pollen.
Na dann freue ich mich jetzt schon auf RS485 Version :)
Gruß, Marc
ZitatEin Paar µA für die Sensoren, AVR, CC1101 kommen auch noch dazu. Und periodisch aufwachen muss der AVR auch noch. Somit bekommen wir hier bestimmt keine 44 Jahre hin
Das ist mir schon klar. Auch dass die Batterien Selbstentladung haben. ;)
Sollte ja eine Vergleichrechnung sein.
ZitatSpart einen Pin und trotzdem Energie.
Klingt nach einer guten Wiederverwertung, ganz im Sinne der Nachhaltigkeit ;)
Einen Nachteil sehe ich auch nicht.
Grüße,
Alexander
Jetzt weiss ich wieder was das Problem an Heißkleber auf Platinen war :-)
Also, habe gerade den SHT10 auf den I2C Bus gepackt - A4 data, A5, sck.
Es geht teilweise...
Die Arduino Wire library kennt nur ein Wire.begin(), von da an ist Schluss mit der Temperatur und Feuchte.
Ein Wire.end() kennt die Library nicht. Wenn man aber den I2C Bus manuell wieder ausschaltet, dann geht der
SHT10 auch wieder.
Ist aber derzeit ein gefrickel!
Vielleicht sollten wir ganz weg von HW I2C und Bitbang machen?
Zitat von: Dirk am 01 März 2014, 21:08:55
Da ich mich parallel noch mit HM-Wired (RS485) beschäftige hatte ich hier auch eine RS485-Version vorgesehen.
Gruß
Dirk
Zu RS485 habe ich Fragen:
1. HM-Protokoll:
Ich habe "HS485_Protokoll.pdf" und "HMW RS 485 Protokollbeschreibung_87.pdf" gefunden.
Gibt es noch weitere Infos?
2. Das Protokoll ist Multi-Master fähig.
Gibt es Einschränkungen vom Protokoll 2 FHEM-Rechner auf einen RS485-Bus zugreifen
zu lassen (kein fhem2fhem).
3. Gibt es intellektuelle Rechtsansprüche, die einem das Leben
schwer machen können?
Zu RS485 habe ich auch eine Meinung.
Gesamtkosten sind minimal, weil das Produkt aus:
Zuverlässigkeit * Leistungsverbrauch * Preis pro Knoten
optimal ist.
Gruss,
Joachim
Zitat von: trilu am 02 März 2014, 16:07:25
Jetzt weiss ich wieder was das Problem an Heißkleber auf Platinen war :-)
Der gute alte Heißkleber :)
ZitatDie Arduino Wire library kennt nur ein Wire.begin(), von da an ist Schluss mit der Temperatur und Feuchte.
Schau mal in twi.h twi_stop() oder twi_releaseBus() könnten das übernehmen.
Zitat
Vielleicht sollten wir ganz weg von HW I2C und Bitbang machen?
Das währ auch noch ein Weg.
Was hältst du davon den Pin für den Config-Taster und für Enable des Spanungsteilers gemeinsam zu verwenden?
Dann würde ich das noch entsprechend umstricken.
Zitat von: jjf am 02 März 2014, 17:24:43
Ich habe "HS485_Protokoll.pdf" und "HMW RS 485 Protokollbeschreibung_87.pdf" gefunden.
Gibt es noch weitere Infos?
Das sind alles Infos die ich derzeit dazu zusammentragen konnte. Ansonsten noch die XML-Files aus der CCU-Firmware. Daraus kann man den Aufbau werden der Datenframes ableiten.
ZitatGibt es Einschränkungen vom Protokoll 2 FHEM-Rechner auf einen RS485-Bus zugreifen
zu lassen (kein fhem2fhem).
Ich habe hier aktuell eine CCU und FHEM am Bus. Das funktioniert, ist aber so nicht vorgesehen.
Probleme gibt es ggf. wenn beide Zentralen Nachrichten quotieren wollen. Da müsste man sich noch was einfallen lassen.
Zitat3. Gibt es intellektuelle Rechtsansprüche, die einem das Leben
schwer machen können?
Zumindest das Vorgängerprotokoll HS485 war veröffentlicht. HM-Wired ist nur eine Erweiterung dessen.
Mir fällt grade nicht ein wo man da ansetzen könnte.
Gruß
Dirk
ZitatWas hältst du davon den Pin für den Config-Taster und für Enable des Spanungsteilers gemeinsam zu verwenden?
Dann würde ich das noch entsprechend umstricken.
Um ehrlich zu sein, nicht ganz so viel :-)
Der Config Taster basiert ja auf einem Pin Interrupt. Ich weiss nicht, wie sich der verhält wenn der Pin anderweitig verwendet wird.
Den Interrupt brauchen wir aber um das Device beim Tastendruck aus dem Schlaf zu holen...
Die twi.h lässt sich nicht so einfach einbinden, das sie in dem utility Ordner zur Wire.h ist.
Bohhh, diese Arduino Hürden :-)
Viele Grüße
Horst
ZitatDer Config Taster basiert ja auf einem Pin Interrupt. Ich weiss nicht, wie sich der verhält wenn der Pin anderweitig verwendet wird.
Klar, der muss auch an bleiben.
Für das Auslesen vom ADC muss man den Interuppt kurz deaktivieren, dannach wieder aktivieren. Im Prinzip ganz einfach :)
Aber das müssen wir ja nicht machen. Währ schön weil man noch ein Pin frei hat.
ZitatDie twi.h lässt sich nicht so einfach einbinden, das sie in dem utility Ordner zur Wire.h ist.
Wire.h benutzt twi.h Daher sollte das eigentlich funktionieren.
Ansonsten die I2C-Register "zu Fuß" ein- und abschalten?
Hej,
nachdem der Thread-Titel nicht ganz sooo selbsterklärend ist, hab ich mich erst heute dazu entschlossen, einen Blick zu riskieren und mit jeder Seite stieg die Begeisterung. :-)
Mit den Dingern könnte ich endlich meine S300TH in Rente schicken und somit FS20 bei mir endgültig "abschalten". :-)
Daher würde ich bei den interessierten Personen für solche Teile auf alle Fälle auch mit aufzeigen.
Was genau würde mich interessieren?
1x Außen: Da genügt wohl T/H/B
Innen wird es schon interessanter: auf alle Fälle auch T/H. Über den Nutzen der Helligkeit (B) für jeden Raum bin ich mir noch nicht so ganz im klaren (würde mich interessieren, was ihr mit einer solchen "Funktion" anstellen würdet). Aber Luftgüte und ggf. auch ein Wassermelder wären im Falle der Verfügbarkeit sehr hilfreich. Also für innen wären dann 6 Stück interessant.
Letztendlich würde mich natürlich noch interessieren, ob sich die Module als externe Temp-Sensoren für die RTs nutzen lassen... das wäre gewissermaßen das Sahnehäubchen. :-)
Great Job... Immer weiter so! 8)
ZitatÜber den Nutzen der Helligkeit (B) für jeden Raum bin ich mir noch nicht so ganz im klaren (würde mich interessieren, was ihr mit einer solchen "Funktion" anstellen würdet).
Na zum Bleistift:
Rolladen werden nach dem Wert der Helligkeit draußen heruntergefahren. Wenn drinne Licht angemacht wird, dann weden die Rolladen etwas früher heruntergefahren (ggf. noch abhängig von dem Bewegungsmelder draußen ;))
LG
Alexander
Zitat von: Dirk am 02 März 2014, 17:41:37
Zumindest das Vorgängerprotokoll HS485 war veröffentlicht. HM-Wired ist nur eine Erweiterung dessen.
Mir fällt grade nicht ein wo man da ansetzen könnte.
Gruß
Dirk
Zitat von http://www.elv.de/output/controller.aspx?cid=307:
"Das wesentliche Know-how der Eigenentwicklungen ist durch Patente, Geschmacks- und Gebrauchsmuster geschützt."
Hat die schon jemand gelesen?
Gruss,
Joachim
Zitat von: hexenmeister am 02 März 2014, 18:50:57Rolladen werden nach dem Wert der Helligkeit draußen heruntergefahren. Wenn drinne Licht angemacht wird, dann weden die Rolladen etwas früher heruntergefahren (ggf. noch abhängig von dem Bewegungsmelder draußen ;))
Das ist schon mal ein guter Anfang. Hatte ich vorhin nicht bedacht (habe bislang aber auch noch keine Rollläden). :)
Meine Phantasie endete vorhin bei: Einschalten des Lichts, wenn ein gewisser Dämmerungswert erreicht wurde und man nach Hause kommt bzw. (und das ist schon wieder heikel wegen des WAFs) der Bewegungsmelder kombiniert mit der gemessenen Helligkeit des Raumes das Hauptlicht einschaltet.
Das mit den Patenten und dem Gebrauchsmusterschutz hatte ich mir auch schon mal angeschaut.
Ein Patent auf das Protokoll an sich werden sie hier in D nicht bekommen haben, sowas vergeben eigentlich nur Amerikaner.
Der Geschmacks- und Gebrauchsmusterschutz dürfte nur die Marke betreffen, also HomeMatic und oder BidCos.
Derzeit sehe ich das gelassen, es ist ja nichts durch illegale Handlungen entstanden, ich habe weder ein Device ausgelesen
noch irgendwelche, unter NDA stehende Datenblätter gelesen.
Die Lib ist rein auf Beobachtung von existierenden Devices entstanden!
Hi Trilu,
Wegen dem fehlenden Wire.end() hab ich grade noch mal etwas gesucht.
Probier wirklich mal:
TWCR = 0;
Quelle: http://forum.arduino.cc/index.php/topic,21424.0.html
Gruß
Dirk
"Ein Gehäuse aus dem 3D-Drucker" kann jeder designen. Wenn wir Schulklassen darin unterrichten, lassen wir die Kids mit Sketchup arbeiten.
Allerdings stimme ich zu: Die Qualität ist bei den billigen Geräten nicht so, dass ich mir das ins Wohnzimmer stellen wollte.
LG
pah
Zitat von: trilu am 02 März 2014, 19:13:47
Das mit den Patenten und dem Gebrauchsmusterschutz hatte ich mir auch schon mal angeschaut.
Ein Patent auf das Protokoll an sich werden sie hier in D nicht bekommen haben, sowas vergeben eigentlich nur Amerikaner.
Ich schliesse mal von mir auf andere:
Ein Rechtsstreit gegen eine Firma mit 1000 Mitarbeitern stehe ich/du/wir nicht durch,
auch dann nicht, wenn das Patent etc offensichtlich zu unrecht erteilt worden ist.
Den Zeit, die man dazu aufwenden muss, steht in keiner Relation zum Effekt:
meine Einschätzung: für 1% der Zeit hat man ein eigenes Protokoll entwickelt.
Im Bereich RS485 gibt es einen Sack von Protokollen, aus dem man sich was aussuchen kann
(auch ich habe da was exotisches verbrochen: Elrad 1997-08 Seite 45, Linux-Treiber für 16550 verfügbar).
Meine Empfehlung: man sollte ein weit verbreitetes Protokoll auswählen. Da wird sich was finden.
Gruss,
Joachim
Klar, Protokolle gibt es genug. Anfangs hatte ich mit der Jeelib gespielt, aber und das war für mich entscheidend;
Ich möchte Geräte bauen die sich in eine bestehende Landschaft integrieren lassen. Was nützt mi ein schöner Aktor,
wenn es keinen passenden Wandschalter gibt...
Ausserdem glaube ich nicht, das eq3 daran interessiert ist, mich zu verklagen. Das Protokoll ist bekannt und von Anderen
Bereits in den Umlauf gebracht. Siehe FHEM, den CUL von busware, usw...
@Dirk
Probier wirklich mal:
TWCR = 0;
Quelle: http://forum.arduino.cc/index.php/topic,21424.0.html
funzt!
Zitat von: trilu am 02 März 2014, 20:31:25
Klar, Protokolle gibt es genug. Anfangs hatte ich mit der Jeelib gespielt, aber und das war für mich entscheidend;
Ich möchte Geräte bauen die sich in eine bestehende Landschaft integrieren lassen. Was nützt mi ein schöner Aktor,
wenn es keinen passenden Wandschalter gibt...
Ausserdem glaube ich nicht, das eq3 daran interessiert ist, mich zu verklagen. Das Protokoll ist bekannt und von Anderen
Bereits in den Umlauf gebracht. Siehe FHEM, den CUL von busware, usw...
Eine kurze Suche ergibt:
Verfahren zur sicherung der kommunikation zwischen einem heimautomatisierungsserver und einem zentralen konfigurationsserver
EP 2517137 A1
Fernsteuerbarer schalter WO 2011085840 A1
Verfahren und vorrichtung zur steuerung eines heimautomatisierungssystems EP 2529511 A1
Steuerung eines heimautomatisierungssystems EP 2529510 A1
Method for specifying transmitting times for cyclically sending out data messages, and subscriber device therefor US 20090067390 A1
Übertragungsverfahren DE 102012100331 A1
Interessant ist, das RWE und eQ-3 gemeinsam anmelden.
Homematic ist auch eine Marke!
Joachim
eq3 entwickelt und verkauft unter unterschiedlichen Markennamen.
FS20, Homematic, RWE, Max, etc...
Kennst du dich mit Patentrecht aus?
Zitat von: trilu am 03 März 2014, 10:24:20
Kennst du dich mit Patentrecht aus?
Nein!
Joachim
PS
Anmerkung: wenn etwas veröffentlicht worden ist, heisst das nicht,
dass es nicht durch Patentrecht, Gebrauchsmuster oder Markenrecht etc.
geschützt ist.
Zu HS485.pdf:
1. "... von ELV aus ausschließlich an lizenzierte Software-Entwickler."
Meine (vollkommen unmassgebliche) Schlussfolgerung: Für Funk braucht
man eine Lizenz. Weswegen genau ist mir unklar.
2. betrifft RS485: "Wir konzentrieren uns auf die Entwicklung, Fertigung und Erweiterung der System-Hardware..."
->
Sie machen die kleinen Kästchen
"Um die Entwicklung einer eigenen Software ..."
-> Gegen FHEM haben sie nichts einzuwenden.
3. Adressierung 32Bit
Da es für RS485 (meines Wissens) keine Bausteine gibt, die mehr als 256 Knoten
an einem Bus unterstützen, ist das auffallend. Warum schickt man 8 Bytes über den
Bus (4=Ziel 4=Quelle), wenn man mit 2 auskommt? Weil dann jeder Knoten
eine eindeutige Adresse haben kann. Das könnte geschützt sein, sowie das Verfahren
zum Ermitteln der vorhandenen Knoten (discovery).
Persönliche Schlussfolgerung:
Solange das nicht klar ist, investiere ich keine Arbeitzeit.
Zitat von: trilu am 03 März 2014, 07:39:34
funzt!
Super. Dann lass ich das so.
Eine kleine Änderung im Schaltplan/Layout gibt es noch:
Das Enable des Spannungszeilers geht jetzt an D7. Dadurch ist noch ein zusätzlicher ADC-Port frei.
Ich habe die geänderten Schaltpläne und Layouts nochmal angehängt.
Falls es keine weiteren Einwände gibt, würde ich das heute Abend bzw. morgen Vormittag an den Fertiger schicken.
https://github.com/kc-GitHub/Wettersensor/raw/master/Schematic/Universalsensor-CC1101-Schematic.pdf
Gruß
Dirk
ZitatFalls es keine weiteren Einwände gibt, würde ich das heute Abend bzw. morgen Vormittag an den Fertiger schicken.
Ist das Absicht oder hast du den Anschluss für meine Kaffeemaschine vergessen?
Sieht prima aus!!!
Hallo,
ich habe mir zwei Panstamps gekauft. Ich bin absoluter Anfänger in der Materie. Aus dem Git-Hub habe ich mir die Daten der AskSin Lib gezogen. Leider kann ich nicht alle Sketches kompilieren - es kommen immer wieder Fehler. Auch fehlen mir für die Anwendungen Unterlagen was auf welchem Pin liegt. Welcher ist der Pin für das Anlernen und muss der auf Masse oder Plus - mit Vorwiderstand oder ohne.
Ich finde das Klasse, was Ihr da in mühevoller Kleinarbeit über Try-and-Error von den Geräten lernt.
Ich möchte mit den Panstamps eigentlich S0 Impulse Zählen. Da ich ein Battery-Board mit DHT22 habe, soll auch die Temperatur mit übertragen werdnen. Für mich ist das Homematik Protokoll interessant, weil ich dann einen Empfänger weniger brauche.
Gibt es zu diesem Projekt irgendwelche Dokumentation ?
Gruß Christoph
Hallo Christoph,
ZitatAuch fehlen mir für die Anwendungen Unterlagen was auf welchem Pin liegt. Welcher ist der Pin für das Anlernen und muss der auf Masse oder Plus - mit Vorwiderstand oder ohne.
Das kann man am Schaltplan gut erkennen. Die Anschlüsse am Panstamp sind vermutlich aber anders. Du müsstest dir wohl beide Schaltpläne nebeneinander legen und vergleichen.
Gruß
Dirk
Hallo Dirk,
wen ich das richtig lese, wird für die Config D8 auf Masse gezogen. Bei dem Batteriy Board hängt der DHT22 auf A1 und A2. Auf den CC1101 hat man keinen Einfluß, aber da Die Pins die in der Zeichnung zum CC1101 gehen am Panstamp nicht vorhanden sind. Gehe ich davon aus, das der gleich angeschlossen ist.
Mein Problem ist, dass der Sketch beim kompilieren Fehler zeigt, mit denen ich nichts anfangen kann.
Gruß Christoph
Zitatwen ich das richtig lese, wird für die Config D8 auf Masse gezogen.
Das ist in diesem Fall korrekt. Allerdings kannst du die Zuordnung der Pins im Sketch selber festlegen. Das ist somit dir überlassen. Du kannst also Die LED an D4 vom Batteryboard auch als Config-LED konfigurieren.
ZitatAuf den CC1101 hat man keinen Einfluß, aber da Die Pins die in der Zeichnung zum CC1101 gehen am Panstamp nicht vorhanden sind. Gehe ich davon aus, das der gleich angeschlossen ist.
Das sieht so aus. GDO0 geht auch beim Panstamp laut Schaltplan auf D2.
ZitatMein Problem ist, dass der Sketch beim kompilieren Fehler zeigt, mit denen ich nichts anfangen kann.
Was denn für Fehler? Du müsstest die hier schon posten, sonst kann dir vermutlich niemand helfen.
Gruß
Dirk
Hallo,
er stoppt in diesem Bereich
//- homematic communication -----------------------------------------------------------------------------------------------
HM::s_jumptable jTbl[] = { // jump table for HM communication
// byte3, byte10, byte11, function to call // 0xff means - any byte
// { 0x01, 0xff, 0x0e, HM_Status_Request },
{ 0x11, 0x04, 0x00, HM_Reset_Cmd },
// { 0x01, 0xff, 0x06, HM_Config_Changed },
// { 0x40, 0xff, 0xff, HM_Remote_Event },
{ 0x00 }
};
Buttons button[1]; // declare remote button object
Sensirion sht10;
BMP085 bmp085;
Sensor_SHT10_BMP085 sensTHP;
mit dieser Meldung:
HM_WDS10_TH_O.ino: In function 'void setup()':
HM_WDS10_TH_O:78: error: 'sensTHP' was not declared in this scope
HM_WDS10_TH_O:79: error: 'sht10' was not declared in this scope
HM_WDS10_TH_O:79: error: 'bmp085' was not declared in this scope
da komm ich als Anfänger einfachn nicht weiter - zumal ich ja keinen Luftdrucksensor habe sondern nur den Temp/Hum DHT22 auf dem Battery Board - und der ist auf A1/A2 angeschlossen (laut Schaltplan)
somit müsste ich weiter unten
sensTHP.regInHM(1,&hm); // register sensor class in hm
sensTHP.config(A4, A5, 0, &sht10, &bmp085, 570);
auf
sensTHP.regInHM(1,&hm); // register sensor class in hm
sensTHP.config(A1, A2, 0, &sht10, NULL, 570);
ändern - reicht das aus ?
Gruß Christoph
Hi,
zuerst musst du mal das Archiv "additional-sensor-libraries.zip" in den Library Ordner entpacken.
Aber nicht ins AskSin Verzeichnis, sondern eins höher.
Dann sollten auch deine Fehler beim Kompilieren der Vergangenheit angehören, egal ob Sensoren angeschlossen, oder nicht.
Wenn Kompilieren geht, dann konfigurierst du deine HW richtig, also
#include <BMP085.h> // pressure library
auskommentieren durch //
BMP085 bmp085;
ebenfalls auskommentieren
sensTHP.config(A4, A5, 0, &sht10, NULL, 570); // data pin, clock pin and timing - 0 means HM calculated timing, every number above will taken in milliseconds
Hier gibst du die richtigen Pins an für deinen SHT10 an, in genanntem Beispiel ist es
A4 Data Leitung des Sensors
A5 CLK Leitung des Sensors
0 gibt die Wiederholung des Sendens in millisekunden an, 0 steht für Berechnung durch die Lib
&sht10 ist die Adresse zur Class die du weiter oben deklariert hast.
Wenn du jetzt einen DHT22 einbinden möchtest, dann musst alles was mit dem SHT10 zu tun hat durch die DHT22 Class ersetzen,
zusätzlich die Sensor Class abändern "Sensor_SHT10_BMP085.cpp"
Da du aber schon Probleme beim Kompilieren hast, würde ich dir empfehlen, einen SHT10 einzusetzen :-))
Viele Grüße
Horst
Ich habe mir gerade man das Schematic-PDF angesehen.
Kann mir sagen was beim MAX1724+ das L1 für ein Induktor-Bauteil ist? Vor allem ein Link (zb. Reichelt) wäre hilfreich...
Hallo Tobias,
L1 ist eine Speicherdrossel. Laut Datenblatt wird unter anderem eine aus der Murata Serie LQH4C empfohlen die Serie LQH3C sollte für den Einsatz aber genau so passen. Die gäbe es auch eine bei Reichelt. Artikelnummer: "LQH3C 10µ"
Gruß
Dirk
Hallo Zusammen,
während der Wartezeit auf die ersten Platinen, laut Sendungsverfolgung sollten die im Laufe dieser Woche hier ankommen, habe ich mich doch entschlossen das Layout etwas universeller zu machen.
Herausgekommen ist das "Universal-Sensor-Board"
Das Layout basiert auf dem bisherigen Schaltplan / Layout. Ist dazu also voll kompatibel.
Folgende Funktionen sind hier vorgesehen:
Sensoren auf dem Board: Feuchte / Temperatur / Luftdruck / Helligkeit
Weitere Sensoren über das Shield erweiterbar (kleine Zusatzplatine): z.B. Bewegung / Gas (z.B. CO2, Luftgüte) usw.
Schnittstellen: CC1101 868Mhz-Modul oder 433Mhz-Modul / RS485 / evtl. 1-Wire (Softwarebassierend über den Atmage32p)
Spannungsversorgung: Batterien, 2 Zellen oder 1 Zelle mit MAX1724 / 7(5)-24 V (extern z.B. über den RS485-Bus).
Im Schaltplan sind die einzelnen Optionen durch gestrichelt Linien gekennzeichnet.
Die unterschiedlichen Funktionen ergeben sich dann durch verschiedene Bestückungsvarianten.
JP1 überbrückt standardmäßig den MAX1724. Falls dieser bestückt werden soll, muss diese Brücke getrennt werden.
Alternativ kann mit einer Brücke die 5 V vom Spannungsregler (MC34036) an das Shield angelegt werden und so 5 V Sensoren versorgen.
Die Pegelwandlung (5 auf 3,3V) muss dann auf dem Shield erfolgen.
Der Atmega32p hat in diesem Layout die Möglichkeit mit 2 verschiedenen Quarz-Bauformen ergänzt zu werden. Q1 könnte z.B. ein 32,768 kHz Quarz sein. Q2 z.B. ein 8 Mhz Quarz um im RS485-Mode ein stabilen UART zu gewährleisten. Als "einfaches" CC1101-Sensor-Modul reicht die Genauigkeit des interne Osszillator des Atmega32p aus, so dass hier kein Quarz bestückt werden muss.
Die Bauteile für die externe Spannungsversorgung werden alternativ auf dem Platz bestückt auf dem sonst der Batteriehalter sitzt, somit komme ich hier mit den selben mechanischen Platinenabmessungen aus. Damit passt auch das in einem früheren Post gezeigte Gehäuse. Bei der externen Spannungsversorgung kommt ein Schaltregler zum Einsatz der intern für den RS485 Tranceiver 5 V zur Verfügung stellt. Danach kommt noch ein kleiner Liniarregler, der 3,3 V für die restlichen aktiven Bauteile zur Verfügung stellt.
Die 7(5)-24 V könnte auch zur Versorgung "Energiehungriger" Sensoren wie Gas, VOC usw. dienen. Damit könnte man die Schaltung auch über ein kleines Steckernetzteil versorgen.
Anbei der Schaltplan und auch das Layout.
Macht so ein Universalboard aus eurer Sicht Sinn oder soll ich bei dem ursprünglichen Layout bleiben?
Viele Grüße
Dirk
Schau mal bitte ins Bastelforum in meinen thread. Mit deinem universalsensor wird langsam zu identisch ;(
http://forum.fhem.de/index.php/topic,20956.0.html
In meinem Plan fehlt nur noch das SPI-Display.... Das muss ich noch einfügen.
Jedenfalls könnten wir da ev. zusammenarbeiten....
Btw: hasts du deine PLatine für ein spezielles Gehäuse designed? Ich hab eins im Auge......
Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk
finde die neue sehr gut !
*habenwollenhabenwollen* ;)
Hi Tobias,
ZitatSchau mal bitte ins bastelforum in meinen thread.
Ich hab das am Rande mitbekommen.
Ich bin mir aber nicht sicher, ob man das so alles in das geplante Gehäuse bekommen würde:
http://forum.fhem.de/index.php/topic,20620.msg143214.html#msg143214
Die Basis Panstamp fand ich ehrlich gesagt auch nicht so interessant.
Das Ursprüngliche Layout entstand auf Basis der Software die Trilu quasi fertig hat. Daher ist die Ansteuerung für die Sensoren softwareseitig schon so ziemlich fertig. Und da würde ich, auch aus Platzgründen nicht so viel ändern wollen.
Die RS485-Erweiterung hatten wir ein paar Beiträge weiter unten schon mal diskutiert.
ZitatDa konnte wir zusammenarbeiten....
Warum nicht? Die ersten Platinen sollte ich ja diese Woche schon bekommen. Dann kann ich auch schon ein paar Erfahrungen vom "Fertigmodul" berichten.
Würde denn die Basis für deine geplanten Sensoren passen? Ich vermute den Panstamp bekommt man da bestimmt nicht so ohne weiteres drauf?
Würde das mit deinen Anforderungen da noch passen?
Was müsste geändert werden damit das für dich passt?
Gruß
Dirk
Irgendwie kann ich es nicht verstehen eine Hardware um einen Panstamp herum zu entwickeln. Der grosse Vorteil des Panstamp Moduls ist das es Funk an Board hat. Für Steckbrett und zum Proggen super, aber bei Eigenentwicklung doch viel zu teuer. Ausserdem muss bei Eigenentwicklung gelötet werden, da kommt es auf das Funkmodul nicht an...
@dirk - mir gefällt das Konzept des Baukastens. Macht das die Ursprungsidee teurer? Ich denke der grösste Bedarf ist bei Temperatur, Feuchte und vielleicht Licht.
Druck reicht einmal im Haus und Luftgüte wird vermutlich teuer wegen des Sensors...
Viele Grüsse
Horst
Fuer mich ist ganz wichtig die Luftguete (TGS2600) und ggf co2 (TGS4161) wert. Dazu noch ein SPI Display um die werte anzuzeigen. Schau mal in meinen Schaltplan.
Warum findest du die panstamps nicht gut? Sind klein und kompakt. Kleiner als der Arduino + CC1101. Kosten auch nur 18€/Stück. Die Versandkosten kann man bei Sammelbestellung vernachlässigen.
Wegen der Luftgütesensoren ist BatterieBetrieb kein Thema (Jeder Sensor verbraucht ca 50mA). Deswegen kann ich mir den Batteriehalter sparen.
Ich verwende auch BMP085 Sensoren, aber nicht Plain sondern als AddonBoard. Ist leichter zum Löten...
Habe mich mal heute morgen durch den ganzen Thread durchgewühlt und alles gelesen ...puhhhh. Warscheinlich können wir uns nur in Teilen der Schaltung austauschen... :(
Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk
Hallo.
Lese schon die ganze Zeit begeistert mit.
Bin gespannt ab wann ich welche bestellen kann.
Aber nur mal so also dumme Frage, wären die Module vielleicht mal möglich um sie als counter an Zähler anzubinden......
Stenny
was meinst du mit counter an zähler zu binden?
ich bin gerade am überlegen wie ich meinen strom und gas zähler an fhem anbinden kann,
stromzähler hat dieses ir fenster und der gaszähler einen magneten, also reed kontakt möglich.
allerdings macht der strom und gas zähler über homematic protokoll nicht wirklich viel sinn, oder fällt dir
ein guter grund ein?
viele grüße
trilu
Hallo,
mir schon - ich kann meinen HM-LAN nutzen un brauche nicht noch einen weiteren Empfänger/Protokol in fhem.
Ich suche auch nach einer Lösung S0 oder sonstige Impulse zu zählen und das Ganze über HM Protokol zu übertragen.
Gruß Christoph
Zitat von: trilu am 11 März 2014, 06:48:30
@dirk - mir gefällt das Konzept des Baukastens. Macht das die Ursprungsidee teurer?
Nein. Die Kosten für die reine Platine wird sich durch die Änderungen sicher nicht im Preis erhöhen. Eher das Gegenteil könnte sein, wenn man so evtl. größere Stückzahlen ordern kann. Der Komplettpreis wird sich, wie auch jetzt schon, anhand der endgültigen Bestückung ergeben.
ZitatIch denke der grösste Bedarf ist bei Temperatur, Feuchte und vielleicht Licht.
Druck reicht einmal im Haus und Luftgüte wird vermutlich teuer wegen des Sensors...
Dito.
Zitat von: Tobias am 11 März 2014, 07:12:08
Fuer mich ist ganz wichtig die Luftguete (TGS2600) und ggf co2 (TGS4161) wert. Dazu noch ein SPI Display um die werte anzuzeigen.
Wenn du magst, schicke ich dir eine der ersten Prototypen-Platine. Bis auf die externe Spannungsversorgung sind die Anschlüsse vom Shield größtenteils identisch.
Da könntest du etwas experimentieren.
Ich habe noch Displays aus diesem Projekt übrig:
http://forum.fhem.de/index.php/topic,12854.msg77861.html#msg77861
Das lässt sich recht einfach per SPI ansteuern. Oder an was für ein Display hattest du gedacht?
ZitatIch verwende auch BMP085 Sensoren, aber nicht Plain sondern als AddonBoard. Ist leichter zum Löten...
Das stimmt. Im geplanten Gehäuse mit Batterien währ dafür der Platz aber ziemlich eng.
ZitatHabe mich mal heute morgen durch den ganzen Thread durchgewühlt und alles gelesen ...puhhhh. Warscheinlich können wir uns nur in Teilen der Schaltung austauschen... :(
Kommt drauf an. Wenn du unbbedingt auf die Panstamps setzen willst, dann stimme ich dir zu. Ansonsten könntest du deine Sensoren auf eine Zusatzplatine packen.
Was für ein Panstamp wolltest du als Grundlage nehmen? das "alte" mit Atmega32p oder das "neue"? Was hat das "neue" für technische Daten? habe dazu noch keine Infos gesehen.
Zitat von: stenny73 am 11 März 2014, 07:54:43
... wären die Module vielleicht mal möglich um sie als counter an Zähler anzubinden......
Das geht bestimmt. Im Endeffekt kommt es darauf an über welches Medium und in welchem Abständen und Auflösungen du die Information übertragen möchtest.
Per Funk gibt es in einigen Frequenzbereichen, auch dem welches Homematic benutzt, Einschränkungen bezüglich der Kanalauslastung (Duttycycle). Ggf. müsstest du hier die Zähler summieren und in "größeren" Intervallen zur Zentrale (FHEM) senden.
So ähnlich funktioniert das bei der neuen Homematic-Funkschaltsteckdose mit Energiezähler auch.
In einigen Frequenzbereichen, vor allem im 433 Mhz Bereich kann man auch dauernd Senden.
Alternativ währ dann noch den Zähler Kabel gebunden anzuschließen. Z.B. über RS485.
Im Prinzip hängt das "nur" von der Software ab, die dann auf dem AVR läuft.
Gruß
Dirk
Im Grunde reichen doch die Summierten Impuls alle paar Minuten zu bekommen vom Gas oder Stromzahler ( bei denen mit Scheibe).
Genial wäre es natürlich auch wenn man per infrarot Schnittstelle die smartmeter auslesen könnte..... Aber das wäre wohl eine ganz andere Geschichte.
Gesendet von meinem HTC One mit Tapatalk
Hi,
mir isses eigentlich egal ob da ein Panstamp oder ein arduino mit CC1101 werkelt. Mit den ganzen Sensoren muss es nur in dein=mein Gehäuse passen. Geplant ist der alter AVR-Panstamp. Davon habe ich noch 4 hier rumliegen. Schlussendlich soll das Ganze aber per SWAP-Protokoll versendet werden.
Ich habe dieses Display im Auge: http://www.adafruit.com/products/358
Schau dir mal den Schaltplan an... Wenn du Ahnung davon hast kannst du ja mal bitte einen kritischen Blick drauf werfen... Die Schaltung bleibt ja dieselbe - egal ob onBoard oder durch Zusatzplatine
Zitatmir schon - ich kann meinen HM-LAN nutzen un brauche nicht noch einen weiteren Empfänger/Protokol in fhem.
Ich suche auch nach einer Lösung S0 oder sonstige Impulse zu zählen und das Ganze über HM Protokol zu übertragen.
ZitatIm Grunde reichen doch die Summierten Impuls alle paar Minuten zu bekommen vom Gas oder Stromzahler ( bei denen mit Scheibe).
Genial wäre es natürlich auch wenn man per infrarot Schnittstelle die smartmeter auslesen könnte..... Aber das wäre wohl eine ganz andere Geschichte.
Der Vorteil des HM Protokolls ist ja, das man Geräte verknüpfen kann. Also Aktionen von Sensoren ableiten. Die einzig sinnvolle Aktion die ich aus erhöhtem Stromverbrauch
ableiten könnte, ist meiner Frau den Fön auszuschalten :-)
Mal im Ernst, was mir vorscheben würde ist ein Gerät dem ich den Zählerstand und den Multiplikator einmal übergebe und er nicht irgendwelche Impulse weiterleitet, sondern den Momentanverbrauch und den Gesamtverbrauch. Mein Stromzähler liefert das über IR. Mein Gaszähler nicht, also muss eine universelle Lösung her :-)
Batteriebetrieb würde für ein Reedrelais gehen, das könnte über Interrupt ein Device wecken und sollte damit schön sparsam sein. Stromzähler, egal ob IR Link oder Ferraris, braucht Dauerstrom. Für meinen Wasserzähler bräuchte ich auch eine Optik, vermutlich mit einem kleinen Laser.
Damit würde mir etwas wie das hier vorschweben:
http://www.amazon.de/TP-Link-TL-WR703N-802-11n-Wireless-Router/dp/B008UNA6FS
Das Ding hat Wlan, Netwerk und USB - damit würde IR Link direkt gehen, Ferraris Zähler, Gas und Wasser könnte man mit einem kleinen Arduino konvertieren.
Was haltet ihr davon?
Hallo,
1. Ich finde die HW Erweiterung WOW, da ich wohl in Summe 10 Sensoren brauche ud davon 8 die ich mit Bewegung erweitern will.
2. wg den anderen Aktionen sollten getrennte Threads aufgemacht werden sonst wir das zu unübersichtlich.
Ich bin auch schon dran und plane eine Art "universal" Schaltmodul.
Geplant sind bis zu: 8 230V Schalter SolidStateRelais, 15 LED Kanäle (3*5er Stripes), Temp/Helligkeitsmessung, 2 Bewegungsmelder. Realisieren liesse sich damit z.B. die Steuerung Wasserbett oder Aquarium. Aber auch Stereoanlage WZ mit Hintergrundbeleuchtung und Tempüberwachung.
Ich muss nur mal zusehen, das ich die Bauteile als Vorlage für Eagle erstelle oder finde und mich in Homematic einlesen, ob das so machbar ist von den Channels usw.
Nico
Hi Tobias,
Zitat von: Tobias am 11 März 2014, 12:25:32
Schlussendlich soll das Ganze aber per SWAP-Protokoll versendet werden.
Ich denke das sollte auch funktionieren. Ggf. muss hier noch GDO2 vom CC001 Modul verbunden werden. Diesen nutzt die Lib von Trilu aktuell nicht.
ZitatIch habe dieses Display im Auge: http://www.adafruit.com/products/358
Für die Displayansteuerung sollte man noch zusätzlich etwas I2C-Ram mit integrieren um einen Framebuffer für das Display zu haben.
Das kann aber auf der Display-Platine mit sein. Bei einem SW-Display mit 128x64 Pixeln währen das hier schon um die 8 kb RAM bei einem Farbdisplay entsprechend mehr.
Ohne Framebuffer geht es zwar auch, die Ansteuerung ist dann meist aber schwieriger. Zumindest bei dem Display was ich hier habe kann man keine einzelnen Bildpunkte Adressieren und zeichnen, sondern nur einen kompletten Block. Das kann bei deinem Display aber anders sein.
ZitatSchau dir mal den Schaltplan an... Wenn du Ahnung davon hast kannst du ja mal bitte einen kritischen Blick drauf werfen...
Beim CO2 Sensor brauchst du keinen Levelshifter. Hier kommt doch "nur" eine analoge Spannung raus, hier würde also ein einfacher Spannungsteiler mit 2 Widerständen ausreichen.
Das Selbe gilt für den VOC-Sensor.
Dem DHT22 und dem TEMT6000 würde ich noch je einen 100 nF Abblockkondensator verpassen.
Der MAX1797 scheint mir nicht der passende Schaltregler zu sein. Das ist eine StepUp Regler. Ich hab das Datenblatt nur mal überflogen.
"The input voltage range is +0.7V to VOUT, where VOUT can be set from +2V to +5.5V."
Wenn VOUT bei dir "nur" 3,3V sind, dann kann VIN auch nur bis 3,3V gehen.
Bei der Auswahl der Spule musst du darauf achten dass das eine Speicherdrossel sein sollte. In den Datenblättern der Regler werden aber meist entsprechende Spulen empfohlen.
Dein aktueller Verpolschutz ist so im Moment unwirksam. GND vor und hinter dem Mosfet dürfen nicht verbunden sein. Das GND-Symbol muss also hinter den Mosfet.
Je nach Mosfet wirst du hier trotzdem einen Spannungsabfall haben. Daher musst du prüfen ob deine 5 V Sensoren noch bei 4,9 V oder 4,8 V sicher arbeiten.
Ansonsten: wenn du nicht zwingend aus 5 V versorgen musst, nimm einen Schaltregler um von > 6 V auf 5 V zu kommen und einen einfachen Liniarregler um dahinter von 5 V auf 3,3 V zu kommen.
Dann kannst du als Verpolschutz auch eine "einfache" Diode verwenden
Gruß
Dirk
Hi Dirk,
habe alle deine Hinweise befolgt. Kannst du Bitte nochmal drauf schauen?
Ist es wirklich gut an die Gassensoren einen einfachen Spannungteiler anzusetzen? Hat dieser nicht einen zu hohen Stromverbrauch? Ich hoffe die Kombination 680/1k ist korrekt...
Hallo,
Nimm doch einfach Widerstände mit grösserem Werte in gleichem Verhältnis, dann hast Du weniger Verlust im Spannungsteiler.
z.B. 6,8k/10k
Nico
Die Antwort für Tobias habe ich im Parallel Tread geschrieben:
http://forum.fhem.de/index.php/topic,20956.msg148631.html#msg148631
Gruß
Dirk
Ps. Heute sind die Platinen gekommen. Ich bin aber erst morgen wieder zu Hause. Dann kann ich am Wochenende Basteln und berichten :)
cool, ich freue mich!
dann können wir ja weiter basteln :-)
Danke für das interessante Projekt.
Ist die Sammelbestellung noch aufnahmefähig (leider habe ich erst gestern wieder ins Forum reingeschaut) ? Wenn ja, möchte ich auch gern meine Wünsche nennen:
2x indoor-komplett (gehäuse,batteriehalter,platine,atmega,max,T, Feuchte,druck, Helligkeit, (+ PIR))
5x indoor-T/H (gehäuse,batteriehalter,platine,atmega,max,T, Helligkeit (+PIR))
2x outdoor (gehäuse,batteriehalter,platine,atmega,max,T, Feuchte, Helligkeit, (+ PIR))
Vielleicht später noch mehr.
Ich habe keine Ahnung von der Elektronik. Aber, das Basteln macht immer Spaß.
Gruß
anh
Hallo anhtu,
ZitatIst die Sammelbestellung noch aufnahmefähig
Ja, Wir sind erst in der Prototyp-Phase :)
PIR ist auf dem Bord noch nicht mit drauf.
Wenn es klappt wie geplant sollte das dann aber als Aufsteckplatine möglich sein.
Im Outdoorgehäuse wird der Temperatur/Feuchte Sensor nicht Onboard sein.
Da das Außengehäuse einen Transparenten Deckel hat, und als Helligkeitssensor im Sommer auch jede Menge Wärme einfängt, macht der Sensor hier nicht soo viel Sinn.
Dieser muss dann extern angeschlossen werden. Der I2C-Port ist über eine Steckerleiste aber nach außen geführt.
Gruß
Dirk
danke. alles klar. ich warte darauf :).
Hallo,
Ich konnte es gestern Nacht doch nicht lassen und habe einen ersten Sensor zusammengebaut.
Noch ohne SHT10, Also noch keine Feuchte/Temperatur, weil die Sensoren noch nicht da sind. Die sollte aber jeden Tag hier ankommen.
Der Sketch von Trilu funktioniert auch, allerdings ohne valide Daten wegen dem noch fehlenden Sensor.
Verbaut ist aber der Temperatur/Luftdruck- und der Helligkeitssensor.
Beide liefern auch schön Daten, allerdings derzeit "nur" auf dem Terminal. Die Homematic Integration fehlt hier noch.
@Trilu:
Ich baue dir am Wochenende einen Sensor zusammen und schicke ihn dir, wenn du deinen SHT10 hier auf die Platinen transplantieren möchtest.
Ansonsten müsstest du noch ein Paar Tage warten. Willst du eine Version mit Max oder ohne?
Anbei noch ein Paar Bildchen.
Gruß
Dirk
Ps.
Der Max ist bei dieser Version noch nicht bestückt.
Der kommt hier heute erst an.
Update:
Beim ausmessen der Befestigungslöcher für die Platine hatte ich mich wohl etwas vertan.
Daher sind auf der rechten Seite noch 2 neue Löcher dazugekommen. Jetzt kann man die Platine auch wieder ordentlich befestigen.
(http://hfma.de/images/FHEM/CC1101-Sensor_fertig.jpg)
(http://hfma.de/images/FHEM/CC1101-Sensor_geoeffnet.jpg)
(http://hfma.de/images/FHEM/CC1101-Sensor_platine_oben.jpg)
(http://hfma.de/images/FHEM/CC1101-Sensor_Platine_unten.jpg)
sieht echt cool aus.
gruss frank
Klasse ;)
@Dirk - Profi am Werk! Das Ding sieht klasse aus, echt Professionell!
SHT10 umlöten ist kein Thema.
Max wäre gut, weil dann könnte ich mich auch an die Spannungsmessung setzen, so dass Batterie ok/not ok variabel wird.
Wie wollen wir den Helligkeitswert übergeben?
Martin hat ja die Druckmessung/Anzeige bereits in FHEM integriert. Das passiert hier:
if($modules{CUL_HM}{defptr}{$src.$chn}){
push @entities,CUL_HM_UpdtReadBulk($modules{CUL_HM}{defptr}{$src.$chn}
,1,$statemsg
,"temperature:$t")
}
if ($h) {$statemsg .= " H: $h" ; push @event, "humidity:$h"; }
if ($ap){$statemsg .= " AP: $ap"; push @event, "airpress:$ap";}
push @event, $statemsg;
}
Das ganze wertet einen Weather Event aus - 2 byte temperatur, 1 byte feuchte, 2 byte druck
Hier könnte man noch 2 byte anhängen für Helligkeit. Wie gesagt, das wäre dann aber ein Weatherevent, damit kann man
keine Aktionen über Peer verknüpfen.
Die zweite Möglichkeit wäre den Sensor Event dafür zu nutzen. Das wäre aufwändiger zu implementieren, da wir einen
eigenen Kanal dafür brauchen und diverse Register ausgewertet werden müssen. Zusätzlich können wir nur ein byte als Value übergeben.
Der Vorteil wäre aber, wir könnten dann einen Dimmer ansteuern um die abnehmende Helligkeit auszugleichen...
"41" => { txt => "Sensor_event", params => {
BUTTON => '00,2,$val=(hex($val)&0x3F)',
LONG => '00,2,$val=(hex($val)&0x40)?1:0',
LOWBAT => '00,2,$val=(hex($val)&0x80)?1:0',
NBR => '02,2,$val=(hex($val))',
VALUE => '04,2,$val=(hex($val))',} },
Viele Grüße
Horst
ZitatMax wäre gut, weil dann könnte ich mich auch an die Spannungsmessung setzen, so dass Batterie ok/not ok variabel wird.
Ich baue dir einen Max mit drauf.
Die Spannungsmessung sollte mit und ohne max über den Spannungsteiler R5 und R6 laufen können.
Alternativ könnten wir ohne Max aber die Bestückung weglassen und die Spannungsmessung über die interne Referenz machen.
Ggf. sollte beide Möglichkeiten im Code vorhanden sein.
ZitatWie wollen wir den Helligkeitswert übergeben?
Für die Helligkeitsmessung könnten wir den ks550 nehmen. der Hat schon Frames für Helligkeit.
Allerdings keins für Luftruck.
Luftdruck hat nur die ws550.
Alternativ erstellen wir ein komplett neues Device für den "Komplett-Sensor".
Die XML-Datei, damit das ding auch an der CCU läuft könnte ich dann machen.
Das kann man als Update dann auch selber an einer CCU einspielen.
Als Frames würde ich hier Vorschlagen:
TEMPERATURE, HUMIDITY, BRIGHTNESS (siehe ks550) und AIR_PRESSURE aus ws550.
Der Helligkeitssensor hat 2 Gain-Einstellungen. "low" Faktor 1 und high (Faktor 16)
High könnte man nehmen wenn der Sensor im Innengehäuse steckt. Dann ist der empfindlicher.
Und dann könnte man sich auch überlegen was man mit dem Threshold macht und den Sensor ggf. ewents auslösen lässt, wenn die Helligkeit sich "zu schnell" ändert.
Als zusätzlicher Alarmsensor interessant.
Gruß
Dirk
du willst also beide varianten :-)
Weather und Sensor Event ...
ZitatWeather und Sensor Event ...
War nur eine Idee.
Aber lass uns mit den Weather-Events beginnen.
Wer die Sensor-Events noch braucht kann dann später ja updaten.
Dazu ist dann im einfachsten Fall ja nur ein USB-UART-Kabel erforderlich.
Ich habe mir gestern übrigens den Bootloader ein paar mal Zerschossen.
Man muss auf einem Frischen AVR nachdem man den Bootloader geflasht hat, die Lock Bits für den Bootloader (LPM und SPM) setzen.
Sonst kann es passieren, wenn man ein zu großes Hex-File per Bootloader flasht, dieses in den Botloaderbereich schreibt. Dann ist der Bootloader futsch. und man muss den per ISP wieder neu flashen.
Mit gesetzten Lockbits passiert das dann nicht.
Was meinst du, eigenes Device? Welche Type-ID nehmen wir dann? Vielleicht eine die das erste Byte auch nuzt? dann kommen wir mit den bestehenden nicht ins "gehege". Vielleicht irgendwas mit FExx?
Wie wollen wie das Device dann nennen? Mein Vorschlag:
CC-WDSen-THPL-I und CC-WDSen-THPL-O
Seriennummer und HM-ID würde ich beim ersten Einschalten ggf. Zufällig vergeben und ins Flash schreiben. Wer möchte kann diese Daten dann per Konsole ggf. noch ändern.
Alternativ ging auch noch 2 Virtuelle Devices in einer Hardware. Das ist aber aufwendiger, Weil die Register doppelt vorhanden sein müssten.
wenn wir erst mal nur den Weather Event nehmen würde ich keine Änderungen am Device Type machen.
Das müsste ja alles in FHEM, etc nachgezogen werden.
Ich würde den Helligkeitswert schlichtweg hinten an den Weatherevent anhängen und Martin bitten das mit in
CUL_HM.pm zu übernehmen.
Wenn wir dann die Helligkeit als eigenen Channel machen, dann brauchen wir einen eigenen Gerätetyp.
Dann würde ich aber auch anfangen, Temperatur und Feuchtigkeit als Sensor Wert in jeweils einem eigenen
Kanal zu übergeben.
Sensorevents hätten den Vorteil das man damit Aktoren steuern kann. Z.b. einen Lüfter schalten, wenn die
Luftfeuchtigkeit zu hoch wird. Oder mit einem Steckdosenaktor einen Radiator schalten auf Basis der Temperatur
unseres Geräts.
ZitatIch würde den Helligkeitswert schlichtweg hinten an den Weatherevent anhängen und Martin bitten das mit in
CUL_HM.pm zu übernehmen.
So hätte ich das auch gemacht. Halt als eigener Devicetyp dann Kann die CCU damit dann auch was anfangen.
Bei der WS550 ist AIR_PRESSURE lediglich ein zusätzlicher Parameter. Plane für AIR_PRESSURE aber 2 Bytes ein. Für Helligkeit würde ich auch 2 Bytes planen.
Dann kann man die vollen 16Bits vom TSL2561 übertragen.
Die Gainumschaltung machen wir dann erstmal per Console. Die muss man pro Sensortyp eigentlich auch nur einmal einstellen.
Wenn wir das so machen, dann kann ist das XML-File ja trotzdem vorbereiten.
Kannst ja Martin mal fragen wie hoch der Aufwand währ ein neues Device dafür zu definieren. Das sollte sich aber in Grenzen halten.
ZitatWenn wir dann die Helligkeit als eigenen Channel machen, dann brauchen wir einen eigenen Gerätetyp.
Das Sowieso
Das sollte beim HM-WDS10-TH-O und den verwandten Sensoren bereits funktionieren. Zumindest haben die Im XML-File eine link_role-source vom Typ WEATHER_TH. Da sind auch Weather-Events definiert. Daher müsste man diese Sensoren auch jetzt schon mit den passenden Empfängern "verheiraten" können.
Ich schreib Martin mal an - falls er hier nicht sowieso mitliest :-)
Das sollte beim HM-WDS10-TH-O und den verwandten Sensoren bereits funktionieren. Zumindest haben die Im XML-File eine link_role-source vom Typ WEATHER_TH.
Das ist ja das was ich bei einem eigenen Device mit Sensor je Channel ändern möchte. Ich möchte dann auch die Sensor event message nutzen.
WEATHER_TH lässt sich mit dem Heizungsthermostat pairen, aber nicht mit dem Schaltzwischenstecker.
SENSOR_TH würde sich auch mit einem Schaltzwischenstecker, oder dem Platinenrelaismodul, etc kombinieren lassen.
Weisst du was ich meine?
ZitatWEATHER_TH lässt sich mit dem Heizungsthermostat pairen
Ahso, Vermutlich nur mit dem.
Also dann mit ober und unterer Schaltschwelle usw.
ich lese nur gelegentlich mit. Hoffentlich habe ich also die Frage erfasst.
ein TH Sensor lässt sich mit 'wetter-empfängern' peeren - es sollten auch mehrere gehen.
Das Problem ist das Timing. Das ist im Prinzip wir beim TC->VD verhalten. Der Sender solch regelmaessiger messages wacht nach mit einen definierten 'jitter' auf. Die Empfänger müssen das auch tun.
Die Berechnung des nächsten Aufwachen wird aus der ID des Senders und der message-nummer errechnet.
Ob es funktioniert kann man mit dem virtuellen TH testen. Also
- virtuellen Channel erstellen
- peeren mit einen RT weather channel - fhem save (der virtuelle Channel leitet hiervon seine neuen Kommandos ab)
- set vChan virtTemp 20
Nun sollte der Virtuelle Channel etwa alle 2,5min die 20Grad senden. Der RT sollte dies empfangen und sich auf das Timing synchronisieren. Das Fenster des RT ist ziemlich schmal - sollte beim Fehlern breiter werden.
Wenns funktioniert können wir den Algo direkt in den eigenbau einpassen.
Gruss Martin
Hier sind noch kurz ein paar Bilder vom aufgebauten Außensensor.
Die gezeigte Bestückungsvariante enthält hier nur den Lichtsensor.
Auf der Platine ist noch Platz für den Luftdrucksensor. Da das Gehäuse Wasserdicht ist, muss zum Druckausgleich ein kleines Loch z.B. auf der Unterseite gebohrt werden damit der Luftdrucksensor auch den Außendruck messen kann.
Ein Separater Temperatur / Feuchtesensor ist auf der Platine nicht geplant, da man im Gehäuse wohl keine Sinnvollen Temperaturwerte ermitteln kann.
Der I2C-Bus ist aber auf eine Steckerleiste geführt, so dass man einen externen Sensor anschließen könnte.
Gruß
Dirk
(http://hfma.de/images/FHEM/CC1101-Sensor-Aussen_Fertig.jpg)
(http://hfma.de/images/FHEM/CC1101-Sensor-Aussen_Platine.jpg)
Zitat von: Dirk am 15 März 2014, 00:02:43Auf der Platine ist noch Platz für den Luftdrucksensor. Da das Gehäuse Wasserdicht ist, muss zum Druckausgleich ein kleines Loch z.B. auf der Unterseite gebohrt werden damit der Luftdrucksensor auch den Außendruck messen kann.
Ein Separater Temperatur / Feuchtesensor ist auf der Platine nicht geplant, da man im Gehäuse wohl keine Sinnvollen Temperaturwerte ermitteln kann.
Der I2C-Bus ist aber auf eine Steckerleiste geführt, so dass man einen externen Sensor anschließen könnte.
Großartig... Eine Freude, die Fortschritte mit anzusehen. :-)
Eine Frage hätte ich aber: Wäre es nicht sinnvoller, den Luftdrucksensor wie auch bereits Temperatur und Feuchtigkeit nach außen zu führen, damit das Gehäuse auch wirklich dicht ist?
Wenn man nur Helligkeit und Druck messen möchte, ist es wohl nicht besonders praktikabel. Ich könnte mir aber gut vorstellen, dass alle, die mehr als nur Helligkeit messen wollen, wenn dann nicht nur den Druck sondern eben auch gleich Temperatur und Feuchtigkeit messen. :-)
ZitatEine Frage hätte ich aber: Wäre es nicht sinnvoller, den Luftdrucksensor wie auch bereits Temperatur und Feuchtigkeit nach außen zu führen, damit das Gehäuse auch wirklich dicht ist?
Der Luftdrucksensor braucht nur ein recht kleines Lock als Druckausgleich.
Entsprechend angebracht bleibt das Gehäuse immer noch Spritzwassergeschützt.
Da der I2C-Bus aber nach außen gelegt werden kann, kann auch hier der Drucksensor zusammen mit dem Temp/Feuchtesensor auf einer externen Platine untergebracht werden. Der interne Sensor bleibt dann einfach unbestückt.
Gruß
Dirk
Sieht gut aus. :)
In diesem Gehäuse habe ich auch mein Prototyp aufgebaut (basiert allerdings auf ATtiny84a und RFM12B).
Enhaltene Sensoren (Temp/Luftdruck: DHT22, Licht: BH1750). Für den DHT22 habe ich in das Gehäuse ein Loch eingefräst und den Sensor wasserdicht verklebt. Vielleicht wäre das auch hierfür eine Alternative.
(http://s6z.de/cms/images/content/arduino/TinyTX/TinyTX_Proto_Outdoor_01_k.jpg)
Gruß,
Alexander
Hallo Dirk,
Nach dem gestrigen Event in Karlsruhe, bin ich dann auch mal auf den Thread aufmerksam geworden. Könntest du für mich
1x indoor-komplett (gehäuse,batteriehalter,platine,atmega,max,T, Feuchte,druck, Helligkeit, (+ PIR))
1x outdoor (gehäuse,batteriehalter,platine,atmega,max,T, Feuchte, Helligkeit, (+ PIR))
vorsehen? Wobei ich später bestimmt noch einpaar mehr benötigen würde.
Gruß svenson
Hallo zusammen,
auch ich bin gestern in Karlsruhe auf diesen Sensor aufmerksam geworden. Frage von mir:
Gibt es irgendwo den Schaltplan für den Außensensor (für den Innensensor wäre dieser auch nicht schlecht, da ich vermutlich auch schon eine Anwendung gefunden habe ;))?
Ich hatte so etwas ähnliches auf der Agenda, aber eher ein Update von diesem (http://www.busware.de/tiki-index.php?page=CPM-BS) Sensor. Da ihr vermutlich das Homematic Protokoll implementieren werdet, ich aber vermutlich eher das vorhandene FS20 nutzen würde, gäbe es aus meiner Sicht zwei Möglichkeiten:
- getrennte Firmware
- Auswahl des Protokolls (HomeMatic, FS20) per Taster (beim Einschalten des Gerätes gedrückt halten) und signalisieren per LED (sollte dann auch vorhanden sein 8)).
Was meint ihr dazu?
Viele Grüße
PeMue
ZitatDa ihr vermutlich das Homematic Protokoll implementieren werdet
Richtiger Satzbau, falsche Zeit - Ist bereits implementiert 8)
Ich denke für FS20 gibt es bereits genügend Lösungen, beim Homematic Protokoll finde ich das Peeren interessant und natürlich die
bidirektionale Kommunikation. FS20 und Homematic sind sehr unterschiedlich, beide in ein Device zu packen macht also wenig Sinn.
Das Abfragen der Sensoren beruht auf standard Arduino Libraries, FS20 Sende und Empafangsroutinen kann man sich bei busware
abschauen, sollte also einfach sein, eine eigene Firmware zu entwickeln...
Hallo,
leider konnte ich gestern nicht, ansonsten wäre ich gerne mal nach Karlsruhe gekommen.
Ich habe versucht es nochmal nachzuvollziehen, gab es schon eine Entwicklung Richtung PIR?
Ich habe bei Alibaba welche gefunden, die fast ohne externe Schaltung auskommen und auch nur via Widerstand im Schaltausgangsdelay einzustellen ist.
IMHO sollte das irgendwo zwischen 2-10 sec stehen und kann ruhig fix sein. Bereich sollte 3-6m sein. Was Indoor reicht.
Ansonsten würde ich mal welche bestellen und mal mit meinen Jeelink testen.
Nico
Zitat von: trilu am 23 März 2014, 11:39:11
Das Abfragen der Sensoren beruht auf standard Arduino Libraries, FS20 Sende und Empafangsroutinen kann man sich bei busware abschauen, sollte also einfach sein, eine eigene Firmware zu entwickeln ...
<witz>Wenn Du wüsstest, wie ich programmiere 8)</witz>.
Habt Ihr Eure Firmware irgendwo in github oder so? Mit Arduino sketches habe ich noch nie gearbeitet, aber C-Programme erstellt schon. Aber man kann ja immer etwas dazulernen.
Ist eigentlich die Firmware vom Innen- und vom Außensensor gleich?
Geht eigentlich der Sensor dann mit dem HM-USB Stick? Das wäre vielleicht für mich eine Alternative (obwohl ich eigentlich nicht so viele Empfänger haben will).
Dann melde ich mal starkes Interesse an je einem Innen- bzw. einem Außensensor an.
Gruß PeMue
ja, gibt einen github für die lib: https://github.com/trilu2000/AskSin
im ordner examples findest du das device, HM_WDS10_TH_O - die firmware für innen und außensensor ist gleich, ist ja auch die selbe hardware in einem unterschiedlichen gehäuse :D
bisher geht der sensor auch noch mit der HM software, wir emulieren ja ein original device. allerdings wird mit der HM soft vermutlich nur temperatur und feuchte angezeigt. für den luftdruck haben wir den string erweitert, folglich wird der druck momentan nur in FHEM mit angezeigt.
Hallo Zusammen,
diese Woche sind ein paar Temperatur/Feuchtsensoren gekommen, so das sich von den hier liegenden Prototypen-Platinen ein Paar bestücken kann.
Ich denke so um die 6-7 Sensoren könnte ich dann schon mal fertig machen.
Der voll bestückte Innensensor (ohne Max1724) mit Gehäuse liegt aktuell bei 29,00€.
Für den Max1785 + Spule usw. würden noch etwa 4,50€ dazu kommen.
Für eine Bestückungsvariante mit weniger Sensoren wird es dann entsprechend günstiger. Da das ziemlich viele Varianten sind, bitte einfach per PM anfragen.
Da die Anzahl noch sehr beschränkt ist, schlage ich vor, dass jeder Interessent erst einmal nur einen Sensor bekommen sollte. So können schon mal mehr von euch testen.
Falls das Teil für den einen oder anderen dann doch nicht das richtige ist, findet sich bestimmt ein anderer Abnehmer.
Die aktuellen Platinen werden sich von der fertigen Version nicht allzu groß unterscheiden. Im finalen Platinenlayout möchte ich lediglich Platz für die alternative Bestückung mit Draht gebundenen Sensoren (RS485) vorsehen.
Die Aktuelle Firmware die hier drauf läuft ist noch nicht ganz fertig, aber man kann schon alle Sensorwerte übertragen. Der Batterieverbrauch ist aber noch nicht optimiert.
Mit einem einfachen USB-UART-Kabel oder einem USB-UART-Adapter kann man aber ganz einfach selber Firmwareupdates durchführen.
Der Bootloader ist Arduino-Kompatibel.
Innen / Aussen-Sensor:Der Innensensor kann folgende Sensoren aufnehmen:
- Luftfeuchte/Temperatur
- Luftdruck
- Helligkeit
Der Aussensensor kann folgende Sensoren aufnehmen:
- Helligkeit
- Luftdruck (Temperatur)
- Weitere Sensoren wie z.B. Temperatur/Feuchte können jeder Zeit über den nach außen geführten I2C-Bus angeschlossen werden.
Den Innen-Sensor kann man auch außen einsetzen, sofern er spritzwassergeschützt angebracht wird.
ein
PIR-Sensor ist hier so noch nicht vorgesehen.
Aber: Die beiden Steckerleisten die nach Außen geführt sind, können beliebige zusätzliche Sensoren aufnehmen, sofern die benötigten Pins am AVR noch frei sind.
Hier gibt es aber noch keine abgestimmte Idee, so dass man für z.B. einen PIR-Sensor hier derzeit noch selber aktiv werden muss.
Die Spannungsversorgung für externe Sensoren kann im Bereich 2,6-3V, versorgt von den zwei AA-Batterien erfolgen.
Falls auf der Platine noch der MAX1724 bestückt wird, so kann man eine Stabile Spannungsversorgung von 3,3V auf dem Board erwarten.
Zitat von: PeMue am 23 März 2014, 10:37:31
Gibt es irgendwo den Schaltplan für den Außensensor (für den Innensensor wäre dieser auch nicht schlecht, da ich vermutlich auch schon eine Anwendung gefunden habe ;))?
Ja, der Schaltplan der aktuellen Version ist hier: http://forum.fhem.de/index.php/topic,20620.msg144693.html#msg144693
der für den erweiterten Sensor hier: http://forum.fhem.de/index.php/topic,20620.msg147709.html#msg147709
ZitatDa ihr vermutlich das Homematic Protokoll implementieren werdet, ich aber vermutlich eher das vorhandene FS20 nutzen würde, gäbe es aus meiner Sicht zwei Möglichkeiten:
- getrennte Firmware
- Auswahl des Protokolls (HomeMatic, FS20) per Taster (beim Einschalten des Gerätes gedrückt halten) und signalisieren per LED (sollte dann auch vorhanden sein 8)).
Was meint ihr dazu?
Es wird hier wohl auf getrennte Firmware hinaus laufen. Aber, wie oben beschrieben, geht der Update und somit auch der Austausch der Firmware recht einfach.
Der Sensor kann grundsätrzlich mit einem 868Mhz oder 433Mhz-Funkmodul bestückt werden.
Alternativ kann das neue Layout auch mit einem RS485 Transceiver bestückt werden.
Somit sind mit passender Software eine Vielzahl von möglichen Protokollen denkbar.
Zitat von: santalaus am 23 März 2014, 14:32:56
Ich habe versucht es nochmal nachzuvollziehen, gab es schon eine Entwicklung Richtung PIR?
Derzeit könnte so ein Modul über die Pinreihen, wo alle wichtigen Signale nach außen geführt sind, aufgesteckt werden.
ZitatIch habe bei Alibaba welche gefunden, die fast ohne externe Schaltung auskommen und auch nur via Widerstand im Schaltausgangsdelay einzustellen ist.
Achte darauf, dass das Modul mit 3,3V betrieben werden kann und, falls Batteriebetrieben einen niedrigen Stromverbrauch hat.
Zitat von: PeMue am 23 März 2014, 16:49:24
Geht eigentlich der Sensor dann mit dem HM-USB Stick?
das sollte funktionieren. Und wenn alles klappt, sollte der komplette Sensor auch mit der CCU funktionieren.
Temperatur und Fechhte gehen jetzt schon, auch mit der CCU.
Anbei noch ein Paar aktuelle Bilder:
Fertiger Sensor, mit Temperatur/Feuchte, Luftdruck, Helligkeit. Der Max1724 ist hier nicht bestückt.
Im Gehäuse seht ihr auch ein Loch mit dem Acrylstab als Lichtleiter für den Helligkeitssensor. Das Funktioniert ganz gut. Natürlich gibt es dadurch eine Dämpfung die man bei der Auswertung berücksichtigen muss. Aktuell hat der Acrylstab einen Durchmesser von 3mm. Ich finde das das aber etwas knapp ist. Um die 4-5mm währ aus meiner Sicht besser. Dann ist die Dämpfung auch geringer.
Vom Programmieradapter habe ich auch noch ein paar hier liegen falls den noch jemand braucht.
Das ist ein FTDI-Chip Drauf. Daher sollter auch unter Linux/MacOS funktionieren.
Der Adapter ist mit einem SMD-Jumper bei auslieferung auf 5V eingestellt. Wir brauchen aber 3,3V. Mit einer kleinen Lötbrücke und vorherigen trennen der voreingestellten Brücke lässt sich dieser auf 3,3V umstellen. Falls ich das schon umlöten soll, bite bescheid sagen.
Viele Grüße
Dirk
(http://hfma.de/images/FHEM/Sensor-fertig_mit_Loch_fuer_Helligkeissensor.jpg)
(http://hfma.de/images/FHEM/Gehaeuse_innen.jpg)
(http://hfma.de/images/FHEM/Programmieradapter.jpg)
Hallo Dirk,
Ich bin wie immer sprachlos über die Qualität deiner Arbeit!
Wenn du eine weitere Charge auflegst so denke bitte an die zwei Aussen Sensoren für mich.
LG
Franz
hallo dirk,
was möchtest du für den programmieradapter?
gruss
andre
Schließe mich an meinem Vorschreiber an! Bin auch an einem Innen und Aussensensor interessiert.
Zitat von: justme1968 am 23 März 2014, 19:23:39
was möchtest du für den programmieradapter?
5€ + Versand.
Ich denke 1€ Für Marke + kleiner Polsterumschlag sollte da reichen.
Zitat von: P.A.Trick am 23 März 2014, 19:24:13
Schließe mich an meinem Vorschreiber an! Bin auch an einem Innen und Aussensensor interessiert.
Hab dich auf die Liste gesetzt. Oder möchtest du schon einen Sensor aus der Prototypen-Reihe?
Gruß
Dirk
Zitat von: Dirk am 23 März 2014, 20:58:25
5€ + Versand.
Ich denke 1€ Für Marke + kleiner Polsterumschlag sollte da reichen.
Hab dich auf die Liste gesetzt. Oder möchtest du schon einen Sensor aus der Prototypen-Reihe?
Gruß
Dirk
Ich warte gerne bis die nächste Charge ansteht.
Hallo,
was mir grade beim betrachten aufgefallen ist. Wäre es möglich den Helligkeitssensor zu verschieben?
Statt mittig nach rechts oder links?
Ich denke ansonsten wird das mit der Zusatzplatine noch schwieriger, da ja der Plexiglasstab im Weg ist.
Nico
Zitat von: santalaus am 23 März 2014, 22:57:05
Wäre es möglich den Helligkeitssensor zu verschieben? Statt mittig nach rechts oder links?
Der Helligkeitssensor liegt in der Mitte, da es dann wohl besser aussieht.
Man könnte diesen noch etwas nach rechts schieben. ggf. auch als alternative Bestückungsvariante.
Ansonsten könnte man auf der Zusatzplatine auch ein Loch für den Acrylstab vorsehen.
Anbei mal ein Bild wie es aussehen würde den Lichtsensor rechts zu plazieren.
Was meint Ihr?
Gruß
Dirk
Zitat von: Dirk am 15 März 2014, 00:02:43
Ein Separater Temperatur / Feuchtesensor ist auf der Platine nicht geplant, da man im Gehäuse wohl keine Sinnvollen Temperaturwerte ermitteln kann.
Der I2C-Bus ist aber auf eine Steckerleiste geführt, so dass man einen externen Sensor anschließen könnte.
Hallo Dirk,
Ich hätte einige Fragen zum Außensensor:
- wäre es am Außensensor möglich mehr als einen Temperatursensor anzuschließen? Es gäbe den Anwendungsfall das dieser Sensor am Dach auch für eine Solar Anlagen Pumpensteuerung verwendet werden könnte.
- Wäre es Möglich einen Laderegler auf der Platine unterzubringen oder in einer Erweiterungsplatine?
- Wie groß / Stark müsste eine Photovoltaik Solarzelle sein damit der Sensor mit einem Akku Funktionieren würde? Ist dann hier ein Step Up Wandler sinnvoll?
Vielen Dank für deine Antowrt im Voraus!
LG
Franz
Hallo Dirk,
Ich hätte gerne 4 unbestückte Platinen und 4 Gehäuse für den Innensensor. Ist das möglich? Lieferzeit spielt keine Rolle.
Gruß und Danke Robbi
@franz74
prinzipiell würden mehrere Temperatursensoren gehen, allerdings ist der SHT10 kein I2C Device.
Das heisst, er besitzt keine eigene Adresse. Du bräuchtest pro Sensor 2 Port Pins vom Arduino.
Wenn es dir nur um Temperaturmessung geht, könnte man einen Sketch auf Basis des 18D21 bauen,
hier würde man mehrere Temperatur über einen 1 Wire Bus betreiben.
Stromverbrauch vom aktuellen Sensor ist relativ niedrig. Die meisste Zeit schläft der Sensor und braucht um die 60 uA. Wenn die
Sensoren gelesen werden und das Ding sendet, dann braucht es um die 30mA, für etwa 200 ms
Viele Grüße
Horst
Hallo Horst,
Wow wenn du 1-Wire anbinden könntest das wäre Genial!
Es gibt doch 16Kanal Geräte in HM und wenn du da eine 16 Port RF 1-Wire Firmware machen könntest wäre das sicher für viele eine Perfekte Lösung ihre Heizungs Temperaturen zu erfassen zumal ein 1-Wire Sensor in einer Tauch Hülse mit 90cm Kabel EUR 3,50 inkl. Versand kostet...
LG
Franz
Zitat von: Franz74 am 24 März 2014, 20:10:41
... zumal ein 1-Wire Sensor in einer Tauch Hülse mit 90cm Kabel EUR 3,50 inkl. Versand kostet...
viel zu teuer ;)
Hier: http://www.ebay.de/itm/230985068853?_trksid=p2055120.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT
Da es ganz einfach ist, auf einem Arduino einen 1-Wire Master zu implementieren, wäre ich eigentlich nur an den cc1101-Subplatinen und der entsprechenden library interessiert. Wie am Samstag schon mtgeteilt ...
LG
pah
Zitat von: Franz74 am 24 März 2014, 09:23:04
Ist dann hier ein Step Up Wandler sinnvoll?
Auf der Platine ist ein Max1724 vorgesehen.
Das ist ein DC-DC Converter der aus 0,8 bis 3,3V, 3,3V am Ausgang liefert.
Der Laderegler müsste Wohl auf eine Zusatzplatine.
Zitat von: Prof. Dr. Peter Henning am 24 März 2014, 21:30:43
... wäre ich eigentlich nur an den cc1101-Subplatinen und der entsprechenden library interessiert. Wie am Samstag schon mtgeteilt ...
Wieviel brauchst du denn?
Gruß
Dirk
Hej Dirk,
nicht mal Ansatzweise würde man vermuten, dass es sich hier um ein Bastelprojekt handelt... Großartige Arbeit! :-)
Primär brauche ich (für alle Platinen) Temperatur und Feuchtigkeit. Helligkeit wird auch zunehmend interessanter. Und CO2 glaub ich, wäre jetzt nur per Zusatzplatine?
5x für innen und 1x für außen. Wenn du meinst, dass man das Innengehäuse auch für den Außeneinsatz verwenden kann, dann würde ich das nehmen. Regen ist kein Thema.
Mit SMD löten würde ich mir recht schwer tun. Alles andere sollte ich schaffen.
Die Sache mit den 1wire-Sensoren hat meine Aufmerksamkeit jetzt allerdings auch noch zusätzlich erregt. Ich verwende draußen Vegetronix-Feuchtigkeitsmesser und zur Zeit läuft dafür eigens ein RPi um die Daten auszulesen. Wenn sich da was machen lässt, wäre das natürlich noch ein zusätzliches Like. :-)
Und Programmieradapter würde ich demnach auch einen benötigen, solange die Platinen nicht OTA flashbar sind.
Eilig hab ich es nicht... ganz im Gegenteil, da keine Zeit. Kann daher gerne noch warten.
Edit: Achja... wie ist das mit dem Max1724? Dient er "nur" um gleichmäßiger Strom zu liefern oder würde sich dadurch ggf. auch die Batterielaufzeit in irgendeine Richtung verändern?
Zitat von: Mr. P am 25 März 2014, 12:57:52
wie ist das mit dem Max1724? Dient er "nur" um gleichmäßiger Strom zu liefern oder würde sich dadurch ggf. auch die Batterielaufzeit in irgendeine Richtung verändern?
Damit hat man eine stabile Versorgung mit 3,3V und zwar ab 0,8V Eingangsspannung. Durch eine bessere Ausnutzung der Batterien verlängert sich die Gesamtlaufzeit. Trotz des Eigenverbrauchs von MAX1724. Dieser ist auch recht gering.
Hallo Dirk, Trilu,
@Außensensor
könnte dieser nicht in eine Solar LED Gartenlampen Gehäuse verbaut werden? Die Helligkeit könnte doch auch über die Spannung der Solarzelle detektiert und an die CCU Übermittelt werden oder?
@1-Wire
Wenn dieser als Busmaster für 1 Wire Temperatur / Luftfeuchte / Counter Module verwendet werden könnte wäre das echt der hit und würde quasi eine 1- Wire Integration in Homematic per Funk ermöglichen!
Anwendungsfälle:
- Garten / Pool (Temperatur / Luftfeuchte)
- Warmwasser Solar (Temperatur)
- Heizung (Puffer / Boiler / Kessel (Temperatur)
- Strom / Wasser Zähler mit S0 Ausgang an 1-Wire counter (Zähler)
Und vieles Mehr!
Die einzige Frage ist wie diese "Kanäle" dann in der CCU dargestellt werden bzw. ob diese dann über die Geräteeinstellungen in der CCU so Konfiguriert werden können das z.B. pro Kanale ausgewählt werden kann ob ein Temperatur / Luftfeuchte / Counter Modul mit welcher ID dahinter steht?
Also ich denke das hier dann auch ein CCU Firmware Update mit dem neuen "Gerät" nötig sein wird damit dieses Modul für alle einfach Nutzbar ist oder was meint ihr?
LG
Franz
Zitat von: Mr. P am 25 März 2014, 12:57:52
Und CO2 glaub ich, wäre jetzt nur per Zusatzplatine?
Ja, Vermutlich brauchst du auch eine externe Spannungsversorgung, da die Gassensoren in der Regel eine Heizung haben.
Die ist externe Versorgung in der nächsten Platinenversion mit vorgesehen.
ZitatWenn du meinst, dass man das Innengehäuse auch für den Außeneinsatz verwenden kann, dann würde ich das nehmen. Regen ist kein Thema.
Ich meine das das gehen sollte.
ZitatDie Sache mit den 1wire-Sensoren hat meine Aufmerksamkeit jetzt allerdings auch noch zusätzlich erregt. Ich verwende draußen Vegetronix-Feuchtigkeitsmesser und zur Zeit läuft dafür eigens ein RPi um die Daten auszulesen. Wenn sich da was machen lässt, wäre das natürlich noch ein zusätzliches Like. :-)
So wie ich das sehe, müsste in der Firmware "nur" einen One-Wire Master implementieren. eine Parasitäre Spannungsversorgung der Nodes währ dann aber noch nicht gewährleistet.
Aber man kann die Platine später ja weiterentwickeln.
ZitatUnd Programmieradapter würde ich demnach auch einen benötigen, solange die Platinen nicht OTA flashbar sind.
Mit dem Atmega328p als Controller aktuell wird OTA wohl nichts werden, da dieser nur 2KB Bootloader hat.
ZitatEilig hab ich es nicht... ganz im Gegenteil, da keine Zeit. Kann daher gerne noch warten.
Zeit braucht es sicher noch etwas. Jetzt sind erstmal die ersten Prototypen fertig die diese Tage an die ersten Interessenten gehen.
Die 2. Revision der Platine will ich Anfang nächster Woche fertigen lassen.
Wenn es dann keine größeren Änderungen mehr gibt, werde ich dann auch mehr Platinen ordern.
ZitatEdit: Achja... wie ist das mit dem Max1724? Dient er "nur" um gleichmäßiger Strom zu liefern oder würde sich dadurch ggf. auch die Batterielaufzeit in irgendeine Richtung verändern?
Sowohl als auch. Die Sensoren auf der aktuellen Platine brauchen mindestens 2,7V Die Batterien liefern 3V. Die Entladekurve der Batterien ist aber nicht so sehr flach, so dass die 2,7V schon ach etwa 1/3 Batteriekapazität erreicht sind. Bis zu diesem Punkt dauert es Schätzungsweise aber auch über einem Jahr, so dass der MAX1724 hier nicht unbeding nötig währ. Mit Max können die Batterien bis auf ca. 0,8V "leergesaugt" werden. Der Max liefert dabei eine kontinuierliche Ausgangsspannung von 3,3V.
Damit lassen sich also die Batterien besser ausnutzen, damit auch die Lauftzeit deutlich verlängern. Zusätzlich kann man dann auch Sensoren anschließen welche erst ab 3 bzw. 3,3V funktionieren.
Zitat von: Franz74 am 25 März 2014, 13:16:06
@Außensensor
könnte dieser nicht in eine Solar LED Gartenlampen Gehäuse verbaut werden? Die Helligkeit könnte doch auch über die Spannung der Solarzelle detektiert und an die CCU Übermittelt werden oder?
Das ginge auch. Müsste man mal sehen wie die Helligkeits/Spannungskurve währ.
ZitatWenn dieser als Busmaster für 1 Wire Temperatur / Luftfeuchte / Counter Module verwendet werden könnte wäre das echt der hit und würde quasi eine 1- Wire Integration in Homematic per Funk ermöglichen!
Klar. Ich denke hier kommen bestimmt noch weitere Ideen.
ZitatDie einzige Frage ist wie diese "Kanäle" dann in der CCU dargestellt werden bzw. ob diese dann über die Geräteeinstellungen in der CCU so Konfiguriert werden können das z.B. pro Kanale ausgewählt werden kann ob ein Temperatur / Luftfeuchte / Counter Modul mit welcher ID dahinter steht?
Für solche Sachen müsste man eigene Devices für die CCU erstellen. Mit dem aktuellem Sensor werde ich das auch schon machen. Damit man Luftdruck und Helligkeit auch in der CCU zur Anzeige bekommt.
ZitatAlso ich denke das hier dann auch ein CCU Firmware Update mit dem neuen "Gerät" nötig sein wird damit dieses Modul für alle einfach Nutzbar ist oder was meint ihr?
So ist es.
Gruß
Dirk
Ich bin schon gespannt auf die Sensoren......
auf jeden Fall habt ihr hier ein Megageiles Projekt am laufen!!! Respekt an alle Beteiligten!!
Hallo,
ich habe die PIR Sensoren hier aus dem Thread mal bestellt und probiere das.
Ich finde die Einstellung mit Potis auch nicht so schlimm. Macht man ja einmalig.
Auf der Zusatzplatine habe ich vor zudem 1wire und Schalt-Eingänge vorzusehen.
Die Schalteingänge wollte ich auf noch freie Interruptable Eingänge legen. Mal sehe was da machbar/frei ist.
Bei 1wire ist das bei mir als zusätzliche Temperatursensoren vorgesehen.
Ich habe mal ins Datenblatt geschaut der Sensor braucht im Idle auch nur µA und soll ab 3V laufen.
Hat bzgl der Spannung hier schon jemand Erfahrung? Ich dachte immer 1wire braucht 5V.
Wenn ich den PIR habe und einen Sensor dann schaue ich mal ob das irgenwie noch in dem Gehäuse machbar ist.
Nico
Darf ich mir was wünschen?
Der Thread ist jetzt 15 Seiten lang. Und wenn man nicht von Anfang an alles Beitrag für Beitrag mitverfolgt hat, ist es sehr schwer, den aktuellen Stand zu ermitteln.
Könnte irgendjemand mal in ein paar wenigen Sätzen zusammenfassen, was jetzt der aktuelle Entwicklungsstand ist? Ich hab den Thread jetzt dreimal durchforstet, aber bin nicht wirklich schlaugeworden.
Oder ich formuliere einfach mal, was ich eigentlich suche: Einen Luftdrucksensor, der Homematic spricht. So wie es der Titel des Threads verspricht :)
Hallo,
WIMRE schrieb Dirk, die Testsensoren sind zu Testern unterwegs und er will noch am Platinenlayout feilschen.
Ist das durch, dann geht es wohl in die weitere Runde.
Nico
Zitat von: betateilchen am 26 März 2014, 18:48:38
Der Thread ist jetzt 15 Seiten lang. Und wenn man nicht von Anfang an alles Beitrag für Beitrag mitverfolgt hat, ist es sehr schwer, den aktuellen Stand zu ermitteln.
Da geb ich dir recht.
Das sollten wir mal ändern. Würde ich aber gerne erst nach dem neuen Layout machen.
ZitatOder ich formuliere einfach mal, was ich eigentlich suche: Einen Luftdrucksensor, der Homematic spricht. So wie es der Titel des Threads verspricht :)
Genau das macht der.
Wenn du nur Luftdruck brauchst, kann ich dir einen Aussensensor schicken.
Von dem gibt es noch Platinen. Hier wird sich das Layout wohl auch nicht mehr ändern.
Gruß
Dirk
Na dann schick mal die Kostennote per email :) Meine Adresse hast Du noch?
Hallo Dirk,
Hut ab , wieder eine super arbeit von Dir.!
habe mich gerade durch die 15 Seiten gekämpft ;) Interssant aber auch anstrengend , Betateilchen hat schon Recht!
Gute wäre eine Zusammenfassung!
Wie ist die aktuelle Bestellmöglichkeit / Verfügbarkeit
würde 1 x Indoor-komplett (gehäuse,batteriehalter,platine,atmega,max,T, Feuchte,druck, Helligkeit, (+ PIR ???))
starten ... sicher später mehr.
klaus
Hallo Klaus,
Zitathabe mich gerade durch die 15 Seiten gekämpft ;) Interssant aber auch anstrengend , Betateilchen hat schon Recht!
Gute wäre eine Zusammenfassung!
Ich werde das die Tage wohl mal im Wiki zusammenfassen.
Ggf. macht es auch Sinn für die reine Hardware ein eigenen Tread auf zu machen.
Weil die Sensoren ja nicht nur Homematic sprechen können.
ZitatWie ist die aktuelle Bestellmöglichkeit / Verfügbarkeit
Noch nicht so gut, weil noch Prototypenstatus.
Platinen für Außensensoren sind noch ein paar da.
Ich hab dich also erstmal auf die Liste gesetzt.
Gruß
Dirk
mir geht das ähnlich, habe mehrere Firefox Tabs offen um den Überblick zu behalten, weil die wichtigen Details etwas verteilt sind.
Wenn das alles noch Prototypen Status hat kann ich ja warten.... Ich weiß jetzt auch nicht genau was sich noch ändert und habe u.a. gesehen das mit PIR von einigen Usern geordert wird. Aber das gibt es doch soweit ich es gelesen habe noch gar nicht..?!
Ansonsten ist dies ein tolles Projekt und die Qualität macht auf den Bildern einen super Eindruck, ganz toll mein Respekt ;)
Hallo Zusammen,
mir ist heute, nachdem ich zum wiederholten Mal den DHL Mann nicht klingeln gehört habe eine Idee gekommen.
Könnte man nicht auch einen kleinen Blitz und einen kleinen Lautsprecher mit drauf packen? So wie vom Handy eine LED Blitz / Leuchte.
Signalgeber: http://www.conrad.de/ce/de/product/710132/Piezo-Signalgeber-RMP-Serie-mit-integrierte-Elektronik-Geraeusch-Entwicklung-85-dB-3-24-VDC-4100-Hz-Inhalt-1-St/?ref=detview1&rt=detview1&rb=1
LED: http://www.conrad.de/ce/de/product/176724/LED-bedrahtet-Weiss-Rund-5-mm-10000-mcd-20-20-mA-32-V-LED-5-10000W/?ref=category&rt=category&rb=1
Der könnte dann blinken und tuten, wenn jemand an der Tür klingelt. Oder das Telefon klingelt. HM Anbindung vorausgesetzt. Oder wenn eine andere Wichtige Information signalisiert werden soll.
In Verbindung mit dem Bewegungsmelder automatisch in dem Raum in dem Bewegung registriert wird.
Ich bin an ein paar Sensoren mit Bewegungsmelder interessiert. Temperatur ist nicht so wichtig, da ich sowieso HM Thermostate in den Räumen habe.
Wenn die dann noch blinken und tuten könnten (ähnlich Rauchmelder nur nicht so laut) wäre das spitze!
Das Blitzen und Tuten könnte man auch noch für eine Alarmanlage nutzen.
Für Schwerhörige ist das auch spitze.
Bei Stromausfall evtl. Notbeleuchtung...
Fraglich wäre dann auch, wie lange die Batterie hält, bzw. wie groß diese ausfallen muss.
Wie groß ist denn aktuell die Platine? Ich habe Abgehängte Decken, bzw. Holzbalkendecken. Da würde ich einfach eine Dose setzen und alles reinstecken und nur den BM , LED und mini Lutsprecher durch eine Blende gucken lassen.
Dann hab ich keine hässlichen Kästen an der Decke.
Macht so eine Anwendung Sinn?
Hallo,
kennst du den MP3 Funk Gong*? Der kann Blinken und auch mp3 Files abspielen...
LG
Franz
* Es kommt jetzt ganz neu ein neuer MP3 Funk Gong nur als Platine mit besserem Verstärker und ohne gehäuse...
Ja, kenn ich...
Aus folgenden Gründen habe ich mich dagegen entschieden:
- Hässlich
- zu groß
- braucht eine Steckdose (hab ich nicht an der Decke)
- zu teuer
Evtl ist das neue Bauteil ja zu gebrauchen. Wobei mir ein Gerät mienau den Funktionen, die ich brauche am besten gefallen würde.
Wenn da Buzzler und Blitzer drauf kommen, dann möchte ich auch einen Fluxkompensator haben ;)
Aber ganz ehrlich, ich finde dass dieses Gerät weder 'tuten' noch 'blitzen' können soll. Es ist zu einem ganz anderen Zweck konzipiert werden (ein Sensor, kein Aktor).
Wenn für das andere genug Interessenten gibt, könnte jemand auf dieser Basis ein weiteres Gerät entwickeln. Oder man baut eine Erweiterungsplatiene für dieses Gerät. Oder man entwickelt eine Minimalversion (ein Breakoutboard), wo jeder anklemen kann, was er will.
Ich finde jedoch, man sollte zunächst das aktuelle Entwicklung produktionsreif bekommen.
... meine fünf Cent...
Finde ich auch!
Lassen wir unser Helden mal die erste Runde gewinnen (Prototyp) auf das noch einige siegreiche folgen werden!
LG
Franz
Zitat von: hexenmeister am 28 März 2014, 10:14:39
Oder man baut eine Erweiterungsplatiene für dieses Gerät.
Genau das ist der Sinn der Erweiterungsplatine. Die Pinbelegung geht aus dem Schaltplan dazu hervor. Somit kann den Sensor jeder selber erweitern. Auch wenn es am Schluss keine Sensor, sondern ein Blitzdings wird.
Ich habe hier übrigens schon ein paar Platinen für ein Breakout-Board mit AVR/Arduino + CC1101 und kleinem Feld von Lochrasterpads hier liegen. Damit könnte jeder eigene Experimente machen.
Gruß
Dirk
ich finde auch soviel wie ich hier schon mitgelesen habe, wenn das Ding alles macht was hier geschrieben wurde ist das absolut Super...
aber da kommt mir ein weiterer Einfall evtl. für die Zukunft, mal ein Platine für eine schaltbare Steckdose auf Homematic Basis zu bauen, denn davon könnte man heute genug einsetzen und die sind teuer, ich scheue mich immer noch welche zu kaufen und mache das mit meinen herkömmlichen Fernbedienungen, würde aber gerne alles auf Homematic Basis machen.
Einfach eine Sorte kaufen und eben eine selbst erstellte kleine Platine einsetzen..!
Hallo,
der Sensor ist da. Superarbeit Dirk. Vielen Dank, jetzt weiss ich was Du bzgl. des Airpress Sensors meintest. Den zu löten Respekt.
Ich hoffe das die PIRs nun aus China schnell kommen. Dann schaue ich mal wie das umzusetzen ist.
Bzgl der schaltbaren Steckdosen: das ist immer schwierig, da man einen zuverlässigen Lieferanten für die Gehäuse braucht. alles was ich da bisher gefunden hatte war einfach das es sich in Summe nicht rechnete.
Aber ich plane eine Schalter/PWM Platine zu machen. Die ich an mehreren Stellen brauchen werde. Plan sind 8 Ausgänge SolidState oder Relais.
und 16 PWM Kanäle für 3* LED Leisten. optional kommen dann noch PIR als Eingänge dran.
Nico
Zitat von: santalaus am 28 März 2014, 16:59:45
Aber ich plane eine Schalter/PWM Platine zu machen. Die ich an mehreren Stellen brauchen werde. Plan sind 8 Ausgänge SolidState oder Relais.
und 16 PWM Kanäle für 3* LED Leisten. optional kommen dann noch PIR als Eingänge dran.
Da können wir uns zusammentun.
In die Richtung liegt hier auch schon was in der Schublade.
Hier mal die gepatchte CUL_HM, damit auch die Helligkeit in FHEM angezeigt wird.
Gruß
Dirk
Zitat von: Dirk am 28 März 2014, 18:00:59
Hier mal die gepatchte CUL_HM, damit auch die Helligkeit in FHEM angezeigt wird.
Mal ne dumme Frage: wie kalibriert ihr die Helligkeit?Wäre mal ganz interessant zu wissen. Habe mich am Samstag mit pah unterhalten und er hat mir auch einen Tipp gegeben, was ich in der Dokumentation verwerten werde.
Gruß Peter
Zitatwie kalibriert ihr die Helligkeit?
Der Sensor gibt die Helligkeit in Lux wieder. Aber nur, wenn er direkt angestrahlt wird.
Aber erst seit vorhin :).
Bin noch am feilen an der Firmware.
Mit Lichtleiter muss ein Korrekturfaktor eingerechnet werden. Das sollte aber erstmal in FHEM passieren und müsste aktuell experimentell ermittelt werden.
Der Sensor hat zwei Photodioden.
Eine für Visible und Infrarot, eine für nur Infrarot. Aus beiden wird dann die Lichstärke in Lux berechnet.
So steht es zumindest im Datenblatt.
Ich werte immer auf schönes Wetter, um auch mal in der Sonne zu testen.
ZitatHabe mich am Samstag mit pah unterhalten und er hat mir auch einen Tipp gegeben
Was für ein Tip?
Gruß
Dirk
Meiner ist auch angekommen, vielen Dank!
Sieht sehr professionel aus!
(http://s6z.de/cms/images/content/arduino/HM/HM_WDS10_TH_O_01_k.jpg)
Funktioniert genau wie beschrieben: zieht ca. 260µA, sendet beim ersten Mal falsche Daten, mit den HM-Patch liefert auch die Lux-Werte.
Die Werte (T und H) liegen nah am denen meiner anderen Sensoren (HM-TC-IT-WM-W-EU und Selbstbau mit DHT22).
Readings:
2014-03-28 21:05:04 Activity alive
2014-03-28 15:40:44 CommandAccepted yes
2014-03-28 21:05:04 D-firmware 0.1
2014-03-28 21:05:04 D-serialNr TLU0001002
2014-03-28 15:40:44 PairedTo 0x416C78
2014-03-28 15:40:44 R-burstRx off
2014-03-28 15:40:44 R-pairCentral 0x416C78
2014-03-28 15:40:44 RegL_00: 01:00 02:01 0A:41 0B:6C 0C:78 00:00
2014-03-28 21:40:52 airpress 1018
2014-03-28 21:40:52 battery ok
2014-03-28 21:40:52 humidity 45
2014-03-28 21:40:52 lux 3.63
2014-03-28 15:40:43 sabotageAttack ErrIoAttack cnt:1
2014-03-28 21:40:52 state T: 23.2 H: 45 AP: 1018 Lux: 3.63
2014-03-28 21:40:52 temperature 23.2
Woher kommt eig. "sabotageAttack ErrIoAttack cnt:1"?
Bin auf die nächste Firmwareversion gespannt ;)
Zitat von: hexenmeister am 28 März 2014, 22:01:29
Woher kommt eig. "sabotageAttack ErrIoAttack cnt:1"?
Das kommt aus 10_CUL_HM solange ein Sensor nicht korrekt oder mit einer anderen Zentrale (genauer: deren ID) gepairt ist.
Zitat von: hexenmeister am 28 März 2014, 22:01:29
Bin auf die nächste Firmwareversion gespannt ;)
Version 0.2 ist hier im Anhang :)
Stromverbrauch ist jetzt nur noch, wie geplant mit MAX ~30 µA
Alle ca. 2,5 Min. während der Sensor sendet, verbraucht mit er MAX ca. 45 mA, aber nur für ca. 0,1 Sek.
Die LED sollte noch während des Sendens abgeschaltet werden, dann sind es noch ein paar mA weniger.
Angenommen die AA-Zellen haben 2500 mAh gespeichert wenn sie voll sind, dann sollte ein Satz Batterien mit aktivierten Helligkeitssensor (dieser braucht die höchste Minimalspannung) laut meiner Rechnung ca. 54 Monate, also etwa 4,5 Jahre durchhalten.
Ich habe hier mit 60 µA Standby und 80 mA Sendeverbrauch gerechnet, da mit sinkender Batteriespannung der Stromverbrauch durch den MAX mit der Zeit ansteigt.
Beim Sensor ohne Max habe ich einen Stromverbrauch von ~25µA im Standby gemessen und ~25 mA beim Senden.
Nach meiner Rechnung, und der Annahme dass man aus den Batterien bis zur Spannung von 2,7V nur etwa 500 mAh entnehmen kann, komme ich hier immer noch auf eine Batterielaufzeit von ~26 Monaten. Also ca. 2,2 Jahre
Gruß
Dirk
Update:Bitte nach dem Firmwareupdate den Sensor neu anlernen.
Die Seriennummer hat sich geändert.
Der Sensor sendet jetzt übrigens auch mit dem ersten Datenpaket die richtigen Werte.
Geflasht werden kann das Ganze mit AVRdude mit folgender Befehlszeile:
/path/to/avrdude -C/path/to/arduino-ide/hardware/tools/avr/etc/avrdude.conf -patmega328p -carduino -P COM1 -b57600 -D -Uflash:w:/path/to/WetterSensor.hex:i
Update2:Ich hab mich um eine Kommastelle vertan. Aber an 2 Stellen. Das gleicht es wieder aus :). Ich hoffe die Rechnung stimmt diesmal.
Ohne Max, sind es "nur" ca. 26 Monate (2,2 Jahre), Mit Max ca. 54 Monate (4,5 Jahre) Batterielaufzeit.
Ich werde die Tage vielleicht mal bei einem Sensor auch die Batteriespannung mit übertragen lassen. Dann wissen wir in 2 bzw. 4 Jahren wie es sich in der Praxis verhält :).
Hi Dirk
Hoffe du bist Samstag noch gut zu deinem Hotel gekommen.
Hätte auch Interesse an deinem Wunderwerk. Würde erstmal zwei mit Temperatur und Luftfeuchtigkeit nehmen. Eine Version mit Bewegungsmelder wären super. Schließe mich da meinen diversen Vorrednern an.
Ciao
Martin
ZitatVersion 0.2 ist hier im Anhang :)
Sehr schön, werde morgen versuchen :)
Bei den USB-UART-Dingern kann man durch Lötbrücken zw. 3,3 und 5V umschalten. Wenn ich das Board mit Batterien speise und nur GND, RESET, TX und RX anschliesse, dann dürfte diese Einstellung doch ohne Bedeutung sein, oder?
Grüße,
Alexander
Zitat von: hexenmeister am 29 März 2014, 02:22:23
Bei den USB-UART-Dingern kann man durch Lötbrücken zw. 3,3 und 5V umschalten. Wenn ich das Board mit Batterien speise und nur GND, RESET, TX und RX anschliesse, dann dürfte diese Einstellung doch ohne Bedeutung sein, oder?
Nein, denn TX und Reset haben dann auch 5V Pegel.
Die IC's mögen es nicht, wenn an den Eingängen Spannungen über der Versorgungsspannung anliegt. Auch wenn die AVR's hier recht tolerant sind. Dennoch: besser die Lötbrücke auf 3,3V Umschalten. Umgekehrt ist das nicht Problematisch.
Alternativ kann man in die TX- und Reset-Leitung (vom USB-UART-Adapter aus gesehen) auch einen Spannungsteiler mit 2 Widerständen bauen.
Gruß
Dirk
Danke für die Erklärung, werde morgen einen von meinen Adapter umbauen.
Gute Nacht!
Moin!
Irgendwie komme ich mit dem Flashen nicht weiter. Die Verbindung ist richtig, USB-UART ist ein FTDI... Port stimmmt auch. MC bekommt Reset, es blinkt paar mal TX an dem Adapter, dann paar Mal RX, dann bootet die Platiene wieder...
Über Serial macht die Platiene keine (Debug-)Ausgaben, oder?
U:\WetterSensor>D:\Arduino\arduino-1.5.6-r2\hardware\tools\avr\bin\avrdude -C D:\Arduino\arduino-1.5.6-r2\hardware\tools\avr\etc\avrdude.conf -p atmega328p -c arduino -P COM15 -b 57600 -D -Uflash:w:WetterSensor.hex:i -v
avrdude: Version 5.11, compiled on Sep 2 2011 at 19:38:36
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "D:\Arduino\arduino-1.5.6-r2\hardware\tools\avr\etc\avrdude.conf"
Using Port : COM15
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude done. Thank you.
Was könnte ich übersehen haben?
Grüße,
Alexander
ZitatIrgendwie komme ich mit dem Flashen nicht weiter. Die Verbindung ist richtig, USB-UART ist ein FTDI... Port stimmmt auch. MC bekommt Reset, es blinkt paar mal TX an dem Adapter, dann paar Mal RX, dann bootet die Platiene wieder...
vertausche mal TX und RX.
Die Anschlussbelegung sieht so aus:
Sensor USB-UART
TX RX
RX TX
Reset DTR
GND GND
Hi Martin,
Zitat von: martinschm am 29 März 2014, 00:12:20
Hätte auch Interesse an deinem Wunderwerk. Würde erstmal zwei mit Temperatur und Luftfeuchtigkeit nehmen.
Ich nehme an den Innensensor?
Ich hab dich mit auf die Liste gesetzt.
Gruß
Dirk
Hallo Dirk,
Hast du noch zwei Aussensensoren?
Lufttruck, Temperatur, Luftfeuchte und Helligkeit waren gewünscht.
LG
Franz
Hallo Dirk,
danke für die Antwort, das habe ich aber auch schon versucht ;)
Aus meiner Sicht ist eben alles richtig angeschlossen. :(
Ich probiere mal die Datei so an einen Arduino Pro Mini zu fläshen, testweise.
Zitat von: Franz74 am 29 März 2014, 11:51:01
Hast du noch zwei Aussensensoren?
Lufttruck, Temperatur, Luftfeuchte und Helligkeit waren gewünscht.
Aktuell hab ich für die Außengehäuse nur Helligkeit und Luftdruck (Temperatur). Könnte ich dir schicken.
Breakout-Boards für die SHT10-Sensoren zum externen Anschluss an den externen Bus vom Außensensor sind in Vorbereitung.
Gruß
Dirk
Zitat von: hexenmeister am 29 März 2014, 11:52:51
danke für die Antwort, das habe ich aber auch schon versucht ;)
Aus meiner Sicht ist eben alles richtig angeschlossen. :(
Bei Einsetzen der Batterie sollte die LED auf dem Board zwei mal kurz blinken. Das ist der Zeichen das das Bootloader aktiv ist.
Es könnte sein, dass das Board bei dir nicht geresettet wird. Dann kannst du versuchen die Batterie rauszunehmen und direkt nach dem Start von AVRdude wieder einzusetzen.
Hi Dirk,
ja richtig, bräuchte Innensensoren.
Danke
Martin
Habe neue Version eingespielt. Danke für die Unterstützung!
Und wo lag denn mein Problem? Verkabelung war richtig, Pfade waren richtig, AVRDude-Aufruf war auch richtig... Aber der FTDI-Adapter war hin. Sehr merkwürdig, es wird erkannt, die LEDs blinken, es passiert aber nichts.
Gut, wenn man mehrere solche Dinger liegen hat ;)
Edit: habe jetzt Stromverbrauch von unter 30µA gemessen (mein Multimeter 'schwankt' wz. 18 und 26µA)! Sehr cool! :D
Zitat von: Dirk am 28 März 2014, 21:29:30
Der Sensor gibt die Helligkeit in Lux wieder. ...
Was für ein Tip?
Die Sensoren von Tobias' Umweltsensor (TSL250, TSL260, beide sind Helligkeitssensoren) neigen dazu, gnadenlos zu übersteuern. Ich würde gerne einen Globalstrahlungssensor auf dem Dach haben. Pah's Tipp in Karlsruhe war:
- Sensoren "dämpfen" mit Folie (deren Dämpfung bzw. Spektrum unbekannt ist, welche?)
- an einem hellen Tag (unbewölkt) den Sensor aufs Dach montieren und die Daten über der Zeit aufnehmen (schauen, dass der Sensor nicht übersteuert)
- entweder mit einer Messkurve oder einer berechneten Kurve des DWD für den Ort (habe ich bisher leider noch nicht gefunden) den Maximalwert in W/m2 kalibrieren
- die Umrechnung in lux sollte annähernd mit 1 W/m2 = 100 ... 130 lux gehen (da gibt es aber auch widersprüchliche Angaben von geht nicht bis zu den o.g. Zahlen)
Gruß PeMue
Wow, ein super Projekt habt ihr da am Laufen! Ich hätte da sicherlich auch Interesse, etwas mit zu bestellen, falls möglich. Habe jetzt die 17 Seiten durchgeackert, aber bin jetzt etwas verwirrt muss ich sagen. Information overflow :D
Zwei Fragen hätte ich konkret:
-Hab gelesen, dass es Innen- und Außenversionen gibt. Was ist denn da der Unterschied? Anderes Gehäuse?
-Wie geht das mit dem Programmieren der Atmels vor sich? Gibts da Pins auf der Platine, wo man sich dran hängt, und dann per ISP selbst bespielt? Oder wie ist das gedacht?
Also wenn ich darf, dann würde ich da mit ca. 6 Stück einsteigen. Ich denke mal so 4 für innen und 2 für außen, falls das jetzt schon wichtig ist. Keine Eile natürlich, will da keine Umstände machen. Bin geduldig und warte nicht drauf...
Der Status im Moment ist, dass ihr nochmal die Platine überarbeitet, richtig? Braucht ihr noch weitere Angaben? Sensoren für Temp, Luftfeuchte und Helligkeit sind immer drauf (oder?) . PIR wäre auch interessant aber so wie ich es verstand den habe, wäre das eine Erweiterungsplatine zum selber machen.
Hallo,
da ist man das WE mal unterwegs und nimmt auf die Schnelle noch den Sensor in Betrieb, geht es schief ;)
Also ich hatte Eneloop Akkus genommen und leider waren diese wohl zu leer.
BWT gegen Ende des Akkus hatte ich mit SW Version 0.1 falsche Werte, wie beim einschalten.
Morgen schaue ich mal, das ich mir einen Adapter bauen, um die neue SW zu programmieren.
BTW Hat jemand Erfahrung mit Acryl bzgl Lichtleiter? Es müsste doch via Prisma möglich sein, direkt vom Rand aus das Licht zum Helligkeitssensor zu bekommen.
IMHO hätte das den Vorteil, das der Weg zum Deckel frei ist und man mehr Platz für die Erweiterung hätte.
Nico
ZitatZwei Fragen hätte ich konkret:
-Hab gelesen, dass es Innen- und Außenversionen gibt. Was ist denn da der Unterschied? Anderes Gehäuse?
-Wie geht das mit dem Programmieren der Atmels vor sich? Gibts da Pins auf der Platine, wo man sich dran hängt, und dann per ISP selbst bespielt? Oder wie ist das gedacht?
Moin!
Ich habe zwar die Geräte nicht entworfen, verfolge jedoch den Thread von Anfang an und habe eine Prototyp-Platine ;)
Daher kann ich diese Fragen auch beantworten.
Zu der ersten Frage:
Ja, Außensensor hat ein wasserdichtse Gehäuse. Und auch kein Sensor für Luftfeuchte drin (da eben wasserdicht). Dafür eine Anschlußmöglichkeit für externe Sensoren.
Zu der zweiten Frage:
Die Platine hat einen (Arduino-)Bootloader drauf und wird per UART Programmiert (erfordert einen externen USB-UART-Adapter). ISP wäre natürlich auch möglich. Es sind Lötpads darauf, die den Pins eines Arduino Pro Mini antsprechen (Es ist ja auch möglich, diesen statt den eingelöteten ATmega zu verwenden).
Grüße,
Alexander
da es hier im thread schon angesprochen wurde ob man dem board auch eine eingeabemöglichkeit verpassen kann kurz ein link auf den anderen thread in dem ein ähnlichers board aber mit lcd display und rotary encoder entsteht: http://forum.fhem.de/index.php/topic,20956.msg154501.html#msg154501 (http://forum.fhem.de/index.php/topic,20956.msg154501.html#msg154501).
in dem video kann man sehen wie die bedienung z.b. zum einstellen der solltemperatur aussehen wird.
das board ist zwar zur zeit vor allem wegen der beiden luftqualitäts sensoren für den betrieb mit netzteil vorgesehen, wenn man die weg lässt und das display nur bei bedarf einschaltet sollte etwas in der art aber auch mit batterien funktionieren.
den aktuellen stand des boards findet sich hier: http://forum.fhem.de/index.php?topic=20956.msg152738#msg152738 (http://forum.fhem.de/index.php?topic=20956.msg152738#msg152738).
gruss
andre
Hallo Dirk,
ich habe auch Interesse an einer Innen- und einer Außenversion.
Beeindruckende Arbeit.
Vielen Dank und viele Grüße
Thomas
Hallo Dirk,
Hättest Du noch zwei Innensensoren mit MAX chip?
Grüße Mark,
Zitat von: PeMue am 30 März 2014, 17:36:34
Die Sensoren von Tobias' Umweltsensor (TSL250, TSL260, beide sind Helligkeitssensoren) neigen dazu, gnadenlos zu übersteuern. Ich würde gerne einen Globalstrahlungssensor auf dem Dach haben. Pah's Tipp in Karlsruhe war:
- Sensoren "dämpfen" mit Folie (deren Dämpfung bzw. Spektrum unbekannt ist, welche?)
- an einem hellen Tag (unbewölkt) den Sensor aufs Dach montieren und die Daten über der Zeit aufnehmen (schauen, dass der Sensor nicht übersteuert)
- entweder mit einer Messkurve oder einer berechneten Kurve des DWD für den Ort (habe ich bisher leider noch nicht gefunden) den Maximalwert in W/m2 kalibrieren
- die Umrechnung in lux sollte annähernd mit 1 W/m2 = 100 ... 130 lux gehen (da gibt es aber auch widersprüchliche Angaben von geht nicht bis zu den o.g. Zahlen)
Ich Experimentiere grade noch mit der Integration-Time. Damit kann man den Sensor unempfindlicher machen.
Man verliert hier zwar an Auflösung, mit sinkender Helligkeit kann man das dann ja automatisch umschalten.
wenn das Wetter bis zum Wochenende so bleibt, kann ich gut weiter testen.
Sollte das nicht reichen, dann wird es wohl die Version mit dem Filter.
Zitat von: vbs am 30 März 2014, 21:19:35
Habe jetzt die 17 Seiten durchgeackert, aber bin jetzt etwas verwirrt muss ich sagen. Information overflow :D
Es gibt bald einen Wiki-Artikel. Ich hoffe ich komme die Woche dazu.
Zitat-Wie geht das mit dem Programmieren der Atmels vor sich? Gibts da Pins auf der Platine, wo man sich dran hängt, und dann per ISP selbst bespielt?
Sowohl als auch. Der Atmel wird, wie die Arduino's auch, über einen seriellen Bootloader programmiert. Ansonsten sind auch die ISP-Pins nach außen geführt.
ZitatAlso wenn ich darf, dann würde ich da mit ca. 6 Stück einsteigen. Ich denke mal so 4 für innen und 2 für außen, falls das jetzt schon wichtig ist.
Ich hab dich mal mit auf die Liste gesetzt. Wenn es dann mit ausreichenden Stückzahlen losgeht, kannst du deine Wünsche noch mal konkretisieren.
ZitatDer Status im Moment ist, dass ihr nochmal die Platine überarbeitet, richtig?
Ja, es kommen noch Pads dazu um die Platine auch in kabelgebundenen Systemen (RS485) verwenden zu können und um eine externe Spannungsversorgung anzuschließen, falls man energiehungrige Sensoren o.Ä. betreiben möchte.
ZitatPIR wäre auch interessant aber so wie ich es verstand den habe, wäre das eine Erweiterungsplatine zum selber machen.
So ist erst mal der Plan. Wenn es eine Sinnvolle Lösung gibt, gibt es bestimmt entsprechende Erweiterungsplatinen.
Zitat von: santalaus am 30 März 2014, 21:50:39
BWT gegen Ende des Akkus hatte ich mit SW Version 0.1 falsche Werte, wie beim einschalten.
Was für eine Spanung hatten die Akkus am Schluss?
ZitatIMHO hätte das den Vorteil, das der Weg zum Deckel frei ist und man mehr Platz für die Erweiterung hätte.
Oder ein Loch in die Erweiterungsplatine an entsprechender Stelle. Ansonsten plane ich für die nächste Version ein alternativen Footprint für den TSL2561 weiter rechts.
Zitat von: justme1968 am 31 März 2014, 00:51:36
das board ist zwar zur zeit vor allem wegen der beiden luftqualitäts sensoren für den betrieb mit netzteil vorgesehen, wenn man die weg lässt und das display nur bei bedarf einschaltet sollte etwas in der art aber auch mit batterien funktionieren.
Ich bin immer noch "scharf" auf die kleinen E-Paper-Displays.
Dann reichen auch Batterien.
Zitat von: Polyboy am 31 März 2014, 12:05:22
ich habe auch Interesse an einer Innen- und einer Außenversion.
Beeindruckende Arbeit.
Ich hab dich mit auf die Liste gesetzt.
Zitat von: MdeJong am 31 März 2014, 14:44:29
Hättest Du noch zwei Innensensoren mit MAX chip?
In ca. 2 Wochen gibt es die nächste und hoffentlich letzten Prototypen.
Gruß
Dirk
Ich bin immer noch "scharf" auf die kleinen E-Paper-Displays.
Dann reichen auch Batterien.
ich hatte sie schon eingepackt für karlsruhe. konnte dann aber leider nicht :(
ja. auf jeden fall reichen dann batterien. aber der anwendungsfall ist ein anderer. um z.b. die temperatur interaktiv über den encoder einzustellen sind sie zu langsam. das macht wirklich keinen spass. als reines status display für passive anwendungen sind sie auf jeden fall um längen besser. zumindest wenn es nicht dunkel ist.
das tft kann man z.b. auch blinken lassen und aufmerksamkeit erwecken wenn ein alram angezeigt wird.
das ideale display wäre eine mischung aus beidem :)
Hallo,
leider kann ich die Spannungen nicht nachvollziehen. Wie gesagt ich war nicht da und habe dann die Akkus direkt versucht zu laden, dabei stellte sich raus, das einer defekt und tiefentladen ist.
Gefühlt war der 2.te Akku nicht leer, aber ich kann es nciht nachvollziehen. Ich hätte gedacht, wg dem Max das es nicht so plötzlich kommt.
Nico
Zitatum z.b. die temperatur interaktiv über den encoder einzustellen sind sie zu langsam. das macht wirklich keinen spass.
Echt. Ich habe grade ein Kindle hier liegen. Da war ich überrascht das der auch kleine Animationen abspielen kann. Das sieht besser aus wie gedacht.
Zitatdas tft kann man z.b. auch blinken lassen und aufmerksamkeit erwecken wenn ein alram angezeigt wird.
Das stimmt.
Zitatdas ideale display wäre eine mischung aus beidem :)
Ich habe hier aber noch die 128x64px LCD's hier liegen. Damit will ich auch noch experimentieren.
Zitat von: santalaus am 31 März 2014, 21:35:56
leider kann ich die Spannungen nicht nachvollziehen. Wie gesagt ich war nicht da und habe dann die Akkus direkt versucht zu laden, dabei stellte sich raus, das einer defekt und tiefentladen ist.
Gefühlt war der 2.te Akku nicht leer, aber ich kann es nciht nachvollziehen. Ich hätte gedacht, wg dem Max das es nicht so plötzlich kommt.
Könnte aber sein, dass dann keine 0,8V mehr am MAX angekommen sind.
Und damit der MAX die 3,3V mit ~30 mA (beim Senden mit LED) am Ausgang bereitstellen kann, muss die Energiequelle am Eingang die 0,8V auch mit > 123mA Liefern können. 123 mA währen aber 100% Wirkungsgrad vom MAX. Daher werden es dann vermutlich 150 mA oder so sein.
Gruß
Dirk
Hallo,
ich weiss nicht ob es eine Homematic Beschränkung ist oder z.Z. nicht umgesetzt. Ist es möglich Luftfeuchtigkeit und -druck mit einer Nachkommastellen zu übergeben?
Bei mir zucken beide Werte schon mal zwischen zwei Werten hin und her.
Die Helligkeitswerte muss ich mal beobachten, könnte aber an der Sensorposition liegen.
Ansonsten scheint die V 0.2 recht gut zu laufen.
Bzgl der falschen Werte bei niedriger Batterie: Was mich wundert es kam vom Sensor immer Batterie: ok, auch bei falschen Sensorwerten.
Ansonsten kann ich es nicht mehr nachvollziehen. Hätte da nicht eine Bat-low meldung kommen sollen? Oder war das in 0.1 nicht implementiert?
Nico
Zitat von: santalaus am 01 April 2014, 17:35:03
ich weiss nicht ob es eine Homematic Beschränkung ist oder z.Z. nicht umgesetzt. Ist es möglich Luftfeuchtigkeit und -druck mit einer Nachkommastellen zu übergeben?
Bei mir zucken beide Werte schon mal zwischen zwei Werten hin und her.
Im HM_WDS10_TH_O ist das so definiert. Daher hatten wir das so auch erstmal übernommen.
Im Prinzip geht das aber.
ZitatBzgl der falschen Werte bei niedriger Batterie: Was mich wundert es kam vom Sensor immer Batterie: ok, auch bei falschen Sensorwerten.
Ansonsten kann ich es nicht mehr nachvollziehen. Hätte da nicht eine Bat-low meldung kommen sollen? Oder war das in 0.1 nicht implementiert?
Im Moment wird die Batteriespannung noch intern im AVR gemessen. Im Zusammenhang mit dem MAX kommen da noch falsche Werte raus.
Die Hartware ist da, muss aber noch entsprechend angesprochen werden.
Gruß
Dirk
Zur Zeit werden die gemessenen Werte wie folgt übertragen:
tttt ff dddd
t = 15 bit temperatur/ 1 bit battery low
f = 8 bit luftfeuchtigkeit
d = 16 bit luftdruck
t wird bereits mit einer Nachkommastelle übertragen, es werden 10tel Grad in den Wert gepackt und verschickt. aus 17,3 wird 173
Aus meiner Sicht macht bei Luftfeuchtigkeit und Druck das Übertragen von Kommastellen keinen Sinn. Der SHT10 hat bei der Feuchtemessung eine Genauigkeit von 5%,
das macht jeden Kommawert überflüssig. Die Frage ist ja immer, was ist die Information Wert und stimmt sie.
Bei 5% stimmt die Kommastelle garantiert nicht, ausserdem spielt es keine Rolle ob du 40 oder 41% Luftfeuchtigkeit hast.
Update: ist ja noch viel schlimmer, zwischen 20% und 80% relF hat er eine Ungenauigkeit von 5% relF - das wären im Mittel 10% Ungenauigkeit.
Falls du damit nur das Wertswitchen in FHEM beseitigen willst, sollten wir eher aufrunden :-)
Oder einen Filter setzen und die Messwertänderung einschränken...
@ all
Es tut mir leid das ich mich im Moment nicht mehr einbringen kann, aber ich habe in der Arbeit einiges um die Ohren.
Neuer Chef und komplette Umorganisation (Zeit fürs Hobby wird bestimmt die nächsten 3 Monate Mangelware sein)...
Hallo,
da hatte ich mich im Datenblatt verschaut. So machen Nachkommastellen keinen Sinn richtig.
BTW. Heute ich die 0.2 bei mir hängengeblieben. Ich weiss ja nicht ob das noch interessant ist.
Nach einigen Sekunden ohne Batterie diese wieder rein und dann waren die ersten Werte.
Daneben. (Temp 1,5°C zu hoch; Feuchtigkeit macht einen Sprung 54->48->50 dort stabilisierend;) Druck und Helligkeit scheinen zu passen.
Nico
Seit dem hier die gepatchte (damit auch Lichtstärke angezeigt wird) CUL_HM-Version veröffentlicht wurde, gab es mehrere Updates.
Ich habe hier die Änderungen zusammengemerged.
Hi Hexenmeister,
das mit dem mergen wird immer ein Problem bleiben. Mit diesem Vorgehen koppelst du dich von allen Updates ab.
Lux bei THSensor einzubauen sehe ich etwas kritisch. Die Basis der SW ist hier immer HM. Die haben dies so nicht. Außerdem werden Daten von HM grundsätzlich in HEX gesendet.
Es gibt hierfür die Möglichkeit einen eigenen subtype zu definieren und diesen in einer eigenen Funktion zu behandeln, welche ausserhalb von CUL_HM liegt. Könnte man in 99_Utils ablegen oder auch anderswo.
Zukunftssicher ist dein aktuellen patchen nicht.
Gruss Martin
Hi Martin,
ZitatZukunftssicher ist dein aktuellen patchen nicht.
Das ist auch nicht das Ziel.
Geplant ist ein eigener Subtyp.
Da sollten wir noch mal besprechen wie wir das angehen.
Die Patches sind aktuell nur die Möglichkeit HM überhaupt zur Anzeige der neuen Daten zu bewegen.
Die THSensoren habe ja auch keine Luftdruck. Daher ist die Implementierung hier sicher auch nicht von Dauer.
Gruß
Dirk
Wie Dirk schon sagte, es handelt sich um einen (derzeit leider notwendigen) Provisorium. ;)
Mal eine bescheidene Frage am Rande: Könnte man die Baugruppe irgendwie so einsetzen, dass man damit die Temperaturwerte von zwei Temperaturfühlern Typ K erfassen und übertragen kann?
Hallo Udo,
momentan basiert die Schaltung darauf, alle Sensoren über I2C abzufragen, d.h. keine Eingangsverstärker, etc. Außer der Batteriespannung wird nichts per A/D-Wandler eingelesen.
Temperaturfühler von Typ K erfordern relativ gute Eingangsverstärker, die dann auch auf einen A/D-Wandler geführt werden.
Fazit: Momentan nicht möglich, wenn aber Bedarf ist, könnte man (=Dirk?) das sicherlich in den Universalsensor mit einbauen.
Gruß Peter
Theoretisch schon.
Du musst die Sensoren hardwareseitig ankoppeln. Vermutlich am einfachsten über je einen ADC-Kanal. Ggf muss noch ein OPV davor?
Mindestens 2 ADC-Kanäle sind noch unbenutzt und nach Außen geführt.
Der Rest ist Software.
Update:
Zitat von: PeMue am 06 April 2014, 11:00:41
Fazit: Momentan nicht möglich, wenn aber Bedarf ist, könnte man (=Dirk?) das sicherlich in den Universalsensor mit einbauen.
Oder am einfachsten über eine kleine Zusatzplatine zum Aufstecken.
Gruß
Dirk
Das ist nix wirklich dringendes. Aber ich hätte dann endlich eine vernünftige Möglichkeit, die Temperaturen meiner beiden Wasserbettmatratzen zu überwachen. Ich habe nämlich den Verdacht, dass die zugehörigen Heizungen viel zu ungenau arbeiten. Und da kam mir nun die Idee...
Ich würde einen AD594 davorschalten. Wenn ich das noch richtig weiß, sollte man auch schauen, dass die Referenzpotentiale auf gleicher Temperatur sind. Ich mach mir mal ein paar Gedanken für eine Aufsteckplatine, ich glaube Lochraster ist da zu wenig ...
Gruß Peter
Ich habe hier mal die Version 0.3 der Firmware angehängt.
Änderungen:
- Es werden jetzt keine "sinnlosen Daten" mehr geschickt wenn entsprechende Sensoren nicht vorhanden sind.
- Die Batteriespannungsmessung geht nun über den Spannungsteiler und nicht mehr über die interne Messung. Dadurch wird nun auch die Spannung richtig gemessen wenn der MAX bestückt ist.
- Die Batteriespannung wird in 2 Bytes nach der Helligkeit mit übertragen. Das ist derzeit aber eher zum debugen gedacht.
- Die Helligkeitsmessung ist optimiert. Je nach Umgebungshelligkeit schaltet der Sensor die Empfindlichkeit entsprechend um. Dennoch kann man bei direkter Sonneneinstrahlung keine sinnvollen Werte messen. Die Sonne ist hier einfach zu hell. Aktuell mache ich versuche mit verschiedenen Filtern. Der Einfachste "Filter" währ z.B. ein Blatt Papier im Deckel des Außensensorgehäuse. Eine Umrechnung des gemessenen Helligkeitswertes könnte man dann in FHEM vornehmen.
Mit dabei ist das Flash-Tool.
Damit kann man die Firmware auch ohne installierte IDE vornehmen.
Außerdem kann man beim Flashen angeben welche HM-ID und welche Seriennummer der Sensor bekommen soll.
Dafür ist kein Neukompilieren der Firmware mehr erforderlich.
Das Flash-Tool existiert derzeit nur für Windows. Da hier aber "nur" weit verbreitete Tools und ein bisschen Shell-Programmierung eingesetzt werden, kann man das recht einfach auf andere Plattformen portieren.
Die Nutzung des Flash-Tools sieht dann so aus:
Das Zip in ein Verzeichniss der Wahl entpacken und ins Verzeichnis wechseln
flash.bat <COMX> <hexfile> [<HM-ID> <Serial>]
COMX ist der benutzte COM-Port vom USB-UART-Adapter
hexfile ist das zu flashende Hex-File
Bei der HM-ID wird die 3 Byte grosse HM-ID eingegeben: XX:XX:XX
Die Serial ist die 10-Stellige Seriennummer.
Ohne Angabe von HM-ID und Serial werden die Daten aus dem Flashfile benutzt.
Gruß
Dirk
Update:Anhang gelöscht.
die letzte Version ist hier:
http://forum.fhem.de/index.php/topic,20620.msg157410.html#msg157410
Hallo Dirk,
danke, habe gerade die neue Version geflasht.
Werde beobachten, wie's läuft.
Ist das Problem mit dem 'Aufhängen' noch vorhanden?
FlashTool erleichtert die Sache schon wesentlich.
Das FlashTool hat zwei kleine 'Unschärfen':
- im ZIP fehlt die libiconv2.dll, wahrscheinlich bei Dir im globalen Path.
- das Aufräumen klappt nicht ganz. Script beschwert sich über fehlende Befehle 'mv' und 'rm'. Klingt irgendwie sehr nach Linux ;)
Ansonsten - sehr cool! 8)
Grüße,
Alexander
Erste Beobachtung:
Lichtstärke soll laut Sensor bei 0,09Lx liegen. Der Sensor liegt offen auf dem Tisch, Deckenlampe ist an.
Mein eigenes Messgerät ist aber der Meinung, es ist 32Lx. Ich sehe das auch so ;)
Die 0.2er Version war in diesem Punkt genauer.
Grüße,
Alexander
Zitatdas Aufräumen klappt nicht ganz. Script beschwert sich über fehlende Befehle 'mv' und 'rm'. Klingt irgendwie sehr nach Linux
Windows XP?
Unter Windows 7 gibts auch cp und mv.
Ich hab's geändert.
die fehlende dll ist auch mit dabei.
ZitatIst das Problem mit dem 'Aufhängen' noch vorhanden?
Ich hoffe nicht.
Ich hab das Problem aber noch nicht genau gefunden.
Alkuell führe ich einen Reset nach ca. 8 Stunden durch.
Das ist zwar ziemlich "dreckig" Aber bis die Ursache gefunden ist, sollte das hoffentlich helfen.
ZitatLichtstärke soll laut Sensor bei 0,09Lx liegen. Der Sensor liegt offen auf dem Tisch, Deckenlampe ist an.
Hier ist mir noch ein Bug reingerutscht.
Schau mal wir sich 0.4 bei dir verhält.
Gruß
Dirk
Update:Anhang gelöscht.
die letzte Version ist hier:
http://forum.fhem.de/index.php/topic,20620.msg157410.html#msg157410
ZitatWindows XP?
Nö, Win 7 Pro 64 SP1. Meiner kennt keine mv und rm.
Script funktionierte sofort :)
Die Lux-Anzeige ist leider unverändert. Wenn ich Sensor direkt auf die Lampe richte (ca. 2m Entfernung), werden 0,18Lx angezeigt (Messgerät 45Lx).
jetzt muss ich nur noch rausfinden, wo an der Platine die Anschlüsse für die Spannungsversorgung sind 8)
Zitat von: hexenmeister am 06 April 2014, 22:22:55
Die Lux-Anzeige ist leider unverändert. Wenn ich Sensor direkt auf die Lampe richte (ca. 2m Entfernung), werden 0,18Lx angezeigt (Messgerät 45Lx).
Ich guck mir das heute Abend nochmal an.
Vermutlich klappt da was mit der Empfindlichkeitsumschaltung noch nicht.
Zitat von: betateilchen am 07 April 2014, 17:03:07
jetzt muss ich nur noch rausfinden, wo an der Platine die Anschlüsse für die Spannungsversorgung sind 8)
Ja, die Doku ist noch nicht fertig. Ist aber in Arbeit.
Die Schaltpläne von hier, sind aber korrekt:
http://forum.fhem.de/index.php/topic,20620.msg144693.html#msg144693
Die Platine des Außensensors ist auf Seite 2 im PDF beschrieben.
Die Beschriftung ist hier leider nicht ganz so gut zu lesen.
Battery + ist das Pad links neben C11
Battery - ist das Pad darunter.
Gruß
Dirk
Die Anschlussbelegung für die Spannung hab ich gefunden, danke. Der Sensor liefert auch schon brav Daten:
state T: 25.5 H: 163 AP: 1005
Ich nehme an, dass AP noch nicht auf NN bezogen ist und ich das noch selbst berechnen muss?
Wie interpretiere ich den Wert von H? Eigentlich interessiert mich ja nur der Luftdruck :)
Wieso funktionieren eigentlich userReadings bei dem für den Sensor angelegten Device nicht?
Ich wollte ein userReading für den berechneten pressure-nn anlegen - aber das Anlegen wird nicht getriggert.
userReadings pressure-nn { relDruck(ReadingsVal("out_Pressure","airpress",1000)) }
Als ich heute Hause kam, hing der Sensor leider wieder.
Reboot alle 8 Stunden als Notmaßnahme scheint nicht immer zu greifen. :(
Zitat von: betateilchen am 07 April 2014, 19:55:08
Wieso funktionieren eigentlich userReadings bei dem für den Sensor angelegten Device nicht?
FHEM behandelt den Sensor aktuell genau so wie einen HM_WDS10_TH_O.
Vielleicht kann da Martin was zu sagen wenn er ab und zu mitliest?
Zitat von: hexenmeister am 07 April 2014, 21:08:11
Als ich heute Hause kam, hing der Sensor leider wieder.
Reboot alle 8 Stunden als Notmaßnahme scheint nicht immer zu greifen. :(
Das habe ich auch festgestellt.
Ich lasse grade einen Langzeittest laufen.
Aktuell sende ich alle 5 Sek. Daten. In diesem Modus hing sich der Sensor sonst immer innerhalb von 1-2 Std. auf.
Jetzt bin ich auch bereits bei über 8 Stunden. Ohne Reset. Mal sehen wie es morgen aussieht.
Zitat von: Dirk am 07 April 2014, 21:35:04
FHEM behandelt den Sensor aktuell genau so wie einen HM_WDS10_TH_O.
Vielleicht kann da Martin was zu sagen wenn er ab und zu mitliest?
martin nicht, es ist kein Homematic Problem (obwohl es schön wäre, wenn pressure-nn direkt bereitgestellt würde, aber das ist ein anderes Thema)
Aber vielleicht kann Rudi bei Gelegenheit erklären, warum userReadings mit einem Bindestrich im Namen nicht funktionieren 8)
http://forum.fhem.de/index.php/topic,22291.0.html
wie im entsprechenden Thread erklärt ist ein "-" ein wort-trenner, genauso wie blank, Punkt oder Komma. Diese Zeichen in einem String solle man vermeiden, zumindest, wenn es einen Namen oder ein Wort ergeben soll.
Sie Unsitte sogar Blanks in Namen (filenamen,... ) zuzulassen erzeugt einfach immer nur Schwierigkeiten.
Der übliche Abstandshalter ist der underscore - das ist ein wort-trenner
Das ist kein HM und auch kein FHEM -Problem, das sind allgemeine regexp Regeln.
ja ne, iss klar...
Du meinst, genau wie bei measured-temp, desired-temp, R-irgendwas usw. - die selbstverständlich auch alle keinen Bindestrich verwenden.. :o
Und von Leerzeichen im Namen hat niemand gesprochen.
ja, hast recht - sollte ich alle austauschen....
untersteh Dich (http://www.ip-phone-forum.de/images/smilies/keule.gif)
@Martin
Wie wollen wir den vorgehen um eigene Devices für HM anzulegen?
Ich würde gerne das das Ganze ohne gepatche von CUL_HM auskommt.
Dann kann ich den Devices auch eigene Readings geben.
Und das ganze sollte idealerweise auch per Update verteilbar sein.
Ein eigenes Modul pro Device/Devicefamilie was CUL_HM mit den nötigen Informationen versorgt?
@hexenmeister
Der Sensor liefert im 5 Sekundentakt Daten und läuft noch.
Sieht also gut aus. Ich denke ich werde heute Abend die v0.5 liefern.
Gruß
Dirk
Zitat von: Dirk am 08 April 2014, 12:05:48
Der Sensor liefert im 5 Sekundentakt Daten und läuft noch.
Sieht also gut aus. Ich denke ich werde heute Abend die v0.5 liefern.
Sehr cool! :D
Werde dann sofort auch testen.
Grüße,
Alexander
Zitat von: betateilchen am 07 April 2014, 22:24:22
Aber vielleicht kann Rudi bei Gelegenheit erklären, warum userReadings mit einem Bindestrich im Namen nicht funktionieren
so wie ich das sehe, gibts dafür vermutlich morgen von Rudi eine Lösung per update :)
@Dirk,
Ich hatte schon einmal einen Vorschlag gemacht... muss ich noch einmal suchen, und werde diesen Kompletieren.
gepatchtes CUL_HM ist keine Option.
Je nach dem, was man alles ändert oder anbietet muss man mehr oder weniger tun.
Gruss Martin
Hi,
Im Anhang ein "Grundriss". Je nachdem was du brauchst musst du
- parametrisierung Device
-- festlegen, welchen zugriffsmode dein Device hat (burst,...) welche Kanäle, welche Registersätze auf welchen Kanälen
- Register Definition
-- wenn passende nicht vorhanden sind, musst du ein neues definieren
- Register Nutzen
- du musst jedem Channels die Register zuweisen. Die eigenen oder vordefinierte.
- Kommndos
- jeden Kanal musst du kommandos zuweisen
! neue Kommandos kann man bislang nicht festlegen.
Folgende Kommandos gehen immer:
regBulk => "<list>:<peer> <addr1:data1> <addr2:data2> ...",
getRegRaw => "[List0|List1|List2|List3|List4|List5|List6] ... [<PeerChannel>]",
getConfig => "",
regSet => "[prep|exec] <regName> <value> ... [<peerChannel>]",
clear => "[readings|register|rssi|msgEvents]",
raw => "data ...",
reset => "",
pair => "",
unpair => "",
- parser
wenn du bei der Definition des Device einen eigenen subType festgelegt hast kannst schreibst du eine Funktion
"CUL_HM_Parse<mysubType>"
Alle nachrichten deines Device werden hier hingeleitet und du kannst sie Zerlegen. Alle Trigger scheibst du in die EventQueue
push @evtEt,[$shash,1,$statemsg];
Standards wie Register lesen wird automatisch gemacht.
Fragen? :)
Gruss Martin
ZitatFragen?
Ja. Wohin kommt das Ganze dann?
CUL_HM wollen wir ja nicht patchen.
Gruß
Dirk
ZitatCUL_HM wollen wir ja nicht patchen.
da sollte es auf keinen Fall rein.
Im Prinzip in ein file deiner Wahl.
i.a. macht man eigenen Code nach 99_myUtils.pm
Ich kann einmal einen konkreten Vorschlag machen - als template quasi.
Gib mir die Randbedingungen...
Oft kann man einiges von vorhandenen Aktoren übernehmen - dann muss man nicht alles selbst machen (was sinn der Sache ist/sein soll).
Was hast du nun konkret vorliegen? Einen Thermosensor auf Basis eines HM-WDS10-TH-O plus zusätzlicher ... register, events, readings... Liste einmal auf, was der Sensor kann oder können wird
Gruss Martin
Hallo,
gibt es für die Sensoren schon eine Gerätedefinition für die Homematic CCU2, damit dieser Sensor auch damit genutzt werden kann?
LG
Franz
Hallo Franz,
Zitatgibt es für die Sensoren schon eine Gerätedefinition für die Homematic CCU2, damit dieser Sensor auch damit genutzt werden kann?
Noch nicht. Die muss ich noch bauen.
Du kannst den Sensor aber trotzdem an die CCU anlernen. Der verhält sich dort wie ein HM_WDS10_TH_O.
Du siehst dort aber nur Temperatur / Feuchte. Beim Außensensor ohne externen Temp/Feuchtesensor nur die Temperatur vom BMP180
Dafür musst du aber noch die 0.5er Firmware auf den Sensor flaschen.
Die Poste ich gleich noch.
Viele Grüße
Dirk
Hallo,
anbei mal wieder ein kleines Update:
Version 0.5
- Die Helligkeitsanzeige sollte nun die richtigen Werte liefern.
- Ich hoffe der Sensor läuft nun ohne Hänger durch
- Ich habe noch ein paar Optimierungen gemacht, so das der Code etwas weniger Platz im Flash braucht
Noch was vergessen:
Im Zip sind 2 Hex-Files.
... _test.hex ist eine Version bei der der Sensor alle 5 Sekunden Nachrichten verschicket.
Das soll nur zum Testen sein. Ansonsten schickt der Sensor seine Daten ca. alle 2,5 min.
Gruß
Dirk
Update:Anhang gelöscht. Der Link zur letzten Firmware ist jetzt immer hier:
https://github.com/kc-GitHub/Wettersensor/raw/master/Tools/Firmware/Flash-Tool-Windows.zip
Hat zufällig jemand eine avrdude binary für Mac OSX greifbar?
Hier sollte eins dabei sein:
http://www.ladyada.net/learn/avr/setup-mac.html
*grummel* kenn ich doch. Aber das muss einfacher gehen.
Leider gibts das FlashTool im Moment erst für Windows.
Eine Linux-Version werde ich auch vorbereiten.
Wenn du die Binaries für MacOS zusammen sammelst dann könnte man dafür auch eine Version bauen.
Zitat von: betateilchen am 09 April 2014, 20:16:04
Hat zufällig jemand eine avrdude binary für Mac OSX greifbar?
einfach die arduino ide installieren. da ist alles dabei...
ansonsten angehängt.
... und die Ardunio IDE ist sogar für Windows (wer hätte es gedacht) portaben. Habe die auf dem USB Stick ...
Gruß Peter
Die arduino ide habe ich hier auf dem Mac - aber ein avrdude habe ich darin nicht gefunden. Danke.
liegt alles unter /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin
ja, danke - so tief in der Struktur hatte ich nicht gesucht. Wenn ich irgendwo JAVA lese, ist bei mir schon schluss 8)
Gibts einen zwingenden Grund, den Aussensensor von 0.2 auf 0.5 zu aktualisieren?
Ich geh dann mal löten...
locate ist dein freund
und ich wäre auch nicht drauf gekommen wenn ich nicht das ino tool verwenden würde.
Zitat von: betateilchen am 09 April 2014, 20:45:50
Ich geh dann mal löten...
Du hast glaube keinen MAX drauf?
Dann nicht unbedingt.
Weil in der 0.2er Version wird die Batteriespannung nur intern gemessen und nicht vor dem MAX.
Außerdem bekommst du so auch noch die Temperatur vom BMP180 und die Batterispannung wird auch noch übertragen. Nicht nur "Batteri-Leer".
Und ich hoffe jetzt, dass diese Version stabiler läuft.
Die letzten blieben ab und zu hängen.
Du musst aber nicht unbedingt löten.
Ich stecke einen einreihigen Pfostenstecker auf 4 Kabel die zum USB-UART-Adapter gehen.
Den Pfostenstecker kann man dann in die ersten 4 Pins der unteren Pinreihe stecken und dann leicht nach unten Verkanten.
Dann festhalten und flashen. Für soche Aktionen ab uns zu ist das völlig ausreichend. Wenn man das öfters machen möchte, dann lohnt es sich die 4 Pins mit einem Pfostenstecker zu verlöten.
Hallo!
Habe den _test.hex geflasht. Nach ca. 1 Stunden nachgesehen - leider hing da gute Teil wieder :(
Deiner lief doch stabil(er). Was könnte bei meinem anders sein?
Zitat von: hexenmeister am 09 April 2014, 21:03:22
Nach ca. 1 Stunden nachgesehen - leider hing da gute Teil wieder :(
Deiner lief doch stabil(er). Was könnte bei meinem anders sein?
Eine Stunde nur?
Bis heute lief meiner über einen Tag. Vorhin hing er aber auch wieder.
Daher bin ich hier noch nicht fertig.
Die Helligkeit war wieder ok?
Ich hab mal Trilu gefragt. Vielleicht hat er noch ne idee.
Falls mal jemand inden Code schauen möchte, ich hab den bei mir im Github liegen.
Gruß
Dirk
also mein Sensor mit Version 0.2 lief jetzt zwei Tage durch.
Zitatalso mein Sensor mit Version 0.2 lief jetzt zwei Tage durch.
Naja, du hast keinen Temperatur/Feuchtesensor und keinen Helligkeitssensor.
Auf jeden Fall werde ich mal in diese Richtung "ermitteln"
Danke für den Hinweis.
so, den Hardwareteil hab ich fertig. Nun muss ich noch die Software zum Laufen bringen...
(http://up.picr.de/17913557eg.jpg)
(http://up.picr.de/17913558pa.jpg)
@Dirk
Stabil ist meiner leider noch nicht. Sieht man gut an den 'Sprüngen' in Diagram. Lief wohl nur sehr kurz mit der _test-Firmware. Ich habe erstmal wieder die 'normale'-Version geflasht.
Aber die Lux Anzeige sieht jetzt gut aus! ;)
P.S. Wie war noch mal Dein GitHub-Link?
wo finde ich die libusb0.dll *grummel*
Zitat von: betateilchen am 09 April 2014, 22:11:22
wo finde ich die libusb0.dll *grummel*
In Arduino-IDE zum bleistift: ...\hardware\tools\avr\bin
Der Code vom Sensor ist hier:
https://github.com/kc-GitHub/Wettersensor
Das Subrepo von der AskSin-Lib ist hier:
https://github.com/kc-GitHub/AskSin
Wie Verhält sich denn die LED bei dir beim senden?
Leuchtet die 2mal kurz oder einmal kurz und einmal lang?
Zitatwo finde ich die libusb0.dll *grummel*
Eine DLL für MacOS?
Fehlt die noch beim FlashTool? Dann pack ich sie noch mit rein.
vergiss MacOS - ich teste grade in einer Windows-VM (auf Mac) und im Flashtool ist die dll nicht dabei.
Aso.
Ist im Anhang.
Falls noch was fehlt, sag bescheid.
Ich muss das ding doch mal auf ner nachtem VM testen.
Update:
Anhang gelöscht.
Die fehlende dll-Datei ist im geändetren Flash-Tool hier enthalten:
http://forum.fhem.de/index.php/topic,20620.msg157410.html#msg157410
kommt die dll ins bin Verzeichnis oder irgendwo ins Windows-System?
Mensch, mach doch mal eine vernünftige Doku zu dem Sensor...
dll ins bin Verzeichnis kopiert, Update durchgeführt, geht.
(http://up.picr.de/17913941qy.png)
übrigens - die HMID und Seriennummer sind Pflichteingaben, ohne die Angaben meckert das Flashtool rum.
Danke!
ZitatWie Verhält sich denn die LED bei dir beim senden?
Leuchtet die 2mal kurz oder einmal kurz und einmal lang?
Die LED blinkt in kurzem Abstand nacheinander zwei mal kurz.
Was sagt das aus?
Zitat von: betateilchen am 09 April 2014, 22:33:46
übrigens - die HMID und Seriennummer sind Pflichteingaben, ohne die Angaben meckert das Flashtool rum.
Das sollte natürlich nicht so sein. Danke für den Hinweis.
Ich habs unten gefixt. Ohne Angabe der Daten wird nun wieder die HM-ID und die Seriennummer aus dem HEX-File benutzt.
Zitat von: hexenmeister am 09 April 2014, 22:38:19
Die LED blinkt in kurzem Abstand nacheinander zwei mal kurz.
Was sagt das aus?
Dann passt da schon mal alles.
Das erste mal kurz bedeutet Daten wurden gesendet, das zweite mal kurz ist der ACK von FHEM.
Das zweite mal lang würde bedeuten das FHEM das Packet nicht bestätigt hat.
Das kann man testen indem man das Device aus FHEM löscht, oder FHEM beendet.
Wenn die Firmware mal stabil läuft überlege ich aber das blinken abzustellen.
Das spart sicher noch ein paar Wochen Batterielaufzeit.
Gruß
Dirk
Hi,
ich bin jetzt endlich auch mal dazugekommen, mich mit der Sache zu befassen. Trotz libusb0.dll-Hürde habe ich auf meinem jetzt die 0.5er Firmware. Das Pairing unter FHEM hat auch geklappt. Allerdings passiert immer das hier, wenn das Teil sendet:
2014.04.09 22:24:17 1: 192.168.178.152:1000 disconnected, waiting to reappear
2014.04.09 22:24:17 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.04.09 22:24:17 1: 192.168.178.152:1000 reappeared (HMLAN1)
2014.04.09 22:24:17 1: HMLAN_Parse: HMLAN1 new condition init
2014.04.09 22:24:18 1: HMLAN_Parse: HMLAN1 new condition ok
...und readings bekomme ich keine.
Hier ist ein list auf das Device:
Internals:
CFGFN
DEF 42FFFF
HMLAN1_MSGCNT 8
HMLAN1_RAWMSG R481E93C5,0001,00004954,FF,FFC0,19A01042FFFF23A3F40100000000
HMLAN1_RSSI -64
HMLAN1_TIME 2014-04-09 22:12:14
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 8
NAME CUL_HM_HM_WDS10_TH_O_42FFFF
NR 775
STATE ???
TYPE CUL_HM
lastMsg No:19 - t:10 s:42FFFF d:23A3F4 0100000000
protLastRcv 2014-04-09 22:12:14
protSnd 9 last_at:2014-04-09 22:12:14
protState CMDs_done
rssi_at_HMLAN1 avg:-64.37 min:-67 max:-64 lst:-64 cnt:8
Readings:
2014-04-09 22:32:15 Activity unknown
2014-04-09 22:12:12 CommandAccepted yes
2014-04-09 22:12:10 D-firmware 0.5
2014-04-09 22:12:10 D-serialNr KEQ1234567
2014-04-09 22:12:13 PairedTo 0x23A3F4
2014-04-09 22:12:13 R-burstRx off
2014-04-09 22:12:13 R-pairCentral 0x23A3F4
2014-04-09 22:12:13 RegL_00: 01:00 02:01 0A:23 0B:A3 0C:F4 00:00
Helper:
cSnd 0123A3F442FFFF0103
mId 003D
peerIDsRaw ,00000000
rxType 140
Io:
nextSend 1397074334.62589
Prt:
bErr 0
sProc 0
try 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1397074334.4581
ack:
HASH(0x1027d00)
19800223A3F442FFFF00
Rssi:
At_hmlan1:
avg -64.375
cnt 8
lst -64
max -64
min -67
Shadowreg:
Attributes:
IODev HMLAN1
actCycle 000:10
actStatus unknown
autoReadReg 4_reqStatus
expert 2_full
firmware 0.5
model HM-WDS10-TH-O
peerIDs 00000000,
room CUL_HM
serialNr KEQ1234567
subType THSensor
Außerdem habe ich das Ding parallel am Serial Monitor hängen. Das sieht ungefähr so aus:
<- 1C 06 A2 70 42 FF FF 23 A3 F4 00 E6 31 03 F4 00 00 0B 78 09 5C 00 00 11 65 00 00 08 DE (l:29)
-> NA (716228)
Kann mir jemand einen Tipp geben?
Danke&Gruß,
Thorsten
Der Eventmonitor zeiht auch nix an?
HM-LAN kann ich erst am Wochenende Testen.
Sieht aber so aus als ob das Peering nicht richtig geklappt hat.
Lösch das Teil nochmal aus FHEM und Paire es nochmal.
Während dem Pairing kannst du ja mal die Serielle Konsole dran lassen.
ZitatHM-LAN kann ich erst am Wochenende Testen.
Ich habe den Sensor zwar jetzt über hmusbcfg im Betrieb, Hatte aber zwischendurch auch per hmlan angebunden gehabt. Keine Probleme damit.
Toll, da wollte ich schon sagen: 0.5 hängt.
Kann aber nicht meckern, bei mir hat sich der hmland bzw USB-Stick aufgehangen.
Erst nach Rechnerneustart lief es wieder.
/OffTopic Dafür funktioniert nun auch EC3000 was vorher nie ging.
Ansonsten sieht z.Z. alles recht gut aus. Ich habe mal versucht mich mit dem Quellcode zu beschäftigen, damit ich testen kann wenn die PIR kommen.
Nico
Hi Nico, das klingt ja ganz gut.
Bei mir und beim hexenmeister gibt es auch mit dem 0.5er noch hänger.
Das versuche ich noch zu analysieren.
Wie viele HM-Geräte hast du denn die noch so rumfunken?
Ich verfolge grade die Theorie das es beim Empfang und beim Interpretieren der Pakete von anderen HM-Geräten Probleme gibt.
Wenn nur ein Sensor läuft, schein es keine Probleme zu geben, Läuft ein weitere, kommt es bei einem von beiden zu Ausfällen.
Solange die LED am Sensor ca. alle 2-3 min. kurz blinkt, sendet der auch was.
Wie lange lief deiner bisher?
Gruß
Dirk
Wenn es nach der Anzahl der sonstigen HM Geräte gehen würde, müsste mein Sensor schon längst eingefroren sein 8)
Bisher keine Ausfälle bei meinem Sensor zu vermelden, ok, der hat auch nur den BMP180 an Bord. Aber vielleicht ist es ja auch gar kein Problem der Firmware, sondern der benutzten I2C Komponenten?
Zitat von: betateilchen am 10 April 2014, 22:54:19
Wenn es nach der Anzahl der sonstigen HM Geräte gehen würde, müsste mein Sensor schon längst eingefroren sein 8)
ZitatAber vielleicht ist es ja auch gar kein Problem der Firmware, sondern der benutzten I2C Komponenten?
Daran hatte ich auch schon gedacht und den Code für den Helligkeitssensor deaktiviert.
Das hatte auch keine Besserung gebracht.
Bei meinen Selbstbau-Tastern habe ich ab und zu auch hänger. Da gibt es keine I2C-Teile.
Daher tippe ich im Moment auf Probleme vom Code.
Es kann aber auch irgendeine Kombination aus Sensoren und Funkdecodierung sein.
Zur Not werde ich den Reset vom Watchdog vom AVR noch aktivieren.
Dazu muss aber ein neuer Bootloader auf den AVR. Daher würde ich das gerne vermeiden wenn es geht.
Hi,
ich krieg das Ding einfach nicht zum Fliegen...
Zitat von: Dirk am 09 April 2014, 23:14:04
Der Eventmonitor zeiht auch nix an?
Im Eventmonitor finde ich das hier:
2014-04-10 23:18:39 HMLAN HMLAN1 cond: timeout
2014-04-10 23:18:39 HMLAN HMLAN1 Xmit-Events: timeout:1
2014-04-10 23:18:39 HMLAN HMLAN1 prot_timeout: last
2014-04-10 23:18:39 HMLAN HMLAN1 DISCONNECTED
2014-04-10 23:18:39 HMLAN HMLAN1 cond: disconnected
2014-04-10 23:18:39 HMLAN HMLAN1 Xmit-Events: disconnected:1
2014-04-10 23:18:39 HMLAN HMLAN1 prot_disconnected: lastDas passiert immer kurz nachdem die rote LED mal kurz leuchtet.
Ich habe jetzt beim Pairen mal per Serial Monitor mitgeloggt. Da kommt das hier dabei raus:
<- 1A 01 A2 00 42 43 44 23 A3 F4 05 00 3D 4B 45 51 30 30 30 34 35 36 37 70 03 01 00 (l:27) (44296)
-> NA (44990)
-> 10 25 A0 01 23 A3 F4 42 43 44 00 05 00 00 00 00 00 (l:17) (46017)
<- 0A 25 80 02 42 43 44 23 A3 F4 00 (l:11) (46025)
-> NA (46719)
-> 13 26 A0 01 23 A3 F4 42 43 44 00 08 02 01 0A 23 0B A3 0C F4 (l:20) (47282)
<- 0A 26 80 02 42 43 44 23 A3 F4 00 (l:11) (47294)
-> 0B 27 A0 01 23 A3 F4 42 43 44 00 06 (l:12) (47587)
<- 0A 27 80 02 42 43 44 23 A3 F4 00 (l:11) (47593)
-> 10 28 A0 01 23 A3 F4 42 43 44 00 04 00 00 00 00 00 (l:17) (47888)
-> 10 28 A0 01 23 A3 F4 42 43 44 00 04 00 00 00 00 00 (l:17) (48087)
-> 10 28 A0 01 23 A3 F4 42 43 44 00 04 00 00 00 00 00 (l:17) (48286)
-> NA (48290)
<- 16 28 A0 10 42 43 44 23 A3 F4 02 01 00 02 01 0A 23 0B A3 0C F4 00 00 (l:23) (48302)
-> 0A 28 80 02 23 A3 F4 42 43 44 00 (l:11) (48439)
-> 0B 29 A0 01 23 A3 F4 42 43 44 01 03 (l:12) (48796)
<- 0E 29 A0 10 42 43 44 23 A3 F4 01 00 00 00 00 (l:15) (48802)
-> 0A 29 80 02 23 A3 F4 42 43 44 00 (l:11) (48945)
<- 1C 02 A2 70 42 43 44 23 A3 F4 00 E8 30 03 F0 00 00 0F 82 09 68 00 00 13 39 00 00 09 40 (l:29) (180706)
-> NA (181399)
Per "set HMLAN1 logIDs all,sys" bekomme ich das hier:
2014.04.10 23:13:01.453 0: HMLAN_Send: HMLAN1 I:K
2014.04.10 23:13:01.461 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851839 d:23A3F4 O:23A3F4 t:0001FC6B IDcnt:0000
2014.04.10 23:13:26.460 0: HMLAN_Send: HMLAN1 I:K
2014.04.10 23:13:26.468 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851839 d:23A3F4 O:23A3F4 t:00025E1D IDcnt:0000
2014.04.10 23:13:51.473 0: HMLAN_Send: HMLAN1 I:K
2014.04.10 23:13:52.479 0: HMLAN_Send: HMLAN1 I:K
2014.04.10 23:13:53.484 0: HMLAN_Send: HMLAN1 I:K
2014.04.10 23:13:54.489 0: HMLAN_Send: HMLAN1 I:K
2014.04.10 23:13:55.494 1: HMLAN_Parse: HMLAN1 new condition timeout
2014.04.10 23:13:55.527 1: 192.168.178.152:1000 disconnected, waiting to reappear
2014.04.10 23:13:55.544 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.04.10 23:14:00.569 1: 192.168.178.152:1000 reappeared (HMLAN1)
2014.04.10 23:14:00.571 0: HMLAN_Send: HMLAN1 I:A23A3F4
2014.04.10 23:14:00.573 0: HMLAN_Send: HMLAN1 I:C
2014.04.10 23:14:00.576 0: HMLAN_Send: HMLAN1 I:Y01,00,
2014.04.10 23:14:00.578 0: HMLAN_Send: HMLAN1 I:Y02,00,
2014.04.10 23:14:00.580 0: HMLAN_Send: HMLAN1 I:Y03,00,
2014.04.10 23:14:00.583 0: HMLAN_Send: HMLAN1 I:T1AD9C618,04,00,00000000
2014.04.10 23:14:00.585 1: HMLAN_Parse: HMLAN1 new condition init
2014.04.10 23:14:00.614 0: HMLAN_Send: HMLAN1 S:S4D7D7D6A stat: 00 t:00000000 d:01 r:4D7D7D6A m:99 8112 23A3F4 000001
2014.04.10 23:14:00.640 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851839 d:23A3F4 O:23A3F4 t:0000203A IDcnt:0000
2014.04.10 23:14:00.645 0: HMLAN_Parse: HMLAN1 R:R4D7D7D6A stat:0002 t:00000000 d:FF r:7FFF m:99 8112 23A3F4 000001
2014.04.10 23:14:00.646 1: HMLAN_Parse: HMLAN1 new condition ok
2014.04.10 23:14:02.754 0: HMLAN_Parse: HMLAN1 R:E21F923 stat:0000 t:000028B7 d:FF r:FFBC m:A4 8610 21F923 000000 0A90C30E0010Ich habe das Teil auch neu geflasht. Ein list ergibt jetzt das hier:
Internals:
DEF 424344
HMLAN1_MSGCNT 8
HMLAN1_RAWMSG R4D75285E,0001,0001FCD3,FF,FFC0,06A01042434423A3F40100000000
HMLAN1_RSSI -64
HMLAN1_TIME 2014-04-10 23:04:54
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 8
NAME CUL_HM_HM_WDS10_TH_O_424344
NR 85
STATE ???
TYPE CUL_HM
lastMsg No:06 - t:10 s:424344 d:23A3F4 0100000000
protLastRcv 2014-04-10 23:04:54
protSnd 9 last_at:2014-04-10 23:04:54
protState CMDs_done
rssi_at_HMLAN1 avg:-64.37 min:-66 max:-64 lst:-64 cnt:8
Readings:
2014-04-10 23:04:51 Activity alive
2014-04-10 23:04:53 CommandAccepted yes
2014-04-10 23:04:51 D-firmware 0.5
2014-04-10 23:04:51 D-serialNr KEQ0004567
2014-04-10 23:04:54 PairedTo 0x23A3F4
2014-04-10 23:04:54 R-burstRx off
2014-04-10 23:04:54 R-pairCentral 0x23A3F4
2014-04-10 23:04:54 RegL_00: 01:00 02:01 0A:23 0B:A3 0C:F4 00:00
Helper:
cSnd 0123A3F44243440103
mId 003D
peerIDsRaw ,00000000
rxType 132
Io:
newChn +424344,00,01,1E
nextSend 1397163894.71136
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1397163894.7051
ack:
HASH(0x10697d0)
06800223A3F442434400
Rssi:
At_hmlan1:
avg -64.375
cnt 8
lst -64
max -64
min -66
Shadowreg:
Attributes:
IODev HMLAN1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 0.5
model HM-WDS10-TH-O
peerIDs 00000000,
room CUL_HM
serialNr KEQ0004567
subType THSensor
Tja, was tun?
Gruß,
Thorsten
@Dirk
Die letzte 5 Sekunden-TestVersion läuft immer noch (und erzeugt megamäßige logs :) ). Mal sehen, ob sie die Nacht übersteht.
Grüße,
Alexander
@Thorsten
Versuche das Teil mal manuell anzulegen:
define WeatherSensor2 CUL_HM 6FB75E
attr WeatherSensor2 IODev CUL
attr WeatherSensor2 actCycle 000:10
attr WeatherSensor2 autoReadReg 4_reqStatus
attr WeatherSensor2 expert 2_full
attr WeatherSensor2 firmware 0.5
attr WeatherSensor2 model HM-WDS10-TH-O
attr WeatherSensor2 peerIDs.
attr WeatherSensor2 serialNr TLU0001002
attr WeatherSensor2 subType THSensor
Bei IODev, 6FB75E und TLU0001002 solltest du dann deine Daten eingeben.
Und dann beobachte mal den Eventmonitor
Zitat von: hexenmeister am 10 April 2014, 23:31:21
Die letzte 5 Sekunden-TestVersion läuft immer noch (und erzeugt megamäßige logs :) ). Mal sehen, ob sie die Nacht übersteht.
Na mal sehen.
Meiner läuft auch noch.
Hallo Dirk,
bei mir senden 10 Hm Geräte rum. Wobei unter Alive nur 7 in Fhem stehen ???
Den HM-USB hab ich erst seit 1,5 Monaten, vorher nutze ich den CUL, da hatte ich keinen Aussetzer beim übertragen.
Mal sehen.
Der Sensor ist bei den Versionen <0.5 ca 2-3 Tage gelaufen. Bei der 0.5 hatte ich den Absturz wohl heute während der HM weg war. bin aber nicht sicher.
Da läuft nun wieder der Test. Die Helligkeitsdaten sehen besser aus aber die anderen Werte sind heute bei mir "zappeliger" als mit den vorherigen SW Versionen kann aber Zufall sein.
(Siehe Anhang)
Nico
Hi Nico,
Zitat
Die Helligkeitsdaten sehen besser aus aber die anderen Werte sind heute bei mir "zappeliger" als mit den vorherigen SW Versionen kann aber Zufall sein.
Ich denke das sind normale Schwankungen
Beim Luftdruck habe ich auch mit anderen Sensoren öfffters mal "Zappler" um die +/- 1 hPa
Bei Luftdruck und Temperatur schätze ich das Ähnlich ein.
Stell deine Skalen mal so ein, dass die einen Größeren Bereich abdecken. Dann "zappelt" das nicht mehr so sehr.
Gruß
Dirk
Ganz kurz: meiner läuft immer noch! :D
Zitat von: hexenmeister am 11 April 2014, 05:54:31
Ganz kurz: meiner läuft immer noch! :D
Meine beiden auch.
Ich habe jetzt vermutlich auch eine Lösung gefunden und eine Erklärung warum es hier bei einigen funktioniert.
Der AVR bekommt vom C1101, wenn in dessen Empfangspuffer Daten stehen, einen Interrupt.
In der zugehörige ISR (Interupt Service Routine) wird das Auslesen des CC1101 und das decodieren der Daten vorgenommen.
Und das ist recht viel Code der entsprechend viel Zeit verbraucht.
Während der Code in der ISR ausgeführt wird, werden alle anderen Interrupts blockiert. Und vor allem im Timer0 werde Counter gezählt die nicht unwichtig sind.
Und wenn diese Counter nicht stimmen, kann viel Unsinn passieren.
Da das ganze natürlich nur Auswirkungen hat wenn wirklich Daten im CC1101 zur Abholung bereit liegen erklärt auch, warum dieses Problem nur auftritt, wenn in der Umgebung andere HM Geräte Senden.
Da in der "normalen" Firmware der Sensor nur alle 2-3 Min. aktiv ist, und somit nur dann in einem kurzen Zeitfenster für das ACK der Zentrale und für Daten anderer Geräte empfangsbereit ist, ist die Wahrscheinlichkeit recht gering dass es in dieser Zeit zu Störungen kommt. Vor allem da andere Geräte ja nur relativ selten Senden.
Die Test Firmware sendet alle 5 Sekunden. Und davon habe ich zwei hier liegen. Da ist die Wahrscheinlichkeit dass sich die beiden Sensoren gegenseitig stören natürlich entsprechend hoch.
Bei mir zu Hause habe ich noch eine HM-ES-PMSw1-Pl (Funksteckdose mit Energiemessung). Diese sendet recht häufig die Energiedaten zur Zentrale dürfte der Sensor, auch wenn er nur im 2-3 Min. Raster sendet deutlich öfters "gestört" werden.
@hexenmeister
Hast du zufällig auch so ein Teil in Betrieb, oder andere Geräte die recht häufig senden?
@Betateilchen und santalaus
Habt ihr so ein Teil?
Ich habe den Code mal entsprechend umgebaut.
Dieser sendet zum testen wieder im 5 Sekunden raster. Hier ist der Link:
https://www.dropbox.com/s/s7oejqy5exa459x/WetterSensor_test3.hex
Gruß
Dirk
Hallo Dirk,
ich habe die gleiche Funksteckdose einmal.
Dazu
5* HM-CC-RT-DN
1* HM-LC-Dim1TPBU-FM
1* HM-LC-Sw1PBU-FM
1* HM-LC-Sw2-FM
Nico
Zitat von: santalaus am 11 April 2014, 10:22:35
ich habe die gleiche Funksteckdose einmal.
Wie oft sendet die?
Bei mir komme ich auch schon mal auf 15 Sek.
Ich habe hier insgesamt über 50 HM-Komponenten im Einsatz, davon auch mehrere dieser Leistungsmesssteckdosen.
Das beeindruckt Deine Sensorplatine hier aber überhaupt nicht.
Kann mir mal jemand ein "list <sensorDevice>" posten - vielleicht gibt es einfach in der Anlage des Sensors selbst Optimierungsmöglichkeiten.
Zitat von: Dirk am 11 April 2014, 10:28:20
Wie oft sendet die?
Bei mir komme ich auch schon mal auf 15 Sek.
Das kannst Du doch einstellen?
Zitat von: betateilchen am 11 April 2014, 10:30:24
Das kannst Du doch einstellen?
Daher die Frage.
Mal abwarten was die Tests jetzt bringen. Die Interrupt-Problematik war jedenfalls existent. Ob die der Auslöser für das Problem ist, wird sich im Test der nächsten Stunden / Tage zeigen.
Wenn du willst kannst du ja mal die "WetterSensor_05_test" testen. Hier sendet der Sensor alle 5 Sek. Und ist danach auch kurz anfällig für das Problem.
Im "normalen" Modus dauert es deutlich länger bis der hängen bleibt.
Meine Leistungsmesser senden nur, wenn es auch etwas zu melden gibt:
(http://up.picr.de/17924974fk.png)
Hallo,
ich habe die Steckdose genommen, in Fhem eingebunden.
Die läuft einfach so aus der Box raus.
Ich hätte erwartet, das eq3 da schon recht optimale Einstellungen bzgl. senden vorgenommen hatte.
Nico
Ich lasse meine deutlich öfters senden.
Bei Spannungsänderungen +/- 1V
und Netzfrequenz +/- 0.1 Hz
und Mindestpause 5 sec.
Ich will es halt ganz genau wissen :)
Änderungen der Netzspannungen und der Netzfrequenz sind doch mit diesem Ding ohnehin nicht vernünftig/zuverlässig messbar - schon gar nicht im 1/10 Hz Bereich.
Mich interessiert nur, ob der Ofen angeschaltet ist (15 W für die Backofenlampe) und wenn ja, ob er gerade heizt (1600W).
ZitatHast du zufällig auch so ein Teil in Betrieb, oder andere Geräte die recht häufig senden?
Genau so ein Teil nicht, aber genug Thermostate, die sich auch alle 2-3 Minutes zu Wort melden. Der Bewegungsmelder ist auch ein gesprächiges Teil (alle 4 Minuten und bei jeder erkannten Bewegung).
Die Version von gestern ist immer noch online ;)
Also, wenn das Problem immer noch nicht gelöst sein soll, dass ist es zumindest wesentlich 'entschärft'.
Abends werde ich dann die neuste Firmware von heute draufbraten.
Aktuell senden die zwei Sensoren ziemlich gleichzeitig. Ab und zu bekommt einer auch kein ACK, weil der andere "strört". Das sieht man am langen leuchten der LED nach dem Senden. Derzeit sind beide noch unbeeindruckt und laufen mit der V 0.6.
0.6 ist auch als Hexfile im Git.
Wenn das so bis heute Abend läuft stelle ich das Update auch hier nochmal rein.
Andere Frage: Wieso braucht der Sensor überhaupt ein ACK?
Die Homematic Temperatursensoren senden ihre Wetterdaten einfach immer an "broadcast" und erwarten dafür keine Bestätigung - wozu auch?
lastMsg No:E6 - t:70 s:20DACD d:000000 008C48
ZitatAndere Frage: Wieso braucht der Sensor überhaupt ein ACK?
Weil es laut Register für den HM_WDS10_TH_O so vorgesehen ist.
Wenn ich die Infos vom Martin unten so verarbeitet habe , dass in FHEM auch eigene Devices eingebaut werden können,
Könnte man das ggf. Ändern.
Zitat von: Dirk am 11 April 2014, 11:47:59
Weil es laut Register für den HM_WDS10_TH_O so vorgesehen ist.
Da wette ich aber locker dagegen.
Meine HM_WDS10_TH_O (Original!) senden immer an broadcast. Genau wie die WDS40 übrigens auch. Und von broadcast gibt es naturgemäß kein ACK. Und ja, die Sensoren sind alle korrekt gepairt!
Nur der Nachbau verhält sich da anders, der versucht, an die gepairte Zentrale zu schicken und ein ACK zu bekommen, was in meinen Augen völlig sinnlos ist.
ZitatlastMsg
No:6F - t:70 s:6FB75D d:127000 00DF0003F5000000000B5C0000AF2B0000AE2B
ZitatNur der Nachbau verhält sich da anders, der versucht, an die gepairte Zentrale zu schicken und ein ACK zu bekommen, was in meinen Augen völlig sinnlos ist.
Zumindest schickt FHEM auch ein ACK.
Ich muss mal sehen wie sich die CCU da verhält.
Du bist sicher, dass der Originalsensor an Broadcast senden nachdem er gepairt wurde?
Ich muss mich doch mal in das Protokoll einarbeiten. Das hab ich bisher noch nicht gemacht.
Die Registererstellungen stammen alle aus Trilu's Beispielcode.
Zitat von: Dirk am 11 April 2014, 12:03:07
Du bist sicher, dass der Originalsensor an Broadcast senden nachdem er gepairt wurde?
Ja. Das Verhalten habe ich auch schon mehrmals hier im Forum beschrieben.
klingt seltsam - ist aber so.
Liegt wahrscheinlich bei temp-sensoren an der Aufgabenstellung: Mehrere Peers bedienen, die ggf auf wakeup reagieren. Dann aber nicht zu viele messages generieren.... Wenn sie doch nicht Reagieren ist ein Wiederholen sinnlos... man muss eh bis zum nächsten mal warten.
Warum man den peer in Temp-fühlern einträgt ist mir (noch) nicht klar.
Zitat von: martinp876 am 11 April 2014, 13:28:05
Warum man den peer in Temp-fühlern einträgt ist mir (noch) nicht klar.
Tut man gar nicht. Nach einem Peering ist im Sensor kein Peer eingetragen. Allerdings wird der Temperaturfühler als Peer in der Gegenstelle eingetragen, damit diese weiß, auf welchen Temperatursensor sie hören muss.
Zitat von: Dirk am 10 April 2014, 23:33:46
@Thorsten
Versuche das Teil mal manuell anzulegen:
...
Und dann beobachte mal den Eventmonitor
Hi,
das habe ich jetzt gemacht (mit HMLAN1 als IODev). Keine Änderung. Das hier steht im Eventmonitor kurz nachdem die LED flackert:
2014-04-11 21:43:30 CUL_HM og_wz_Temperatur dewpoint: 11.7
2014-04-11 21:44:04 HMLAN HMLAN1 cond: timeout
2014-04-11 21:44:04 HMLAN HMLAN1 Xmit-Events: timeout:1
2014-04-11 21:44:04 HMLAN HMLAN1 prot_timeout: last
2014-04-11 21:44:04 HMLAN HMLAN1 DISCONNECTED
2014-04-11 21:44:04 HMLAN HMLAN1 cond: disconnected
2014-04-11 21:44:04 HMLAN HMLAN1 Xmit-Events: disconnected:1
2014-04-11 21:44:04 HMLAN HMLAN1 prot_disconnected: last
2014-04-11 21:44:07 HMLAN HMLAN1 cond: init
2014-04-11 21:44:07 HMLAN HMLAN1 Xmit-Events: init:1
2014-04-11 21:44:07 HMLAN HMLAN1 prot_init: last
2014-04-11 21:44:07 HMLAN HMLAN1 CONNECTED
2014-04-11 21:44:07 HMLAN HMLAN1 cond: ok
2014-04-11 21:44:07 HMLAN HMLAN1 Xmit-Events: ok:1
2014-04-11 21:44:07 HMLAN HMLAN1 prot_ok: last
2014-04-11 21:44:14 HTTPMOD Heizkessel VLSoll: 30Tja...
Ich versuche jetzt mal eine andere Firmware-Version.
Gruß,
Thorsten
Hi,
jetzt habe ich die 0.4er ausprobiert, ohne Erfolg.
Mit der 0.2er Firmware funktioniert's auf Anhieb:
2014-04-11_22:16:02 CUL_HM_HM_WDS10_TH_O_6FB75D temperature: 22.9
2014-04-11_22:16:02 CUL_HM_HM_WDS10_TH_O_6FB75D battery: ok
2014-04-11_22:16:02 CUL_HM_HM_WDS10_TH_O_6FB75D humidity: 47
2014-04-11_22:16:02 CUL_HM_HM_WDS10_TH_O_6FB75D airpress: 1005
2014-04-11_22:16:02 CUL_HM_HM_WDS10_TH_O_6FB75D lux: 34.6
2014-04-11_22:16:02 CUL_HM_HM_WDS10_TH_O_6FB75D T: 22.9 H: 47 AP: 1005 Lux: 34.6
Ich habe den Eindruck, dass die 0.4er und 0.5er Version meinem HMLAN ganz große Probleme bereitet. Wahrscheinlich kennst Du (Dirk) die Unterschiede zwischen 0.2 und 0.4 am besten.
Ansonsten würde ich mir das ganze auch gerne selbst mal anschauen. Allerdings habe ich nur die 0.2er Sourcen. Kannst Du mir einen Link zu Deinem git geben? (Ich glaube, Du hattest erwähnt, dass das in einem git liegt.)
Gruß,
Thorsten
https://github.com/kc-GitHub/Wettersensor
Hi @all,
Die beiden Sensoren laufen nun schon über einen Tag ohne Ausfall.
Daher gehe ich davon aus, das das Hängenbleiben-Problem nun gelöst ist.
Anbei sind die neuen Hex-Files mit der Version 0.6
Es gibt hier 2x2 unterschiedliche Versionen.
WetterSensor_06.hex ist die Firmware so wie bisher mit der Device-ID vom HM_WDS10_TH_O
WetterSensor_06_test.hex das selbe mit Sendeinterval von 5 Sek. falls noch jemand Testen möchte
WetterSensor_06_type-F101.hex ist eine Version mit einem neuen Device-Type
WetterSensor_06_type-F101_test.hex das Selbe mit Senmdeinterval von 5 Sek.
Durch den eigenen Device-Type muss CUL_HM nicht mehr gepatcht werden (Fast)
Es muss noch ein kleiner Patch gemacht werden.
Diese Version wird so von der CCU noch nicht erkannt.
Für die CCU will ich auch noch eine Unterstützung zur Verfügung stellen.
Gleich zu Beginn vom 10_CUL_HM.pm etwa an Zeile 10 muss nach der Zeile
use HMConfig;Diese Zeile eingefügt werden:
use HMConfig_additionalDevices;Ausserdem muss die Datei HMConfig_additionalDevices.pm ins FHEM-Verzeichniss kopiert werden.
Dadurch kann CUL_HM den neuen Device-Type interpretieren. Folgende Readings gibt es hier:
- Temperatur
- Luftfeuchte
- Luftdruck
- Luftdruck-NN
- Helligkeit
- Batteriespannung
Abhängig von den bestückten Sensoren sollten nur die relevanten Readings sichtbar sein.
Temperatur wird aber immer Übertragen. Bei fehlendem Sensor kommt dann 0.
Luftdruck-NN ist nur Verfügbar, wenn das Globale Attribute "altitude" gesetzt ist und wenn der Luftdrucksensor bestückt ist.
@Martin,
Ich habe noch keine sinnvolle Lösung gefunden die Datei anders einzubinden. Über 99_... klappt es so nicht. Die Modellist und die Subtypelist muss erweitert werden.
Hast du eine Idee wie wir das ohne Patch hinbekommen?
@thorsten,
Testest du bitte mal die 0.6er Version.
Ich habe aktuell keine Idee warum die 0.2er Version bei dir läuft und die anderen nicht.
So groß waren die Änderungen nicht.
Blöderweise habe ich den Codeerst ab V0.4 oder 0.5 auf Github
Gruß
Dirk
Update:Anhang gelöscht. Der Link zur letzten Firmware ist jetzt immer hier:
https://github.com/kc-GitHub/Wettersensor/raw/master/Tools/Firmware/Flash-Tool-Windows.zip
Zitat von: Dirk am 12 April 2014, 02:48:32
Gleich zu Beginn vom 10_CUL_HM.pm etwa an Zeile 10 muss nach der Zeile
Diese Zeile eingefügt werden:
use HMConfig_additionalDevices;
Ausserdem muss die Datei HMConfig_additionalDevices.pm ins FHEM-Verzeichniss kopiert werden.
....
@Martin,
Ich habe noch keine sinnvolle Lösung gefunden die Datei anders einzubinden. Über 99_... klappt es so nicht. Die Modellist und die Subtypelist muss erweitert werden.
Hast du eine Idee wie wir das ohne Patch hinbekommen?
Das mit dem Einbinden ist eigentlich kein Problem.
Aber man sollte das unbedingt in ein eval {} packen, sonst zerschießt dieser Patch die komplette fhem-Konfiguration bei Anwendern, die die zusätzliche Datei gar nicht benötigen und/oder diese Datei nicht auf Ihrem Sytem haben. Beispiele für diese Vorgehensweise gibt es z.B. in fhem.pl (fallweises Einbinden der configDB.pm, falls das jemand nutzen möchte) und in 32_mailcheck.pm (feststellen, welche Zusatzfunktionen zur Verfügung gestellt werden können).
Die Frage ist ausserdem, ob man das Einbinden der Zusatzdatei wirklich in 10_CUL_HM.pm machen will oder ob man das nicht in die HMConfig.pm verlegt.
Genau diese Punkte möchte ich noch klären.
Das sollte kein genereller Patch sein.
Am liebsten hätte ich diese File dynamisch eingebunden. Das muss aber CUM_HM machen.
Da Modellist und Subtypelist erweitert werden müssen.
Hi,
@Betateilchen: Danke.
Zitat von: Dirk am 12 April 2014, 02:48:32
@thorsten,
Testest du bitte mal die 0.6er Version.
Ich habe aktuell keine Idee warum die 0.2er Version bei dir läuft und die anderen nicht.
So groß waren die Änderungen nicht.
Blöderweise habe ich den Codeerst ab V0.4 oder 0.5 auf Github
Die 0.6er werde ich ausprobieren.
Den 0.2er Code habe ich, den hast Du mir mal per Mail geschickt.
Vielleicht hilft auch folgende Beobachtung weiter: Das ganze läuft bei mir auf einer Fritz!Box 7390. Wenn der Sensor sendet, dann hat nicht nur FHEM Probleme damit, sondern mein ganzes Netzwerk scheint kurz zusammenzubrechen. (Ich habe gestern parallel einen Film über T-Entertain aufgenommen und der hatte alle ungefähr 2,5 Minuten einen Aussetzer von ein paar Sekunden.)
Außerdem haben die beiden grünen LEDs vom HM-LAN manchmal wie verrückt geblinkt.
Mein "echter" HM-Sensor hat diese Probleme übrigens nicht.
Gruß,
Thorsten
Zitat von: Dirk am 12 April 2014, 09:51:48
Das sollte kein genereller Patch sein.
Die grundsätzliche Einbindung (das "use") sollte per eval fest erfolgen.
Das dynamische Laden des Erweiterungsmoduls könnte man dann über verschiedene Wege steuern. (sowas gibt es auch für die configDB Erweiterung, die nur geladen wird, wenn sie wirklich gebraucht/benutzt wird)
ZitatMein "echter" HM-Sensor hat diese Probleme übrigens nicht.
Sehr interessant. Ich habe auch ähnliche Probleme. Ich weiss jetzt nicht seit welcher Version, aber ich habe Störungen gemerkt. Zuletzt waren diese so heftig, dass ich den Sensor erstmal deaktiviert habe. Bin je Paar Tage weg, kann nicht ständig fhem beruhigen:)
Mein hmlan blinkt heftig, die rote led leuchtet lange, dann scheint es Sich zurebooten. Manchmal blieb sogar so hängen. Und ständige disconnects, die sind nach dem Stillegen verschwunden.
Irgedndwas scheint mir dem Protokoll nicht zu stimmen.
Insgesamt spinnt mein hmlan letzte Zeit. Mal änderte sich die MAC-adresse, so dass der router neue ip vergeben hat, dann ging dhcp gar nicht mehr. Habe ip fest vergeben... Und die serialnummer änderte sich plötzlich auf ree999999 o.ä. Das ist aber eher die Auswirkung nach dem firmware Update. Ansonsten tut aber... Bin etwas verwirrt :o
Lg
Alexander
Zitat von: hexenmeister am 12 April 2014, 12:55:46Mal änderte sich die MAC-adresse, so dass der router neue ip vergeben hat, dann ging dhcp gar nicht mehr. Habe ip fest vergeben... Und die serialnummer änderte sich plötzlich auf ree999999 o.ä. Das ist aber eher die Auswirkung nach dem firmware Update. Ansonsten tut aber... Bin etwas verwirrt :o
Die Probleme habe ich nicht. Ich hatte vorher schonmal von Problemen beim Firmware-Update des HMLAN gelesen und habe es dann bleiben lassen, da ja alles funktioniert hat. Mein HMLAN hat Firmware 0.961.
Gruß,
Thorsten
Ich mache heute abend noch mal einen Test mit dem HM-LAN.
Zumindest mit dem CUL und auch an meiner CCU1 (als HM_WDS10_TH_O) gibt es aktuell keine Probleme.
In den letzten Versionen waren noch zusätzliche Bytes am Frame mit dran die ich zum debugen genutzt hatte.
Die sind in der 0.6er wieder raus. Vielleicht störte sich der HM-LAN daran?
@Betateilchen
Was sagt dein USB-Config-Adapter dazu?
Zitat von: betateilchen am 12 April 2014, 12:12:56
Die grundsätzliche Einbindung (das "use") sollte per eval fest erfolgen.
Das ist schon klar. Ich würde das aber gerne so gestalten dass man ggf. auch mehrere Erweiterungsdateien einhängen kann ohne CUL_HM oder HMConfig zu patchen.
Daher hat Martin vielleicht eine Idee wie wir das generischer machen
Das Laden muss aber nach HMConfig erfolgen und bevor CUL_HM initialisiert wird.
Gruß
Dirk
Zitat von: Dirk am 12 April 2014, 13:25:56
@Betateilchen
Was sagt dein USB-Config-Adapter dazu?
Mit Version 0.5 bisher keinerlei Auffälligkeiten.
Ich hatte weiter oben schonmal darum gebeten, einmal ein "list <device>" zu posten - leider wurde das wohl übersehen. Vielleicht könnte man darin schon Auffälligkeiten erkennen.
Zitat von: betateilchen am 12 April 2014, 13:29:10Ich hatte weiter oben schonmal darum gebeten, einmal ein "list <device>" zu posten - leider wurde das wohl übersehen.
Hi,
das habe ich schon zweimal gemacht, z.B. hier:
http://forum.fhem.de/index.php/topic,20620.msg157916.html#msg157916 (http://forum.fhem.de/index.php/topic,20620.msg157916.html#msg157916)
Gruß,
Thorsten
Zitat von: betateilchen am 12 April 2014, 13:29:10
Ich hatte weiter oben schonmal darum gebeten, einmal ein "list <device>" zu posten - leider wurde das wohl übersehen. Vielleicht könnte man darin schon Auffälligkeiten erkennen.
Hier von mir:
Internals:
CUL_MSGCNT 6
CUL_RAWMSG A1424A2706FB74DF1123400EE3003E5000186600A00::-18:CUL
CUL_RSSI -18
CUL_TIME 2014-04-12 13:44:59
DEF 6FB74D
IODev CUL
LASTInputDev CUL
MSGCNT 6
NAME CUL_HM_UWS_THPL_6FB74D
NR 75
STATE T: 23.8 H: 48 Lux: 999 P: 997 P-NN: 1017 batVoltage: 2.56
TYPE CUL_HM
lastMsg No:24 - t:70 s:6FB74D d:F11234 00EE3003E5000186600A00
protLastRcv 2014-04-12 13:44:59
rssi_at_CUL avg:-18 min:-18 max:-18 lst:-18 cnt:6
Readings:
2014-04-12 13:44:35 .D-devInfo 030100
2014-04-12 13:44:35 .D-stc 70
2014-04-12 13:44:59 .protLastRcv 2014-04-12 13:44:59
2014-04-12 13:44:35 Activity alive
2014-04-12 13:44:35 D-firmware 0.6
2014-04-12 13:44:35 D-serialNr XLU0001002
2014-04-12 02:09:53 R-pairCentral set_0x1ACAE5
2014-04-12 13:33:10 RegL_00: 0
2014-04-12 13:44:59 batVoltage 2.56
2014-04-12 13:44:59 battery ok
2014-04-12 13:44:59 humidity 48
2014-04-12 13:44:59 lux 999
2014-04-12 13:44:59 pressure 997
2014-04-12 13:44:59 pressure-nn 1017
2014-04-12 13:44:59 state T: 23.8 H: 48 Lux: 999 P: 997 P-NN: 1017 batVoltage: 2.56
2014-04-12 13:44:59 temperature 23.8
Helper:
mId F101
rxType 132
Io:
newChn +6FB74D,00,01,1E
nextSend 1397303099.43017
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_cul:
avg -18
cnt 6
lst -18
max -18
min -18
Attributes:
IODev CUL
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 0.6
model UWS-THPL
peerIDs
room CUL_HM
serialNr XLU0001002
subType THPLSensor
Ich kann das das Problem mit dem HM-LAN auch in der 0.6er Firmware bestätigen.
Der HM-LAN bootet neu wenn er Packete vom Sensor empfängt.
Aus meiner Sicht ist das auch eine böse Sicherheitslücke im HM-LAN.
Denn so kann ich mit einem kleinen Sender in der Nähe eine ganze Hausautomatisierung ggf. incl. Alarmanlage ganz, aber mindestens teilweise außer Gefecht setzen.
@Thorsten,
Kannst du mir die 0.2er nochmal zukommen lassen.
Ich glaube die hab ich gar nicht mehr
Gruß
Dirk
Zitat von: Dirk am 12 April 2014, 13:49:00
Ich kann das das Problem mit dem HM-LAN auch in der 0.6er Firmware bestätigen.
Ok, dann fühle ich mich zumindest nicht mehr alleine.
Zitat
Der HM-LAN bootet neu wenn er Packete vom Sensor empfängt.
Erklärt das auch, warum mein komplettes Netzwerk in dem Moment spinnt?
Zitat
Kannst du mir die 0.2er nochmal zukommen lassen.
...ist hier drangehängt.
EDIT: Anhang entfernt, um Verwirrungen zu vermeiden.
Gruß,
Thorsten
Tipp von mir:
Das Attribut autoReadReg maximal auf 3 setzen, noch besser auf 0 (zumindest bei diesem Selbstbausensor!).
Dann warte ich mal mit dem Update auf 0.6, zumal die 0.5 bei mir völlig problemlos läuft.
ZitatDas Attribut autoReadReg maximal auf 3 setzen, noch besser auf 0 (zumindest bei diesem Selbstbausensor!).
Kannst du da noch etwas zum Hintergrund sagen? Also wieso?
Die Register sind von der Ursprungsversion. Da babe ich nix geändert.
Daher vermute ich mal, das wird an dem HM-LAN-Problem nix ändern.
Kannst du mal ein List <device> vom Originalsensor Posten. Oder gab es das hier schon mal?
Gruß
Dirk
Zitat von: Dirk am 12 April 2014, 14:42:32
Kannst du da noch etwas zum Hintergrund sagen? Also wieso?
Wenn ich das jetzt hier schreibe, krieg ich wieder Prügel von martin.
Internals:
CFGFN
DEF 20DACD
IODev wz_HMUSB
LASTInputDev wz_HMUSB
MSGCNT 894
NAME out_Balkon
NR 133
STATE T: 15.3 H: 58
TYPE CUL_HM
az_HMUSB_MSGCNT 446
az_HMUSB_RAWMSG E20DACD,0000,0599452B,FF,FFB6,6B867020DACD00000000993A
az_HMUSB_RSSI -74
az_HMUSB_TIME 2014-04-12 14:42:54
lastMsg No:6B - t:70 s:20DACD d:000000 00993A
protLastRcv 2014-04-12 14:42:55
rssi_at_az_HMUSB avg:-67.89 min:-82 max:-62 lst:-74 cnt:446
rssi_at_wz_HMUSB avg:-44.61 min:-47 max:-39 lst:-40 cnt:448
wz_HMUSB_MSGCNT 448
wz_HMUSB_RAWMSG E20DACD,0000,058C330E,FF,FFD8,6B867020DACD00000000993A
wz_HMUSB_RSSI -40
wz_HMUSB_TIME 2014-04-12 14:42:55
CHANGETIME:
Helper:
Dblog:
Dewpoint:
Fhemdblog:
TIME 1397306574.92893
VALUE 7.1
Humidity:
Fhemdblog:
TIME 1397306574.92893
VALUE 58
Temperature:
Fhemdblog:
TIME 1397306574.92893
VALUE 15.3
Readings:
2014-04-11 19:27:05 Activity alive
2014-04-08 20:03:17 D-firmware 1.3
2014-04-08 20:03:17 D-serialNr KEQ0174839
2014-04-12 14:42:54 battery ok
2014-04-12 14:42:54 dewpoint 7.1
2014-04-12 14:42:54 humidity 58
2014-04-12 14:42:54 state T: 15.3 H: 58
2014-04-12 14:42:54 temperature 15.3
2014-04-12 14:42:55 testreading bla
Helper:
mId 003D
rxType 132
Io:
newChn +20DACD,00,01,1E
nextSend 1397306575.10319
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_az_hmusb:
avg -67.8946188340807
cnt 446
lst -74
max -62
min -82
At_wz_hmusb:
avg -44.6160714285714
cnt 448
lst -40
max -39
min -47
Shadowreg:
Attributes:
IODev wz_HMUSB
actCycle 000:10
actStatus alive
autoReadReg 0_off
expert 2_full
firmware 1.3
group Sensoren
model HM-WDS10-TH-O
peerIDs 00000000,
room 19 Balkon
serialNr KEQ0174839
subType THSensor
Zitat von: betateilchen am 12 April 2014, 14:45:27
Wenn ich das jetzt hier schreibe, krieg ich wieder Prügel von martin.
Wieso? Dann schick mir ne Mail oder PM.
gibt es Probleme beim selbstbausensor und autoReadReg?
Wer es nicht mag, kann es abschalten - muss die Daten selbst abholen.
AutoReadReg 5 sollte die Daten konsistent halten - auch bei Selbstbausensoren (so wie es auch die HM SW macht).
Wer das nicht will darf es straf-frei abschalten.
Wenn es Probleme gibt würde ich es gerne wissen... sonst wird es nicht verbessert.
Hi,
kann mir mal jemand einen Tipp geben, wie ich die Sourcen übersetzt bekomme? Mit der kleinen Arduino-Entwicklungsumgebung klappt's nicht. Das Teil hat anscheinend Probleme mit dem Präprozessor (verschachtelte Includes und Libraries). Ich denke mal, dass da was mit Eclipse geht, aber da habe ich noch weniger hinbekommen.
Kann mir mal jemand ein Stichwort liefern?
Danke&Gruß,
Thorsten
Mein Sensor (V 0.5) ist nun auch abgestürzt...
Zitat von: martinp876 am 12 April 2014, 18:04:34
gibt es Probleme beim selbstbausensor und autoReadReg?
Wer es nicht mag, kann es abschalten - muss die Daten selbst abholen.
AutoReadReg 5 sollte die Daten konsistent halten - auch bei Selbstbausensoren (so wie es auch die HM SW macht).
Wer das nicht will darf es straf-frei abschalten.
Wenn es Probleme gibt würde ich es gerne wissen... sonst wird es nicht verbessert.
Martin, konntest du meine Frage weiter vorne wegen dem Einbinden der Datei dir schon ansehen?
Zitat von: Thorsten Pferdekaemper am 12 April 2014, 19:20:54
kann mir mal jemand einen Tipp geben, wie ich die Sourcen übersetzt bekomme? Mit der kleinen Arduino-Entwicklungsumgebung klappt's nicht.
wenn du die Arduino-IDE nimmst, musst du alles was sich unter Library in dein lokales Arduino-Lib-Verzeichniss kopieren.
Die erweiterte AskSin-Lib ist ein Subrepo.
Ansonsten kann ich dir das Arduino-Plugin für Eclipse empfehlen, falls du Eclipse benutzt.
Mit der Arduino-IDE kann man eigentlich nicht Arbeiten.
Zitat von: betateilchen am 12 April 2014, 21:00:59
Mein Sensor (V 0.5) ist nun auch abgestürzt...
V0.6 Stürtz nicht mehr ab. und das Problem mit dem HM-Lan hat die 0.5er auch.
Da bin ich wie gesagt noch dran.
Gruß
Dirk
Ein HM-Jammer als Nebenprodukt ist ja auch mal was ;)
Aber Spass beiseite, das ist in der Tat ein böser Bug in hmlan. Ob die CCU auch betroffen sind?
ich habe dieses Problem weder mit HM-USB noch mit einer CCU2.
Und nochwas: Der USB Programmieradapter ist definitiv zu klein - zumindest für meinen Schreibtisch. Der Adapter ist spurlos verschwunden *grummel*
Fielmann?
das ist NICHT witzig...
Zitat von: Dirk am 12 April 2014, 02:48:32
WetterSensor_06.hex ist die Firmware so wie bisher mit der Device-ID vom HM_WDS10_TH_O
WetterSensor_06_test.hex das selbe mit Sendeinterval von 5 Sek. falls noch jemand Testen möchte
äh... WetterSensor_06.hex sendet bei mir aber auch alle 5 Sekunden...
Hallo,
kann ich bestätigen. Ich bin dann direkt zu dem mit dem neuen Devicetype gewechselt. Der läuft nun seit gestern Mittag
Nico
Da der Sensor bei mir in der Produktivinstallation eingebunden ist und ich nur einen dieser Senoren habe, will ich nicht bei jedem Update von fhem HM-Modulen das Patchen wieder von Hand nachziehen zu müssen. Deshalb kommt der Einsatz des neuen Devicetyp für mich erst dann in Frage, wenn die Erweiterung fest implementiert ist.
Zitat von: Dirk am 12 April 2014, 21:18:06wenn du die Arduino-IDE nimmst, musst du alles was sich unter Library in dein lokales Arduino-Lib-Verzeichniss kopieren.
Mit der Arduino-IDE hagelt's nur Fehlermeldungen, wie z.B.:
In file included from WetterSensor.ino:5:
Register.h:18: error: braces around scalar initializer for type 'uint8_t'
Register.h:18: error: invalid conversion from 'int' to 'const uint8_t*'
Register.h:18: error: invalid conversion from 'const uint8_t*' to 'uint8_t'(Das ist von der 0.2er Version des Sensors.)
Welche Arduino-IDE-Version hast Du? Vielleicht liegt hier das Problem.
ZitatAnsonsten kann ich dir das Arduino-Plugin für Eclipse empfehlen, falls du Eclipse benutzt.
Mit der Arduino-IDE kann man eigentlich nicht Arbeiten.
Meinst Du das Plugin hier: http://www.baeyens.it/eclipse/ (http://www.baeyens.it/eclipse/) ?
Damit quäle ich mich seit einigen Stunden herum, aber ich bekomme das auch nicht zum Fliegen. Ein primitiv-Testscript lässt sich übersetzen, aber das Teil findet die Header nicht (Z.B. #include <Wire.h>). Ich habe alle Header sowohl im Standard-Arduino Library-Folder liegen, als auch in meinem "privaten" Library Folder.
Weiß da jemand Rat?
EDIT: Hab's gefunden. Man muss die Libraries erst "Importieren".
Gruß,
Thorsten
Die 0.6 mit eigenem Typ zeigt bei mir Werte für Lux und Batteriespannung an. Ich habe aber gar keinen Lichtsensor und ob die Spannungsmessung wirklich korrekt ist, weiss ich auch nicht.
(http://up.picr.de/17944693am.png)
Hallo betateilchen,
ich wollte Dir gerade schreiben, das ich mir das auch überlegt hatte. Dann aber feststellte, das der neue DevTyp mit dem use eintrag IMHO einfacher zu patchen ist.
Aber Du hast das ja schon vorgenommen ;)
Ich kann das nciht nachvollziehen, da ich einen Vollständig bestückten Sensor habe.
Diese ist wg dem Lux Messer und meinen Bastelleien allerdings noch offen. Hoffentlich kommen die PIRs bald.
Nico
Zitat von: santalaus am 13 April 2014, 12:04:42
Diese ist wg dem Lux Messer und meinen Bastelleien allerdings noch offen. Hoffentlich kommen die PIRs bald.
Meiner hängt schon seit ein paar Tagen im Flur :)
(http://up.picr.de/17945138sq.jpg)
*lach* jetzt weiss ich auch, woher die zweitweisen Unterschiede zwischen Dirks pressure-nn und meinem pressure-nn kommen: Ich nutze die komplexere barometrische Formel, nicht die simple :)
Hier ein paar Vorschläge zu der zusätzlichen HMConfig-Datei
1. bitte einen kürzeren Namen wählen, bei mir heißt die jetzt HMConfig_add.pm
2. Soweit ich das sehe, ist Lux immer 1000, wenn kein Lichtsensor existiert? Dann sollte sich so das überflüssige Reading unterdrücken lassen:
if ($lux < 100001 && $lux != 1000) {
3. Aus Performancegründen würde ich die Abhandlung des Luftdrucks so umsetzen:
# air pressure
if ($pressure) {
$stateMsg .= ' P: ' . $pressure;
push (@events, [$shash, 1, 'pressure:' . $pressure]);
# my $altitude = AttrVal('global', 'altitude', 0);
my $altitude = $attr{global}{altitude};
if ($altitude) {
my $pressureNN = $altitude ? sprintf('%.0f', ($pressure + ($altitude / 8.5))) : 0;
# if ($pressureNN) {
$stateMsg .= ' P-NN: ' . $pressureNN;
push (@events, [$shash, 1, 'pressure-nn:' . $pressureNN]);
}
}
Zitat von: betateilchen am 13 April 2014, 02:05:11
äh... WetterSensor_06.hex sendet bei mir aber auch alle 5 Sekunden...
Hm, ich check das nacher mal, kann gut sein dass ich das Hex-File verwechselt habe.
ZitatDeshalb kommt der Einsatz des neuen Devicetyp für mich erst dann in Frage, wenn die Erweiterung fest implementiert ist.
Leider ist Martin noch nicht auf meine Fragen hierzu eingegangen.
Ich habe aber folgenden Vorschag:
CUL_HM sollte unmittelbar nach HMConfig automatisch alle Files laden die mit "HMConfig_" beginnen.
Dann kann jeder der ein eigenes Device baut seine eigenen Types definieren.
Ich würde CUL_HM mal entsprechend umbauen und Martin den Patch schicken.
Oder hat jemand einen anderen Vorschlag?
Zitat
Die 0.6 mit eigenem Typ zeigt bei mir Werte für Lux und Batteriespannung an. Ich habe aber gar keinen Lichtsensor und ob die Spannungsmessung wirklich korrekt ist, weiss ich auch nicht.
Da gibt es wohl noch einen kleinen Bug.
Eigentlich sollte bei fehlenden Lichtsensor 100.001 Lux gemeldet werden. Der eigene DeviceType sollte dann kein Reading melden.
Zitat
Ich nutze die komplexere barometrische Formel, nicht die simple :)
Das ist die gleiche Formel wie in I2C_BMP180. Da hast du dich nicht beschwehrt :)
Zitat1. bitte einen kürzeren Namen wählen, bei mir heißt die jetzt HMConfig_add.pm
Wenn wir es Umsetzen wie unten vorgeschlagen könnte man auch "HMConfig_<type>" nehmen.
Zitat2. Soweit ich das sehe, ist Lux immer 1000, wenn kein Lichtsensor existiert? Dann sollte sich so das überflüssige Reading unterdrücken lassen:
Sollte es, ist noch ein Bug.
Zitat3. Aus Performancegründen würde ich die Abhandlung des Luftdrucks so umsetzen:
Ich kann gerne auch deine komplexere Formel einbauen.
Welche ist das?
Gruß
Dirk
Zitat von: Dirk am 13 April 2014, 13:47:54
CUL_HM sollte unmittelbar nach HMConfig automatisch alle Files laden die mit "HMConfig_" beginnen.
Ich würde CUL_HM mal entsprechend umbauen und Martin den Patch schicken.
Da bin ich aber gespannt. Und ich bin nach wie vor der Meinung, dass HMConfig das Nachladen machen sollte und nicht CUL_HM.
Zitat von: Dirk am 13 April 2014, 13:47:54
Das ist die gleiche Formel wie in I2C_BMP180. Da hast du dich nicht beschwehrt :)
Da habe ich auch nie in den Quelltext geschaut, um rauszufinden, wie Du das machst. Ausserdem war das keine Beschwerde.
Zitat von: Dirk am 13 April 2014, 13:47:54
Ich kann gerne auch deine komplexere Formel einbauen.
Lohnt sich aus Performance- und Ressourcengründen nicht.
Die Differenz tritt eh nur selten auf und die Abweichung ist maximal +/- 1 hPa.
ZitatUnd ich bin nach wie vor der Meinung, dass HMConfig das Nachladen machen sollte und nicht CUL_HM.
Von mir aus auch in der HMConfig am Ende.
Wichtig ist, das die Daten da sind bevor CUL_HM die Modellist und die TypeList baut.
ZitatLohnt sich aus Performance- und Ressourcengründen nicht.
Auf welche Platform beziehst du dich da? Ist deine Formel so komplex? Währ ne FB damit schon überfordert?
Ich halte die Genauigkeit Deiner einfachen Formel für völlig ausreichend.
sub relDruck($){
# Messwerte
my ($Pa) = @_;
my $Temp = ReadingsVal('BMP180','temperature',20);
my $Alti = AttrVal('global','altitude',0);
# Konstanten
my $g0 = 9.80665;
my $R = 287.05;
my $T = 273.15;
my $Ch = 0.12;
my $a = 0.065;
my $E = 0;
if($Temp < 9.1){
$E = 5.6402*(-0.0916 + exp(0.06 * $Temp));
} else {
$E = 18.2194*(1.0463 - exp(-0.0666 * $Temp));
}
my $xp = $Alti * $g0 / ($R*($T+$Temp + $Ch*$E + $a*$Alti/2));
my $Pr = $Pa*exp($xp);
return int($Pr);
}
Zitat von: Dirk
Wenn wir es Umsetzen wie unten vorgeschlagen könnte man auch "HMConfig_<type>" nehmen.
...
Von mir aus auch in der HMConfig am Ende.
Wichtig ist, das die Daten da sind bevor CUL_HM die Modellist und die TypeList baut.
Beispielsweise so? (am Ende der HMConfig.pm einzufügen)
my $mp = "./FHEM";
opendir(DH, $mp) || return;
foreach my $m (sort readdir(DH)) {
next if($m !~ m/^HMConfig_(.*)\.pm$/);
no strict "refs";
my $ret = eval { do "./FHEM/$m"; };
use strict "refs";
}
closedir(DH);
HMConfig Loading: HMConfig_001.pm
HMConfig Loading: HMConfig_002.pm
HMConfig Loading: HMConfig_THPL.pm
Hallo,
ich habe mal etwas mit dem HM-LAN experimentiert.
Sobald der Sensor mehr als 17 Bytes Payload in einem Frame sendet, rebootet der HM-LAN reproduzierbar.
darunter ist alles ok.
Ab Version 0.3 oder 0.4 (weiß nicht mehr genau) hatte ich noch ein paar Bytes zusätzliche Debugging-Infos mit gesendet.
Das waren 20 Bytes.
In der Version > 0.5 werden nur 11 Bytes versendet. Diese Versionen sind also ok und auch mit HM-LAN verwendbar.
Zitat von: betateilchen am 13 April 2014, 02:05:11
äh... WetterSensor_06.hex sendet bei mir aber auch alle 5 Sekunden...
WetterSensor_06.hex und WetterSensor_06_test.hex waren identisch.
Zitat von: betateilchen am 13 April 2014, 15:23:02
Beispielsweise so? (am Ende der HMConfig.pm einzufügen)
my $mp = "./FHEM";
opendir(DH, $mp) || return;
foreach my $m (sort readdir(DH)) {
next if($m !~ m/^HMConfig_(.*)\.pm$/);
no strict "refs";
my $ret = eval { do "./FHEM/$m"; };
use strict "refs";
}
closedir(DH);
Kleine Ergänzung, damit man auch sieht wenn man Fehler im Code hat:
my $mp = "./FHEM";
opendir(DH, $mp) || return;
foreach my $m (sort readdir(DH)) {
next if($m !~ m/^HMConfig_(.*)\.pm$/);
no strict "refs";
my $file = "./FHEM/$m";
my $ret = do $file;
if(!$ret) {
main::Log3 undef, 1, "Error loading file: $file:\n $@";
}
use strict "refs";
}
closedir(DH);
@Martin kannst du das so in HMConfig einbauen?
Oder soll ich das machen.
Ich würde dann HMConfig_THPL.pm einchecken.
Zitat von: betateilchen am 13 April 2014, 13:24:17
2. Soweit ich das sehe, ist Lux immer 1000, wenn kein Lichtsensor existiert? Dann sollte sich so das überflüssige Reading unterdrücken lassen:
Da ist mir wohl der Wert um 2 Kommastellen verrutscht.
Es gibt nun Version 0.7.
Dies überträgt dann auch den richtigen Wert wenn kein Helligkeitssensor da ist, und wenn der Sensor gesättigt ist.
Die aktuellste Version der Firmware ist jetzt immer hier:
https://github.com/kc-GitHub/Wettersensor/raw/master/Tools/Firmware/Flash-Tool-Windows.zip
Gruß
Dirk
Sieht nach einem typischen Pufferüberlauf aus. Wir sollen es an Elv/Eq3 melden. Evtl. gibt es dann eine korrigierte Version.
Grüße,
Alexander
Zitat von: Dirk am 14 April 2014, 02:30:52
Kleine Ergänzung, damit man auch sieht wenn man Fehler im Code hat:
...
@Martin kannst du das so in HMConfig einbauen?
Oder soll ich das machen.
(http://us.cdn2.123rf.com/168nwm/ppart/ppart1012/ppart101200017/8476748-stop-schild-isolated-on-white.jpg)
Das eval {} hatte ich nicht zum Spaß eingebaut, das solltest Du unbedingt drinlassen.
Wenn Du schon irgendwas zum Loggen haben willst (ich hatte das während meiner Tests einfach mit print() gemacht), dann bitte nur so:
my $ret = eval {
my $ret=do "$file";
if(!$ret) {
main::Log 1, ""Error loading file: $file:\n $@";";
return $@;
}
}
Zitat von: hexenmeister am 14 April 2014, 04:17:45
Sieht nach einem typischen Pufferüberlauf aus. Wir sollen es an Elv/Eq3 melden. Evtl. gibt es dann eine korrigierte Version.
*g* die Antwort kann ich mir gut vorstellen: "Wir haben keine Homematic Komponenten, die mehr als 17 Byte payload senden"
(natürlich nur eine Vermutung)
Zitat von: betateilchen am 14 April 2014, 09:45:48
Das eval {} hatte ich nicht zum Spaß eingebaut, das solltest Du unbedingt drinlassen.
Ist aber an dieser Stelle völlig unnötig, da das File ja da ist.
Es geht nicht darum, zu prüfen, ob das File da ist oder nicht.
Wenn in dem File etwas drinsteht (z.B. Perl Syntaxfehler), das fhem zum Absturz bringt (und das passiert schneller als Du denkst) kriegst Du davon im aufrufenden Modul nichts mehr mit und hast auch nix zum Loggen.
Wenn es nur darum ginge, die Existenz eines Files zu prüfen, bräuchte man eval nicht, sondern könnte das viel einfacher testen: if(! -r "$file");
Zitat von: betateilchen am 14 April 2014, 09:50:08
Wenn in dem File etwas drinsteht (z.B. Perl Syntaxfehler), das fhem zum Absturz bringt (und das passiert schneller als Du denkst) kriegst Du davon im aufrufenden Modul nichts mehr mit und hast auch nix zum Loggen.
Do macht das selbe wie Eval. Nur eben für externe Dateien. Daher ist das unnötig das doppelt zu machen.
Zitat von: Dirk am 14 April 2014, 09:54:13
Do macht das selbe wie Eval. Nur eben für externe Dateien. Daher ist das unnötig das doppelt zu machen.
glaubst DU ...
(meinetwegen lass es halt so, bis die ersten User hier aufschlagen und rummaulen, und Du es dann doch ändern wirst.)
Zitat von: betateilchen am 14 April 2014, 10:01:01
glaubst DU ...
Auch perldoc mein das :)
http://perldoc.perl.org/functions/do.html
Zitat
*g* die Antwort kann ich mir gut vorstellen: "Wir haben keine Homematic Komponenten, die mehr als 17 Byte payload senden"
Vermutlich. Oder gibt es schon eine neuere Version der Firmware vom HM-LAN?
Zitat von: Dirk am 14 April 2014, 10:04:57
Vermutlich. Oder gibt es schon eine neuere Version der Firmware vom HM-LAN?
Aber eigentlich geht es doch nicht darum, ob die Herrschaften von eq3 solche Komponenten haben, sondern vielmehr darum, dass es aufgrund einer fehlenden Längenprüfung (ach... woher kenn ich das nur), möglich ist, das System in Schach zu halten.
Also gerade im Moment vielleicht ein guter Zeitpunkt, dass man erhört wird. :-)
Hallo,
Funktioniert eigentlich der neue HM Lan Adapter schon mit FHEM? Habt ihr diesen schon auf die "Lücke" getestet?
http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/homematic-funk-lan-gateway.html (http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/homematic-funk-lan-gateway.html)
Ich denke für den alten nun zu "Lan Konfigurationsadapter" umbenannten werden die nur "ungern" ein Firmware Update machen (haben die jemals gerne ihre Fehler behoben?), egal wie sehr das Herz auch blutet...
LG
Franz
Hi,
die 0.7er Firmware funktioniert jetzt auch bei mir.
Hier ein paar Details, falls es interessiert:
Wie gesagt, ich habe jetzt die 0.7er-Version mit eigenem Subtyp am Laufen
flash.cmd COM16 WetterSensor_07_type-F101.hex 6F:B7:5E TLU0001002
Damit der eigene Subtyp funktioniert habe ich die 10_CUL_HM.pm wieder auf's Original zurückgesetzt und dann das hier ans Ende der HMConfig.pm gehängt:
my $mp = "./FHEM";
opendir(DH, $mp) || return;
foreach my $m (sort readdir(DH)) {
next if($m !~ m/^HMConfig_(.*)\.pm$/);
no strict "refs";
my $file = "./FHEM/$m";
my $ret = do $file;
if(!$ret) {
main::Log3 undef, 1, "Error loading file: $file:\n $@";
}
use strict "refs";
}
closedir(DH);
Dann habe ich mir die Datei HMConfig_additionalDevices.pm aus Dirk's git (https://github.com/kc-GitHub/Wettersensor (https://github.com/kc-GitHub/Wettersensor)) geholt, nach HMConfig_THPL.pm umbenannt und ins FHEM Verzeichnis kopiert.
Jetzt shutdown restart und den Sensor angelernt. Das hat auf Anhieb funktioniert und auch das Logfile zeigt keine Auffälligkeiten.
Hier ist noch ein list vom Sensor:
Internals:
CFGFN
DEF 6FB75E
HMLAN1_MSGCNT 23
HMLAN1_RAWMSG E6FB75E,0000,0CECF84A,FF,FFC8,10A2706FB75E23A3F400E42E03EE000000D20962
HMLAN1_RSSI -56
HMLAN1_TIME 2014-04-14 10:22:20
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 23
NAME DirksSensor
NR 111
STATE T: 22.8 H: 46 Lux: 2.1 P: 1006 batVoltage: 2.40
TYPE CUL_HM
lastMsg No:10 - t:70 s:6FB75E d:23A3F4 00E42E03EE000000D20962
protLastRcv 2014-04-14 10:22:20
protSnd 23 last_at:2014-04-14 10:22:20
protState CMDs_done
rssi_at_HMLAN1 avg:-65.26 min:-73 max:-56 lst:-56 cnt:23
Readings:
2014-04-14 09:44:46 Activity alive
2014-04-14 09:44:43 CommandAccepted yes
2014-04-14 09:44:42 D-firmware 0.7
2014-04-14 09:44:42 D-serialNr TLU0001002
2014-04-14 09:44:43 PairedTo 0x23A3F4
2014-04-14 09:44:43 R-burstRx off
2014-04-14 09:44:43 R-pairCentral 0x23A3F4
2014-04-14 09:44:43 RegL_00: 01:00 02:01 0A:23 0B:A3 0C:F4 00:00
2014-04-14 10:22:20 batVoltage 2.40
2014-04-14 10:22:20 battery ok
2014-04-14 10:22:20 humidity 46
2014-04-14 10:22:20 lux 2.1
2014-04-14 10:22:20 pressure 1006
2014-04-14 10:22:20 state T: 22.8 H: 46 Lux: 2.1 P: 1006 batVoltage: 2.40
2014-04-14 10:22:20 temperature 22.8
Helper:
cSnd 0123A3F46FB75E0103
mId F101
peerIDsRaw ,00000000
rxType 132
Io:
newChn +6FB75E,00,01,1E
nextSend 1397463741.02145
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1397463740.9384
ack:
HASH(0x107f5d8)
10800223A3F46FB75E00
Rssi:
At_hmlan1:
avg -65.2608695652174
cnt 23
lst -56
max -56
min -73
Shadowreg:
Attributes:
IODev HMLAN1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 0.7
model UWS-THPL
peerIDs 00000000,
room z_Prototyp
serialNr TLU0001002
subType THPLSensor
Ich habe das Teil jetzt zum Test neben einen HM-WDS40-TH-I gehängt und mir ein FileLog definert, das mir erlaubt, die beiden zu vergleichen. Ich weiß nicht, wie genau die Sensoren sein sollen, aber ich glaube dass der neue Sensor immer eine etwas höhere Temperatur und niedrigere Feuchtigkeit anzeigt.
...aber jetzt muss ich erst einmal abwarten, was ein Test über längere Zeit bringt.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 14 April 2014, 10:28:36
Ich habe das Teil jetzt zum Test neben einen HM-WDS40-TH-I gehängt und mir ein FileLog definert, das mir erlaubt, die beiden zu vergleichen. Ich weiß nicht, wie genau die Sensoren sein sollen, aber ich glaube dass der neue Sensor immer eine etwas höhere Temperatur und niedrigere Feuchtigkeit anzeigt.
Um wie viel weichen die Daten ab? Die Sensoren haben halt alle Toleranzen.
Der SHT10 misst die Temperatur laut Datenblatt bei 25 °C mit etwa 0,5 °C genau.
Die Feuchte ist mit einer Toleranz von +/- 4,5% angegeben.
Jetzt müsste man wissen was für Sensoren im HM-WDS40-TH-I stecken.
Gruß
Dirk
Zitat von: Dirk am 14 April 2014, 11:42:30
Um wie viel weichen die Daten ab? Die Sensoren haben halt alle Toleranzen.
Der SHT10 misst die Temperatur laut Datenblatt bei 25 °C mit etwa 0,5 °C genau.
Die Feuchte ist mit einer Toleranz von +/- 4,5% angegeben.
Das ganze scheint sich einzupendeln. Seit die beiden Sensoren nebeneinendar hängen, nähern sich die Werte an. Seit der letzten Stunde liegt die Temperatur nur noch maximal 0.1 Grad auseinander. Momentan zeigen sie sogar beide 22.1 Grad an.
Die Feuchtigkeit liegt nur noch 2 Prozentpunkte auseinander. (Neuer Sensor: 48%, Original-HM: 50%.)
Das liegt also locker innerhalb der Toleranz.
Anscheinend muss man solche Sensoren wirklich mal irgendwo hinhängen und dann in Ruhe lassen. Auf dem Schreibtisch messen die Dinger wahrscheinlich nur abgestrahlte Körperwärme und sonstige Ausdünstungen. (SCNR...)
Gruß,
Thorsten
Korrekte Luftfeuchtigkeit hat bei elektronischen Sensoren bei mir bisher immer viele Stunden nach der Inbetriebnahme gedauert - nach 24 Stunden sollte der Wert einigermaßen zuverlässig sein.
Zitat von: betateilchen am 14 April 2014, 11:56:04
Korrekte Luftfeuchtigkeit hat bei elektronischen Sensoren bei mir bisher immer viele Stunden nach der Inbetriebnahme gedauert - nach 24 Stunden sollte der Wert einigermaßen zuverlässig sein.
Ja, ich weiß. Korrekte Messung der Luftfeuchtigkeit ist schwierig.
Ich habe mir ein Diagramm zum Vergleich gebaut. (Siehe Attachment.) Mal sehen, wie das morgen Abend aussieht.
Gruß,
Thorsten
was geht es Dich eigentlich an, wie feucht Dirk ist :P
Zitat von: betateilchen am 14 April 2014, 12:24:01was geht es Dich eigentlich an, wie feucht Dirk ist :P
Sowas hätte ich mir denken können.
...und außerdem hat er ganz schlimm Untertemperatur.
Hallo,
nett und freundlich bei eq3 anfragen. Wenn die nicht wollen, ab damit nach fulldisclosure. IMHO müssen Sie dann.
Sowas gehört gefixed.
Nico
Zitat von: betateilchen am 14 April 2014, 12:24:01
was geht es Dich eigentlich an, wie feucht Dirk ist :P
Mein Feuchtigkeitsgehalt liegt aktuell innerhalb der Toleranzgrenzen :)
Hi,
so, mein Vergleich mit einem "richtigen" HM-Sensor lief jetzt über einen ganzen Tag. Der Anhang zeigt das Ergebnis seit Mitternacht. (Meine FileLogs sind immer nur für den aktuellen Tag.)
Man kann sehen, dass der Originalsensor und der von Dirk kaum voneinander abweichen. Bei der Temperatur sind's maximal 0.3 Grad, wobei sich die Unterschiede über die Zeit wahrscheinlich sogar fast komplett ausgleichen. Womöglich liegt es einfach daran, dass die Gehäuse unterschiedlich durchlüftet sind.
Besser geht's wahrscheinlich nicht.
Bei der Feuchtigkeit ist Dirks Sensor immer 2 bis 3 Prozentpunkte niedriger. Ich denke mal, dass das auch kaum besser geht.
Luftdruck: wetter.com zeigt momentan 1026mBar an für meinen Wohnort. Laut Wikipedia bin ich ungefähr 121m hoch (nein, nicht ich...). Das ergibt dann ungefähr 1026 - 121/8,5 -> 1012. Der Sensor sagt 1013, auch gut.
Bei der Helligkeit kann ich nicht sagen, ob das hinkommt. Ich habe das Gehäuse geschlossen und keinen Lichtleiter oder ähnliches eingebaut. Trotzdem kann das Teil hell und dunkel unterscheiden. Ich habe die Rolläden so gegen 8:00 hochgezogen...
Ob die heftigen Schwankungen so sein müssen kann ich nicht sagen.
@Dirk: Hast Du schon eine Empfehlung von wegen Lichtleiter durchs Gehäuse?
Batteriespannung passt auch. Ich habe NiMH-Akkus drin, da dürfte jeder momentan so 1,2V haben.
Gruß,
Thorsten
Hi Thorsten,
Zitat
Bei der Helligkeit kann ich nicht sagen, ob das hinkommt. Ich habe das Gehäuse geschlossen und keinen Lichtleiter oder ähnliches eingebaut. Trotzdem kann das Teil hell und dunkel unterscheiden. Ich habe die Rolläden so gegen 8:00 hochgezogen...
Ob die heftigen Schwankungen so sein müssen kann ich nicht sagen.
Bei der Helligkeitsmessung im geschlossenen Gehäuse habe ich schon etwas experimentiert.
Bin aber noch nicht ganz fertig.
Deine Helligkeitswerte "sieht" der Sensor nur über die oberen Gehäuseschlitze. Für einfache Hell- / Dunkelmessungen sollte das sogar schon ausreichen.
Aktuell benutze ich als "Lichtleiter" einen 5mm Acrylstab der oben zu einer kleinen Halbkugel geformt ist. Diese schaut dann am Gehäuse raus.
Damit bekomme ich schon ganz gute Werte.
Eine direkte Ableitung der Helligkeit in Lux ist somit natürlich nicht mehr gegeben. Hierfür muss man den Wert umrechnen. Im einfachsten verhält sich das liniar. Im ungünstigen Fall muss man eine Vergleichsmessung zur Umrechnung heranziehen.
Für einfache Automatisierungsfunktionen reicht aber auch die Lösung aus, welche keine Umrechnung benutz. Man muss sich dafür aber eigene Schwellwerte festlegen.
Gruß
Dirk
Gibts denn eigentlich schon eine Planung, ob/wann die vorgeschlagene Änderung zum Nachladen der Typ-Dateien in die HMConfig.pm eingebaut wird?
Bisher hat Martin auch die Vorschläge hier nicht regiert bzw. hat der die wohl übersehen.
Ich werde ihn mal direkt anschreiben.
Gruß
Dirk
Hi,
vielleicht kannst Du ihn auch auf den AskSin-Thread hinweisen. Ich glaube, da sucht jemand nach einer ähnlichen Lösung.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 15 April 2014, 18:43:00
Bei der Helligkeit kann ich nicht sagen, ob das hinkommt. Ich habe das Gehäuse geschlossen und keinen Lichtleiter oder ähnliches eingebaut.
Hallo Thorsten,
d.h. die Helligkeit wird bei Dir in der Grafik direkt in lux angegeben. Da das Gehäuse aber "blickdicht" ist, kommt so wenig raus. Ist das korrekt so? Mit 20-50 lux wäre es mir persönlich zu dunkel ...
Gruß Peter
Zitat von: PeMue am 16 April 2014, 22:01:03
d.h. die Helligkeit wird bei Dir in der Grafik direkt in lux angegeben. Da das Gehäuse aber "blickdicht" ist, kommt so wenig raus. Ist das korrekt so? Mit 20-50 lux wäre es mir persönlich zu dunkel ...
Die Zahl vor Lux stimmt ohne Umrechnung nur, wenn der Sensor direkt beleuchtet wird. Also ohne Gehäuse.
Zitat von: PeMue am 16 April 2014, 22:01:03d.h. die Helligkeit wird bei Dir in der Grafik direkt in lux angegeben. Da das Gehäuse aber "blickdicht" ist, kommt so wenig raus. Ist das korrekt so? Mit 20-50 lux wäre es mir persönlich zu dunkel ...
Ja, das Gehäuse ist ziemlich geschlossen, da kommt ziemlich wenig Licht rein. Ich mag's auch eher hell...
Hallo Dirk,
wie würde sich dann das Gehäuse des Außensensors auswirken? Ist ja transparent, aber die optische "Dämpfung" kennt man ja auch nicht? Bezüglich Kalibrierung in W/m^2 würde ich an einem strahlenden Sommertag einfach die Kurve mit den Karlsruher Messungen (http://imkbemu.physik.uni-karlsruhe.de/~ws_uni/) vergleichen und kalibrieren.
Irgendwelche berechnete Kurven habe ich (noch?) nicht gefunden.
Gruß Peter
Hi PeMue,
Zitatwie würde sich dann das Gehäuse des Außensensors auswirken? Ist ja transparent, aber die optische "Dämpfung"
Um das genau zu beantworten müsste man eine Messreihe mit 2 Sensoren, mit und ohne Abdeckung machen.
Dazu bin ich noch nicht gekommen. dazu hätte ich gerne mal von morgen bis abends keine Wolken.
ZitatBezüglich Kalibrierung in W/m^2 würde ich an einem strahlenden Sommertag einfach die Kurve mit den Karlsruher Messungen vergleichen und kalibrieren.
Oder so. dann reicht auch 1 Sensor.
Da bei voller Sonneneinstrahlung der Sensor übersteuert, muss aber ein Filter davor.
Da bin ich auch noch am experimentieren.
Gut hat sich bisher ein einfaches Blatt 80g Papier gezeigt. Ich will aber nochmal ein paar Tests mit anderen "Filtern" machen.
Gruß
Dirk
Hallo,
Der Sensor läuft nun auch an der CCU mit allen Werten.
Dafür wird dann wieder ein Firmwareupdate nötig sein, da es in der 0.7er Firmware Probleme mit dem Pairing gibt.
Wenn ich es schaffe, stell ich das heute Abend rein.
Gruß
Dirk
Die Darstellung der Temperatur sieht aber "komisch" aus. Ich kann dann ja mal gegen die CCU2 testen :)
Zitat von: betateilchen am 17 April 2014, 13:15:04
Die Darstellung der Temperatur sieht aber "komisch" aus. Ich kann dann ja mal gegen die CCU2 testen :)
Ich vermute das Liegt am Raspberry der da drunter läuft.
Zum Testen auf meiner CCU1 bin ich noch nicht gekommen.
Hat sich martin eigentlich inzwischen schon geäußert? Es kommt von ihm ein Update der HMConfig nach dem anderen, aber vom Nachlademechanismus keine Spur - ich muss das jedesmal manuell nachziehen.
Mist, vergessen.
Hab aber grade ne PM an Martin gesendet.
Hi,
Den Vorschlag hatte ich nicht gelesen ... sorry.
Prinzipiell sicher ok - kann ich einbauen.
Vor solchen grundsätzlichen Dingen denke ich gerne noch einmal nach...
- User können sich eigenen Devices bauen (siehe Panstamp Projekte) und müssen diese einlagern
- der TH-sensor Eigenbau ist sicher etwas gewichtiger, fällt aber unter diese Kategorie
? Ist die Filestruktur so ok? Ein File für ein neues Device?
? Soll das File eingecheckt werden oder wird es dem User "geliefert", falls er sein eigenes Device baut/kopiert?
? Sollte dies in ein Unterverzeichnis abgelegt werden?
? welche Daten werden im File enthalten sein?
- registerdefinition
- register usage
- Kommando usage
- Kommando - definition (noch nicht implementiert)
- parser-routinen
Im Prinzip müsste sich auch alles in 99_myUtil einbauen lassen. Die Änderungen der Strukturen sollten vor dem Lesen der Attribute abgearbeitet sein - und somit rechtzeitig (habe es nicht getestet, aber sollte so sein, hoffe ich).
Also wenn ihr meint, dass es so passt und sicher seit, dass es ein Weg für alle User ist - und ihr meint dass es so stabil ist, dass man es einchecken kann/soll baue ich es ein.
Wird es code-varianten geben, die weitere Anpassungen zur Folge haben werden - und hinten nach ist alles eh User-spezifisch? Dann wäre einchecken nicht der Weg. Dann sollte man das File einfach mit dem Device ausliefern.
Ist eure Entscheidung.
Gruss Martin
Die Lösung wie wir sie hier vorgeschlagen haben, ist zumindest eine der wenigen Lösungen, die tatsächlich fhem-konform wäre. Auch was die Verzeichnis- und Datenstruktur angeht.
Ein Einbau in die 99_myUtils dürfte vermutlich viel zu spät greifen. Und das Risiko, dass die User dort etwas zerschießen, was die Funktionalität von Homematic Komponenten blockiert, ist sehr viel höher, als wenn ein Developer, dem ich durchaus das Wissen zuspreche, zu wissen was er tut, eine entsprechende HMConfig für seine Hardware eincheckt, die er mit Sicherheit auch getestet haben wird. Die Verantwortlichkeiten sehe ich dabei sehr viel klarer definiert, als wenn man die User auf die 99_myUtils losläßt.
Und die Lösung ist einfach soweit offen, dass zusätzliche Hardwaredefinitionen, deren Implementierung sich an Deine HMConfig-Konventionen hält, ohne weiteres Zutun automatisch mitgeladen werden. Ich denke schon, dass eine Verteilung auf dem regulären Update-Weg die beste Lösung sein wird.
für die panstamp devices mache ich es so das pro device model ein eigenes fhem modul geben kann das automatisch nachgeladen wird sobald sich so ein device das erste mal meldet und per define/autocreate angelegt wird. zwischen dem generischen swap modul und den spezialisierten gibt es eine art mini api mit dem das spezielle modul initialize und define des generischen verwenden und teilweise überschreiben kann sowie sich in die set, get und parse funktionen eingängen und diese erweitern kann.
ich weiß nicht wie viel davon auf hm passt (da die swap register definition eh zur laufzeit aus einem XML file gelesen wird) aber vor allem das automatische nachladen sobald das device auftaucht würde ich für wichtig erachten. ein neustart fände ich unschön.
gruss
andre
Zitat von: martinp876 am 17 April 2014, 18:43:20
- User können sich eigenen Devices bauen (siehe Panstamp Projekte) und müssen diese einlagern
Ich habe bisher keinen gangbaren Weg gefunden incl. dem Erweitern der Modellist und Subtypelist.
Daher dieser Vorschlag.
Zitat? Ist die Filestruktur so ok? Ein File für ein neues Device?
? Soll das File eingecheckt werden oder wird es dem User "geliefert", falls er sein eigenes Device baut/kopiert?
? Sollte dies in ein Unterverzeichnis abgelegt werden?
Das könnte man noch mal besprechen.
Prinzipiell ist die Idee weitreichend.
Man kann allgemeine Devices-Devinitionen mit FHEM ausliefern. Ggf. im Contrib-Verzeichniss oder auch selber erstellen und manuell verteilen sofern es nur um eine Handvoll Devices geht
Zitat? welche Daten werden im File enthalten sein?
- registerdefinition
- register usage
- Kommando usage
- Kommando - definition (noch nicht implementiert)
- parser-routinen
Auch das könnten wir noch definieren und ggf. später ausbauen.
ZitatIm Prinzip müsste sich auch alles in 99_myUtil einbauen lassen.
Die Modellist und die Subtypelist konnte ich hier nicht erweitern, so dass sie auch zur Verfügung steht wenn CUL_HM initialisiert wird.
Zitat von: justme1968 am 17 April 2014, 18:57:50
für die panstamp devices mache ich es so das pro device model ein eigenes fhem modul geben kann das automatisch nachgeladen wird sobald sich so ein device das erste mal meldet und per define/autocreate angelegt wird.
Das währ für HM auch eine Idee. Allerdings wohl mit recht viel Umbau verbunden.
Gruß
Dirk
Ein extra Neustart ist nicht notwendig.
Da die Erweiterungen per Update kommen und nach einem Update ohnehin ein Neustart notwendig wird, stehen danach auch die Erweiterungen zur Verfügung. Und seien wir mal realistisch: es werden nicht jeden Tag zehn neue Devices hinzukommen.
Und es ist eine Lösung, die auch ohne autocreate funktioniert.
ein neustart ist nur notwendig wenn ein bereits existierendes modul ein update bekommt. wenn ein neues modul per update kommt ist eigentlich kein neustadt nötig.
selbst wenn nicht jeden tag zehn neue devices dazu kommen kann ich dir versichern der entwickler der auch nur ein einziges neues device baut wird sehr sehr dankbar sein wenn es mit so wenig neustarts wie nur möglich geht. da ist ein einfaches neu laden mit der erweiterungen und der device definition wirklich ist da wirklich sehr hilfreich.
autocreate ist keine pflicht und da hm autocreate sowieso nicht bzw. nur zum teil verwendet hier auch nicht so wichtig.
nochmal: es ist überhaupt nie ein Neustart notwendig.
ein neustart/restart ist notwendig, wenn man Konfigdaten ändet (HMConfig). Die werden zumindest in Teilen nur einmal beim Booten bearbeitet - aus Performancegründen.
Für Funktionen trifft dies nicht zu, die (meisten) werden bei den Aktionen ausgeführt.
Im Prinzip ist Panstamp nichts anders - daher wäre ein einheitliches Vorgehen schön.
Der User kann in diesen Datenstrukturen alles zerschießen, genau wie ihr, da das Nachladen alles Überschreiben darf (so ist FHEM eben). Bei Panstamp werden die Daten geladen, wenn ein entsprechendes Device erstellt wird - das ist nicht so schlecht. In eurem Fall bekommt jeder die Erweiterungen zu dem Eigenbau mit. Und wenn es weitere Devices gibt, auch die.
Falls ihr bei diesem Konzept bleiben wollt solltet ihr strikt auf die Regeln achten. Es betrifft alle HM User (im Gegensatz zu Panstamp).
Wenn ihr ein File je eigenbau-HM-device machen wollt schlage ich vor, dass es all-inclusiv ist, also alles beinhaltet, was dieses Device benötigt.
Zitat von: martinp876 am 17 April 2014, 20:13:49
ein neustart/restart ist notwendig, wenn man Konfigdaten ändet (HMConfig).
Bitte definiere "neustart/restart" aus Deiner Sicht, bevor wir wieder tagelang aneinander vorbeireden.
Zitat von: martinp876 am 17 April 2014, 20:13:49
Falls ihr bei diesem Konzept bleiben wollt solltet ihr strikt auf die Regeln achten. Es betrifft alle HM User (im Gegensatz zu Panstamp).
Nicht wenn die entsprechenden Files über Contrib ausgeliefert werden.
Dann muss jeder der es nutzen will erst altiv werden.
Dennoch finde ich die Methode die Panstamp verwendet interessant.
Allerdings währ es ganz gut wenn wir kurzfristig eine Lösung finden.
Man kann es ja später ggf. Umbauen.
Contrib wäre insoweit unschön, dass keine
automatischen updates stattfinden.
Ich erkenne gerade das Problem nicht, um das es hier überhaupt geht.
hm - seltsame Frage. Restart ist, wenn alle Init Prozeduren ausgeführt werden und alle internen Daten gelöscht werden. FHEM macht das bei boot, shutdown restart und auch bei rereadCfg.
HMConfig hat eigentlich keinen Code - somit werde ich das Lesen weiterer files in CUL_HM implementieren. Macht mehr Sinn, meine ich.
Ein Problem sehe ich, wenn zum einbinden eines selbstbau-device ein File in .FHEM eingecheckt werden muss. Der aktuell gebaute Sensor sit sicher ein besonderer... dennoch ein Selbstbau. Ggf - im Falle von Konflikten - muss sich der Selbstbau dem HM-Konzept unterordnen.
Ich sehe somit zu wenig Flexibilität für User.
Mit einem Schnellschuss der jetzt gerade passt baut man sich Historie auf, die bei einem breit verteilten System auf Dauer Probleme macht. Die meisten scheinen das hier zu verstehen und zu beachten. Die (wenigen) anderen sehen nie Probleme.
Ich habe es erst einmal eingebaut.
Betreffend die Kalibrierung der Heligkeitssensoren:
Das Problem liegt etwas tiefer, als hier vermutet - haben wir schon mal an anderer Stelle diskutiert. Denn die Sensoren sind typischerweise auch im Infraroten empfindlich, ein Blatt Papier hingegen hat im Infrarotbereich ein ganz andere Transmission, als im sichtbaren Bereich.
Die Frage ist also: Was soll gemessen werden ?
- Die solare Einstrahlung auf Flächen bestimmter Neigung ? Das ist sinnvoll für PV-Anlagen, mache ich bei mir auch.
- Die Globalstrahlung ?
- Die empfundene Helligkeit ? Die wird aber z.B. nicht in Lux gemessen, sondern in Lumen
LG
pah
Zitat von: Prof. Dr. Peter Henning am 18 April 2014, 17:23:33
Denn die Sensoren sind typischerweise auch im Infraroten empfindlich, ein Blatt Papier hingegen hat im Infrarotbereich ein ganz andere Transmission, als im sichtbaren Bereich.
Der Sensor hat sowohl einen Kanal für IR+Visible und einen Kanal für IR.
Mit einer Formel laut Datenblatt werden die gemessenen Werte direkt in Lux umgewandelt.
Da muss auch nix mehr kalibriert werden.
Bei direkter Sonneneinstrahlung übersteuert der Sensor aber.
Daher muss für diesen Anwendungsfall dann ein Filter davor.
Gruß
Dirk
Einspruch.
Lux sind Lumen pro Quadratmeter, und das Lumen ist eindeutig auf das menschliche Auge bezogen.
Eine Infrarothelligkeit in Lux anzugeben ist also prinzipiell unsinnig - es sei denn, man legt ein ganz bestimmtes Spektrum zu Grunde und benutzt den IR-Einfall, um die sichtbare Helligkeit abzuschätzen.
Das geht zwar bei direktem Sonnenlicht, das ein thermisches Spektrum bei ca. 5.500 K aufweist. Aber spätestens bei bedecktem Himmel ist das nur noch sehr vage gegeben.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 18 April 2014, 17:38:54
Lux sind Lumen pro Quadratmeter, und das Lumen ist eindeutig auf das menschliche Auge bezogen.
Hat doch auch keiner was anderes behauptet.
ZitatEine Infrarothelligkeit in Lux anzugeben ist also prinzipiell unsinnig
Der Sensor benutzt seine IR-Photodiode lediglich um die Helligkeit entsprechend dem menschlichen Sehvermögen zu berechnen.
Magst du mal in das Datenblatt schauen?
http://media.digikey.com/pdf/Data%20Sheets/Austriamicrosystems%20PDFs/TSL256x.pdf
Gruß
Dirk
Update:
Mein gekauftes Helligkeitsmessgerät welches die Helligkeit übrigens auch in Lux angibt misst so ziemlich die selben Werte wie der Sensor.
Daher gehe ich davon aus, dass die Messung stimmt.
Das Datenblatt habe ich vorher schon angesehen - der Sensor nimmt einfach ein thermisches Spektrum an.
Vielleicht reden wir aneinander vorbei, mein Punkt ist nämlich nur: Wenn Du einen Filter unbekannter spektraler Charakteristik davorsetzt, kann das beliebig daneben gehen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 18 April 2014, 17:56:47
Wenn Du einen Filter unbekannter spektraler Charakteristik davorsetzt, kann das beliebig daneben gehen.
Das ist klar.
Daher ist die Idee: eine Weile einen "nackten" Sensor neben einen mit "Filter" zu legen und beide Kurven dann zur Korrektur heran zu ziehen. Es sei denn die Werte des Sensors mit "Filter" verhalten sich annähernd liniar. Was vermutlich nicht der Fall sein wird. Mal sehen Die Tage werde ich mal einen Versuch starten
Gruß
Dirk
Hallo Dirk,
welches Referenzgerät nimmst Du für die Helligkeit?
Gruß PeMue
Zitatwelches Referenzgerät nimmst Du für die Helligkeit?
Bitte nicht übertreiben :)
Ich glaube nicht das dieses Teil die Bezeichnung "Referenzgerät" verdient hat.
http://www.pollin.de/shop/dt/NDA3OTYxOTk-/Messtechnik_Uhren/Messtechnik/Multimeter/Digital_Luxmeter_MASTECH_MS6610.html
Aber ich kann somit bestimmen dass ich keinen absoluten "Mist messe".
Gruß
Dirk
Zitat von: martinp876 am 18 April 2014, 10:53:45
HMConfig hat eigentlich keinen Code - somit werde ich das Lesen weiterer files in CUL_HM implementieren. Macht mehr Sinn, meine ich.
Seit dem heutigen Update von 10_CUL_HM.pm und HMConfig.pm funktioniert der Sensor nicht mehr. Und er scheint als "virtual Actor" geführt zu werden, weil ich plötzlich ein "set <name> virtual <n>" angeboten bekomme.
Nachtrag:Zitat von: martinp876 am 18 April 2014, 10:53:45
HMConfig hat eigentlich keinen Code - somit werde ich das Lesen weiterer files in CUL_HM implementieren. Macht mehr Sinn, meine ich.
Offenbar nicht...
Wenn ich das Nachladen der HMConfig_Zusatzmodule in der aktuellen 10_CUL_HM.pm komplett auskommentiere und wieder in die HMConfig.pm verlege, funktioniert alles einwandfrei.
könnt ihr einmal das HMConfig_ posten? Hätte gleich danach fragen sollen...
Hi Martin,
die letzte Version ist hier:
https://github.com/kc-GitHub/Wettersensor/raw/master/Tools/FHEM/HMConfig_SenTHPL.pm
Gruß
Dirk
(http://up.picr.de/18010586lh.png)
Sieht gut aus (ok, Firmwareupdate fehlt noch)
Zitat von: Prof. Dr. Peter Henning am 18 April 2014, 15:02:43
Die Idee mit dem HB-Präfix finde ich übrigens sehr gut, auch deshalb, weil die Markenbezeichnung "HomeMatic" geschützt ist.
Ach, und HB ist wohl KEINE geschützte Markenbezeichnung ;)
Firmware und Flash-Tool sind hier:
https://github.com/kc-GitHub/Wettersensor/blob/master/Tools/Firmware/Flash-Tool-Windows.zip?raw=true
Es gibt jetzt 2 Versionen der Firmware. einmal für den Innensensor (HB-UW-Sen-THPL-I) und einmal für den Außensensor (HB-UW-Sen-THPL-0).
Hier ist aber nur die Device-ID unterschiedlich welche bei der CCU für das andere Bildchen sorgt.
Bitte mit der neuen Version das neue Flas-Tool beutzen, da ich die Default-ID und Seriennummer generischer gestaltet habe.
Das Addon für die CCU ist hier:
https://github.com/kc-GitHub/Wettersensor/blob/master/Tools/CCU/HB-UW-Sen-THPL_CCU-addon.tgz?raw=true
Bitte vorher eine Backup machen, da ich das noch nicht zu Hause an der "echten" CCU testen konnte.
Das sollte auf CCU1 und CCU2 und unabhängig von der Firmwareversion funktonieren.
Ich habe das Helligkeits-Reading von Lux nach Luminosity geändert, da der wert in Lux nur stimmt, wenn das Licht ungefiltert auf den Sensor fällt. Ansonsten muss man das entsprechend umrechnen.
Gruß
Dirk
Die 0.8 für den Aussensensor sendet bei mir keine Daten.
Ich habe den Sensor komplett aus meinem fhem gelöscht und dann ein neues Pairing durchgeführt.
Internals:
CFGFN
DEF 6FB75D
IODev wz_HMUSB
LASTInputDev wz_HMUSB
MSGCNT 13
NAME CUL_HM_HB_UW_Sen_THPL_O_6FB75D
NR 272
STATE ???
TYPE CUL_HM
az_HMUSB_MSGCNT 5
az_HMUSB_RAWMSG E6FB75D,0000,07D92A77,FF,FFB8,05A0106FB75D1270000100000000
az_HMUSB_RSSI -72
az_HMUSB_TIME 2014-04-19 12:46:07
lastMsg No:05 - t:10 s:6FB75D d:127000 0100000000
protLastRcv 2014-04-19 12:46:07
protSnd 9 last_at:2014-04-19 12:46:07
protState CMDs_done
rssi_at_az_HMUSB avg:-69.8 min:-72 max:-66 lst:-72 cnt:5
rssi_at_wz_HMUSB avg:-43.5 min:-44 max:-40 lst:-44 cnt:8
wz_HMUSB_MSGCNT 8
wz_HMUSB_RAWMSG R7997E0E2,0001,0233F226,FF,FFD4,05A0106FB75D1270000100000000
wz_HMUSB_RSSI -44
wz_HMUSB_TIME 2014-04-19 12:46:07
Readings:
2014-04-19 12:46:09 Activity alive
2014-04-19 12:46:06 CommandAccepted yes
2014-04-19 12:46:05 D-firmware 0.8
2014-04-19 12:46:05 D-serialNr UWS0000001
2014-04-19 12:46:07 PairedTo 0x127000
2014-04-19 12:46:07 R-burstRx off
2014-04-19 12:46:07 R-pairCentral 0x127000
2014-04-19 12:46:07 RegL_00: 01:00 02:01 0A:12 0B:70 0C:00 00:00
ah... Verwirrendes Problem erkannt.
Der Sensor führt den ersten Sendezyklus nicht mehr direkt nach dem EInschalten (Batterieeinlegen) durch, sondern erst nach Ablauf mindestens eines Sendezyklus (ca 2,5 Minuten) durch:
(http://up.picr.de/18010792vk.png)
Jetzt sind jedenfalls Sensordaten vorhanden. Das Verhalten war aber bis zur 0.7 anders?
das Problem in CUL_HM sollte gelöst sein - backslash vergessen....
Bin jetzt wieder zuhause. Habe neue Firmware-Version eingespielt, FHEM upgedatet (CUL_HM aus SVN genommen). Alles tut wie es soll ;)
Jetzt muss Dirk nur noch das THPL einchecken :P
Wo soll ich das denn "hinchecken"?
Contrib wird ja wohl nicht automatisch aktualisiert.
Allerdings braucht THPL ja auch nicht jeder?
ZitatAllerdings braucht THPL ja auch nicht jeder?
Na dann 'ne Frage an die FHEM-Perl-Profis: Wie macht man so, dass diese Datei nur dann geladen wird, wenn ein entsprechendes Device auch wirklich exisitiert (angemeldet wurde)?
Das haben wir weiter unten schon mal diskutiert.
So ähnlich macht es das wohl das Firmata-Modul. Kurz gesagt, der Umbau das das CUL_HM so macht ist nicht unerheblich. Daher gibt es kurzfristig diesen Weg, dass alle Dateien geladen die mit "HMConfig_" beginnen.
Ich habe mich noch mal mit den Außensensor und der Lichtempfindlichkeit und eventueller Filter beschäftigt.
mein aktueller Plan ist Fensterfilterfolie zu bverwenden. Diese hat eine definierte Lichtdurchlässigkeit und das Ganze reproduzierbar machen. Erste Tests waren auch ganz vielversprechend.
Die Folie die ich hier habe, lässt laut Beschreibung nur ca. 26% Licht durch. Ersten Tests heute Nachmittag, leider ohne direkte Sonne, scheinen das auch zu bestätigen. Verglichen habe ich das mit einem zweiten Sensor ohne Abdeckung.
Der Einbau der Folie ist so auch recht einfach. Ich werde die nächsten Tage mal eine Messreihe machen.
Gruß
Dirk
ZitatKurz gesagt, der Umbau das das CUL_HM so macht ist nicht unerheblich.
Hm... Ist mir beim schnellen Durchlesen entgangen. :(
OK, ich halte trotzdem ein Einchecken in den FHEM-Zweig für tragbar. Auch wenn die wenigsten FHEM-Nutzer das Device haben werden, ein nennenswertes Overhead wird dadurch ja auch nicht generiert.
Zitat von: Dirk am 19 April 2014, 21:51:30
Wo soll ich das denn "hinchecken"?
Allerdings braucht THPL ja auch nicht jeder?
Na, nach FHEM - wohin sonst?
Du willst doch nicht allen Ernstes behaupten, dass dort nur Dateien eingecheckt sind, die JEDER braucht ;) Wenn es danach ginge, könnte man mindestens 70% aller Module in FHEM nach contrib verschieben.
Mal was ganz anderes: Ist eigentlich das Peeren schon richtig implementiert? Ich hab's mal ausprobiert, also...
set DirksSensor peerChan 0 og_bd_Heizung_Weather
Im List vom og_bd_Heizung_Weather sieht das dann so aus:
device og_bd_Heizung
peerList DirksSensor,DirksSensor_chn:02,
Readings:
2014-04-23 22:03:12 R-sign off
2014-04-23 22:36:18 measured-temp 16.4
2014-04-23 22:03:12 peerList DirksSensor,DirksSensor_chn:02,
2014-04-23 22:36:18 state 16.4
Helper:
peerIDsRaw ,6FB75E02,6FB75E01,00000000
Role:
chn 1
Shadowreg:
Attributes:
expert 1
group og_Bad
model HM-CC-RT-DN
peerIDs 00000000,6FB75E01,6FB75E02,
Im list zum Sensor kann ich allerdings dazu nichts sehen. Ich habe auch ein getConfig versucht, aber das scheint ewig auf CMD_pending hängen zu bleiben.
Ich dachte zuerst, dass es gar nicht funktionieren würde, als ich aber den Sensor in den Kühlschrank gelegt habe, hat der RT im Bad geglaubt, das Fenster wäre offen. Ich habe den Eindruck, dass die Übernahme der Werte verzögert bzw. manchmal gar nicht erfolgt. Hier ist ein Auszug aus einem FileLog, das die Werte von beiden zeigt:
2014-04-23_22:08:21 DirksSensor T: 22.3 H: 57 Lux: 0.06 P: 1007 batVoltage: 2.38
2014-04-23_22:08:35 og_bd_HeizungOp T: 22.3 desired: 18.0 valve: 0
2014-04-23_22:10:46 DirksSensor T: 21.9 H: 50 Lux: 0 P: 1007 batVoltage: 2.36
2014-04-23_22:10:57 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:12:56 DirksSensor T: 21.4 H: 48 Lux: 0 P: 1007 batVoltage: 2.36
2014-04-23_22:13:05 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:15:57 DirksSensor T: 21.1 H: 49 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:16:02 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:18:43 DirksSensor T: 19.7 H: 38 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:18:44 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:21:13 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:21:14 DirksSensor T: 16.0 H: 34 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:23:26 og_bd_HeizungOp T: 21.9 desired: 18.0 valve: 0
2014-04-23_22:23:31 DirksSensor T: 14.3 H: 32 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:26:29 og_bd_HeizungOp T: 22.3 desired: 18.0 valve: 0
2014-04-23_22:26:37 DirksSensor T: 16.4 H: 82 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:29:18 og_bd_HeizungOp T: 16.4 desired: 12.0 valve: 0
2014-04-23_22:29:29 DirksSensor T: 18.5 H: 76 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:31:53 og_bd_HeizungOp T: 16.4 desired: 12.0 valve: 0
2014-04-23_22:32:07 DirksSensor T: 19.6 H: 72 Lux: 0 P: 1007 batVoltage: 2.38
2014-04-23_22:34:13 og_bd_HeizungOp T: 16.4 desired: 12.0 valve: 0
2014-04-23_22:34:30 DirksSensor T: 20.2 H: 72 Lux: 0 P: 1007 batVoltage: 2.37
2014-04-23_22:36:18 og_bd_HeizungOp T: 16.4 desired: 12.0 valve: 0
2014-04-23_22:36:38 DirksSensor T: 20.5 H: 70 Lux: 0 P: 1007 batVoltage: 2.38
2014-04-23_22:39:14 og_bd_HeizungOp T: 20.5 desired: 12.0 valve: 0
2014-04-23_22:39:37 DirksSensor T: 20.8 H: 69 Lux: 0 P: 1007 batVoltage: 2.38
2014-04-23_22:41:54 og_bd_HeizungOp T: 20.5 desired: 12.0 valve: 0
2014-04-23_22:42:21 DirksSensor T: 21.0 H: 69 Lux: 0 P: 1007 batVoltage: 2.38
2014-04-23_22:44:21 og_bd_HeizungOp T: 20.5 desired: 18.0 valve: 0
2014-04-23_22:44:51 DirksSensor T: 21.1 H: 69 Lux: 0 P: 1007 batVoltage: 2.38
Kann es sein, dass da das Timing der Kommunikation noch nicht so ganz stimmt?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 23 April 2014, 22:49:39
Kann es sein, dass da das Timing der Kommunikation noch nicht so ganz stimmt?
Das könnte gut sein.
Das Peering habe ich tatsächlich aktuell etwas vernachlässigt, ich habe leider keinen HM-CC-RT-DN zum testen.
Es gibt noch ein 1-2 Stellen im Code der mit delay's arbeitet. Vor allen beim Lesen des Helligkeitssensors. Ja ich weiß das soll man nicht machen. Das war aber ein schneller Weg den Sensor zu laufen zu bringen. Hier kommen mit Sicherheit noch einige Timings durcheinander. Und ich kann mir vorstellen dass da der Sensor den Timeslot bei dem der RT auf Empfang ist ab und zu verpasst.
Das werde ich die nächsten Tage noch ändern.
Update:
Du benutzt aber das "normale" Hex-File, also nicht das was alle 10 Sek. sendet?
Zitat von: Dirk am 23 April 2014, 23:40:52Das Peering habe ich tatsächlich aktuell etwas vernachlässigt, ich habe leider keinen HM-CC-RT-DN zum testen.
Das kann ich dann erledigen.
Zitat
Es gibt noch ein 1-2 Stellen im Code der mit delay's arbeitet.
Böse, böse...
ZitatDas werde ich die nächsten Tage noch ändern.
Ok, Du scheinst zu wissen, wo Du hinfassen musst, dann lasse ich die Finger davon.
Zitat
Update:
Du benutzt aber das "normale" Hex-File, also nicht das was alle 10 Sek. sendet?
Ja, das normale. Im FileLog-Ausschnitt aus meinem vorherigen Post kannst Du das Timing sehen.
Hast Du auch eine Idee, wo das "CMDs_pending" herkommt? Das Teil scheint gar keine Kommandos zu verarbeiten. Beim peering bleibt es auf "2 CMDs_pending" hängen, ebenso beim getConfig.
Gruß,
Thorsten
Hallo,
kurze Status Meldung:
Die Bewegungsmelder liegen beim Zoll, da keine Zoll Unterlagen oder Rechnung drauf war.
Ich bin gespannt ob ich die Mitnehmen darf!
z.Z: Suche ich alle Unterlagen zusammen ist aber umständlich, da ich eingeschränkt bin.
Vor 2 Tagen ist der Blitz direkt ins Nachbarhaus. Da gibt es z.Z. andere Prioritäten.
Nico
Ich musste auch schon paar mal zum Zoll.
Die Sachen wirst Du mitnehmen können. Nimm die Rechnung mit, bzw. die Zahlungsbestätigung, eBay-Ausdruck etc.
Ich habe auch bereits zwei kleine Bewegungsmelderplatinchen liegen. Ich bastele dann mit
Hallo,
es gibt ein kleines Update im Github.
Das Flash-Tool gibt es dort nun auch für den Raspberry Pi.
Man kann das Firmware-Update nun auch über die GPIO-Pins des Raspberry Pi durchführen.
Dazu ist dann kein USB-Serialadapter erforderlich.
Gruß
Dirk
Hi,
Hattest Du auch schon Gelegenheit, Dir das Peering anzuschauen?
Gruß,
Thorsten
Hallo Thorsten,
Mit dem Peering habe ich mich noch nicht beschäftigt.
Ich brauche hier vermutlich auch Unterstützung, da ich keine passende Partner zum Peeren habe.
Ich habe je die noch immer eingebauten Sleeps in Verdacht.
Soll ich dir mal eine Firmwareversion schicken wo das Auslesen des Helligkeitssensors abgeschaltet ist, oder kannst du das mal testen?
Gruß
Dirk
Hallo Zusammen,
Peering sollte eigentlich funktionieren. In der bisherigen Konfiguration sende ich auch nur Temperatur und Luftfeuchtigkeit. Ich habe mich an die Vorgaben des Dummy Devices von Martin gehalten.
Vom Timing bin ich mir nicht ganz sicher ob es stimmt. Die Wartezeit bis zur nächsten Übermittlung wird ja auf Basis des Messagezählers errechnet. Derzeit nutze ich den Aktuellen, kann aber sein das man den Nächsten nehmen muss. Eigentlich macht das keinen grossen Unterschied. Nur wenn der Messagezähler auf 0 ist, dann ist der aktuelle ja 255 und dann macht es eine Unterschied...
Testet mal ohne die Sleeps, wenn es das nicht war, dann gehen wir das Thema Messagezähler an.
Viele Grüsse
Horst
Zitat von: Dirk am 05 Mai 2014, 20:05:05Ich habe je die noch immer eingebauten Sleeps in Verdacht.
Soll ich dir mal eine Firmwareversion schicken wo das Auslesen des Helligkeitssensors abgeschaltet ist, oder kannst du das mal testen?
Das einfachste fuer mich waere natuerlich, wenn Du mir die Firmware-Version schickst. Ich muesste es aber auch hinbekommen, wenn Du mir sagst, wo das entsprechende Coding zu finden ist. Das kann aber ein paar Tage dauern.
Zitat von: trilu am 05 Mai 2014, 20:23:02Vom Timing bin ich mir nicht ganz sicher ob es stimmt. Die Wartezeit bis zur nächsten Übermittlung wird ja auf Basis des Messagezählers errechnet. Derzeit nutze ich den Aktuellen, kann aber sein das man den Nächsten nehmen muss. Eigentlich macht das keinen grossen Unterschied. Nur wenn der Messagezähler auf 0 ist, dann ist der aktuelle ja 255 und dann macht es eine Unterschied...
Das klingt ja so, als ob es meistens funktionieren muesste, nur eben alle 256 Messages oder so mal nicht. Das ist aber nicht der Fall. Es funktioniert meistens nicht richtig. Aber ich denke mal, wir sollten auch hier sicher stellen, dass es moeglichst immer klappt. Koennest Du mir dazu auch einen Tipp geben, wo das entsprechende Coding ist?
Hi
Auch auf die Gefahr hin das ich gleich ausgebuht werde,
kann man noch Platinen bestellen?
Ich habe jetzt mal die ersten 6 Seiten überflogen.
Soweit sieht das ganze ja schon mal sehr gut aus!
Wieweit sind die Platinen bestückt?
Ich hätte gerne sofern möglich zwei Sensoren mit Licht und Luftdruck.
Temperatur muss nicht sein.
Was kostet der Spaß?
ZitatVom Timing bin ich mir nicht ganz sicher ob es stimmt. Die Wartezeit bis zur nächsten Übermittlung wird ja auf Basis des Messagezählers errechnet. Derzeit nutze ich den Aktuellen, kann aber sein das man den Nächsten nehmen muss. Eigentlich macht das keinen grossen Unterschied. Nur wenn der Messagezähler auf 0 ist, dann ist der aktuelle ja 255 und dann macht es eine Unterschied...
bei vd/tc, ist ja wohl das gleiche schema, funktioniert es so:
aus der aktuellen msg-nummer wird das nächste meeting berechnet. auch wenn ein meeting nicht erfolgreich war, werden die zähler incrementiert, um das darauf folgende meeting zu berechnen. auch wenn die msg-nummer "nur" um 1 daneben liegt, können durch die berechnung einige sekunden differenz daraus resultieren. ausserdem werden die abstände mit steigender msg-nummer auch manchmal kürzer. also treffen sie sich nur noch durch zufall. darum schläft der vd nach 6 missglückten meetings auch für eine stunde ein. danach wird er aber solange wach, bis wieder ein meeting erfolgreich ist. sollte der tc sich nicht mehr melden, ist die batterie bald leer.
um die trefferquote zu erhöhen vergrössert der vd nach jedem erfolglosen meeting sein wachfenster, und synchronisiert sich bei erneutem meeting. auch bei regelmässig erfolgreichen meetings scheint er sich manchmal neu zu synchronisieren, wenn das meeting wohl gerade noch geklappt hat.
gruss frank
Zitat von: Thorsten Pferdekaemper am 05 Mai 2014, 20:46:18
Das einfachste fuer mich waere natuerlich, wenn Du mir die Firmware-Version schickst.
Ich bau dir die Tage mal was zusammen.
Zitat von: Henno am 05 Mai 2014, 21:00:16
kann man noch Platinen bestellen?
Ja, es wird aber noch etwas dauern.
Es gab bei mir ein paar Verzögerungen.
Zitat
Wieweit sind die Platinen bestückt?
Von komplett leer bis voll bestückt. Je nach dem was du möchtest.
Zitat
Ich hätte gerne sofern möglich zwei Sensoren mit Licht und Luftdruck.
Innen oder Außenversion?
Zitat
Was kostet der Spaß?
Grob überschlagen, je nach Bestückungsvariante / Ausstattung vermutlich um die 20-35€
Gruß
Dirk
Zitat von: Dirk am 06 Mai 2014, 01:06:33
Ich bau dir die Tage mal was zusammen.
Danke. Koenntest Du mir auch einen Tipp geben, wo im Coding Du etwas geaendert hast (bzw. geaendert haben wirst)? Wenn ich sowieso dran rumschraube, dann kann ich's vielleicht gleich reparieren.
Gruss,
Thorsten
ich mache das in der sensor class
void MyClassName::poll_transmit(void) {
if (tTiming) nTime = millis() + tTiming; // there is a given timing
else nTime = millis() + (calcSendSlot() * 250) - measureTime; // calculate the next send slot by multiplying with 250ms to get the time in millis
nAction = 'm'; // next time we want to measure again
// transmit code
hm->sendPeerWEATHER(regCnl,tTemp,tHum,tPres); // send out the weather event
}
uint32_t MyClassName::calcSendSlot(void) {
uint32_t result = (((hm->getHMID() << 8) | hm->getMsgCnt()) * 1103515245 + 12345) >> 16;
return (result & 0xFF) + 480;
}
Hi Trilu,
Zitat von: trilu am 06 Mai 2014, 18:03:13
ich mache das in der sensor class
ich hatte die Firmware ja schon etwas weiter entwickelt. Daher wird das so nicht ganz passen.
Wenn du wieder Zeit hast, könnten wie die Codestände vielleicht mal zusamen mergen.
@Thorsten
in Sensor_SHT10_BMP085_TSL2561.cpp wird die Helligkeit so eingelesen:
tLux = tsl2561->readBrightness(data0, data1) * 100;Diese Zeile einfach auskommentieren.
Die Funktion readBrightness ist in TSL2561.cpp
Dort findes du auch die Delay's.
Ich werde das die Tage mal umbauen, so dass hier keine vor allem langen Delay's mehr gebraucht werden.
Anbei auch das Kompilierte Hex-File.
Gruß
Dirk
Zitat von: Dirk am 06 Mai 2014, 23:24:28
ich hatte die Firmware ja schon etwas weiter entwickelt. Daher wird das so nicht ganz passen.
Hast Du auch den AskSin-Teil geändert? Ich hatte mir das vom AskSin-Thread geholt und es schien zu passen. Falls Du auch was an den AskSin-Sourcen geändert hast, könntest Du mir die schicken?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 07 Mai 2014, 08:34:23
Ich hatte mir das vom AskSin-Thread geholt und es schien zu passen.
Das würde mich wundern.
Ich hatte an der Lib einige Optimierungen vorgenommen und das Wichtigste, die Timerbehandlung geändert, so das dadurch der Bug mit dem Zyklischen hängenbleiben des Sensors gefixt wurde.
Daher hatte ich die Lib geforkt und im Wettersensor-Repo als Subrepo eingebunden:
https://github.com/kc-GitHub/AskSin
Gruß
Dirk
Zitat von: Dirk am 07 Mai 2014, 09:06:17Das würde mich wundern.
Ich hatte an der Lib einige Optimierungen vorgenommen und das Wichtigste, die Timerbehandlung geändert, so das dadurch der Bug mit dem Zyklischen hängenbleiben des Sensors gefixt wurde.
Ich habe auch ehrlich gesagt nicht ausprobiert, ob es wirklich laeuft. Das Kompilieren hat geklappt und das Ergebnis hatte exact dieselbe Groesse.
Na, dann werde ich das vielleicht mal mit Deinem Fork ausprobieren.
ich hab hier paar Arduino mini pro 3.3V 8Mhz, CC1101 868Mhz Module (die die auch Dirk verwendet) und DHT22 Sensoren.
Ich habe bis jetzt nur mit Uno und selbst gebauten Arduinos und DHT22 ein T/H sensor gebaut aber mit Display und auch mit EtherShield aber will das ganze mit den Arduino Mini Pro und CC1101 bauen da ich schon fast ales mit HM steure.
Da ich schon alle Komponente habe muss ich nur alle verbinden und programmieren, meine Frage wäre gibts eine einfache Programmierung Beschreibung fuer nur T/H mit DHT22 ohne sonstigen Sensoren? (später mach ich vielleicht mit Lichtsensor)
Ich hab hier im Thread gesucht aber konnte keine Antwort finden.
Meine ToDo Liste:
- Arduino Mini Pro 3.3V Programmieren
- CC1101 868 mit Arduino Verbinden
- DHT22 mit Arduino Verbinden
- Daten an FHEM schicken und freuen :)
Hallo,
wenn es nur der DHT 22 sein soll - panstamp Battery Board, entsprechenden Sketch drauf, fertig.
Ich habe das als S0 Counter im Einsatz (binimp und temphumpress zusammen kopiert). Das Battery Board gibt es mit DHT22.
Gruß Christoph
PS. der Panstamp sendet SWAP, aber das ist schon in Fhem integriert.
Danke Christoph, werde mir es anschauen aber ich will keine neue hardware kaufen da ich schon material fuer ca 5 Sensoren habe Arduino Mini Pro, DHT22 und CC1101 868Mhz. Bin auch interessiert an selbstbau von HM kompatiblen Sensoren (mit AskSin ?)
Eigentlich muss ich nur den existierenden Sketch umbauen (uns das ist z.Z. das Problem) und an DHT22 anpassen oder hat es schon jemand gemacht?
Hallo,
ich habe mal gegoogelt - http://www.ebay.de/itm/DHT22-AM2302-digital-Sensor-Feuchtigkeit-Temperatur-Feuchte-Temperatur-Sensor-/290738840660
dort steht, das die Sensoren kompatibel wären, also würde ich das einfach mal probieren - oder die Datenblätter vergleichen.
Gruß Christoph
-- beim Battery-Board vom Panstamp ist ein DHT22 drauf - für den Panstamp gibt es da einen fertigen Sketch, vielleich kanst Du ja Teile davon nutzen (sensor.h und sensor.ino)
Danke Christoph,
ich werde mich heute die nächste paar Tage damit auseinander setzen spricht den Arduino Mini Pro mit dem Code von Dirk und DHT22 zu laufen zu kriegen.
Nur das Problem ist reverse Engineering von dem Code von Dirk da ich es HM Protokoll kompatibel machen möchte.
Zitat von: xequtor am 15 Mai 2014, 13:18:18
Nur das Problem ist reverse Engineering von dem Code von Dirk da ich es HM Protokoll kompatibel machen möchte.
Der Code spricht schon HM. Du musts also nur deine Temperaturwerte anstelle der Temperatur vom SHT10 senden.
Gruß
Dirk
Hallo Dirk,
ist mir bewusst, was ich meine war der Code fuer PanStamp was Christoph meinte, der spricht kein HM deswegen will ich es mit deinem machen.
Mein Problem ist Implementierung fuer Arduino mini Pro (3.3V, 8Mhz) und DHT22.
Mit was kompilierst Du es? Ich gehe davon aus dass mit Arduino IDE wird es nicht funktionieren oder?
Panstamp kann schon DHT22. Warum nutzt du nicht SWAP? Ist der Weg des geringsten Widerstandes.....
Tobias,
werde ich auch tun mit einem von meinen Mini Pro/DHT22 aber irgend wie mag ich die Idee mit HM Protokoll. (fuer HMLAN den ich noch nicht habe)
Die Lib ist für die Arduino IDE ausgelegt, du kannst damit kompilieren und auf den Panstamp laden. Zum proggen finde ich sie aber unübersichtlich 8)
Viele Grüsse
Horst
Der Code vom Sensor sollte auch in der Arduino-IDE Kompilieren.
Zum Entwickeln habe ich das Arduino Eclipse-Plugin verwendet.
Gruß
Dirk
Hallo Dirk,
ich hab jetzt meine Eclipse Umgebung gebaut (mit Blink getestet und alles OK) und Kämpfe mit AskSin. Ich nutze die Eclipse Arduino IDE von eclipse.baeyens.it
Soweit kann ich den AskSin Project kompilieren bis auf:
Sensor_SHT10_BMP085_TSL2561.cpp
Sensor_SHT10_BMP085_TSL2561.h
die zwei schmeißen jede menge errors (41)
Brauche ich die zwei?
Was muss ich machen um nur fuer DHT22 ne hex zu kompilieren?
Fuer nen Eclipse Neuling ist jede menge Code wenn man vorher nur mit Arduino IDE "programmierte" :)
hab noch warning in AskSinMain.cpp gehabt aber bechoben:
alt:
pevt.data[0] = (temp >> 8) & 0xFF | battery.state << 7;
neu:
pevt.data[0] = ((temp >> 8) & 0xFF) | battery.state << 7;
Zitat von: xequtor am 17 Mai 2014, 11:19:05
ich hab jetzt meine Eclipse Umgebung gebaut (mit Blink getestet und alles OK) und Kämpfe mit AskSin. Ich nutze die Eclipse Arduino IDE von eclipse.baeyens.it
Die nutze ich auch.
ZitatSoweit kann ich den AskSin Project kompilieren bis auf:
Sensor_SHT10_BMP085_TSL2561.cpp
Sensor_SHT10_BMP085_TSL2561.h
die zwei schmeißen jede menge errors (41)
Welche Arduino-IDE hast du im Eclipse-Plugin angegeben?
Versuche mal die Version 1.5.2
ZitatBrauche ich die zwei?
Da drin wird das Sensorreading behandelt.
Am Anfang könntest du dich mit einhängen.
Wenn du Ausschliesslich deinen einen Sensor nutzen möchtest, kannst du dir hier auch eine eigene Klasse schreiben.
ZitatWas muss ich machen um nur fuer DHT22 ne hex zu kompilieren?
Hast du eine Arduino-Lib für den Sensor?
ZitatFuer nen Eclipse Neuling ist jede menge Code wenn man vorher nur mit Arduino IDE "programmierte" :)
Obwohl das doch auch nicht viel anders ist. Der Code sollte aber auch mit der Arduino-IDE alleine kompilieren.
Zitathab noch warning in AskSinMain.cpp gehabt aber bechoben:
alt:
pevt.data[0] = (temp >> 8) & 0xFF | battery.state << 7;
neu:
pevt.data[0] = ((temp >> 8) & 0xFF) | battery.state << 7;
Kann man machen. Die Klammer sollte aber optional sein.
Gruß
Dirk
ZitatWelche Arduino-IDE hast du im Eclipse-Plugin angegeben?
Versuche mal die Version 1.5.2
eben die 1.5.2 nutze ich.
hier der Error:
Building file: ../Sensor_SHT10_BMP085_TSL2561.cpp
Starting C++ compile
"/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-g++" -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=152 -I"/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/cores/arduino" -I"/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/variants/standard" -MMD -MP -MF"Sensor_SHT10_BMP085_TSL2561.cpp.d" -MT"Sensor_SHT10_BMP085_TSL2561.cpp.d" -D__IN_ECLIPSE__=1 -x c++ "../Sensor_SHT10_BMP085_TSL2561.cpp" -o "Sensor_SHT10_BMP085_TSL2561.cpp.o"
In file included from ../Sensor_SHT10_BMP085_TSL2561.cpp:8:
../Sensor_SHT10_BMP085_TSL2561.h:37: error: 'Sensirion' has not been declared
../Sensor_SHT10_BMP085_TSL2561.h:37: error: 'BMP085' has not been declared
../Sensor_SHT10_BMP085_TSL2561.h:37: error: 'TSL2561' has not been declared
../Sensor_SHT10_BMP085_TSL2561.h:69: error: ISO C++ forbids declaration of 'Sensirion' with no type
../Sensor_SHT10_BMP085_TSL2561.h:69: error: expected ';' before '*' token
../Sensor_SHT10_BMP085_TSL2561.h:70: error: ISO C++ forbids declaration of 'BMP085' with no type
../Sensor_SHT10_BMP085_TSL2561.h:70: error: expected ';' before '*' token
../Sensor_SHT10_BMP085_TSL2561.h:71: error: ISO C++ forbids declaration of 'TSL2561' with no type
../Sensor_SHT10_BMP085_TSL2561.h:71: error: expected ';' before '*' token
../Sensor_SHT10_BMP085_TSL2561.cpp:15: error: 'Sensirion' has not been declared
../Sensor_SHT10_BMP085_TSL2561.cpp:15: error: 'BMP085' has not been declared
../Sensor_SHT10_BMP085_TSL2561.cpp:15: error: 'TSL2561' has not been declared
../Sensor_SHT10_BMP085_TSL2561.cpp: In member function 'void Sensors_SHT10_BMP085_TSL2561::config(uint8_t, uint8_t, uint16_t, int*, int*, int*)':
../Sensor_SHT10_BMP085_TSL2561.cpp:20: error: 'sht10' was not declared in this scope
../Sensor_SHT10_BMP085_TSL2561.cpp:22: error: 'LOW_RES' was not declared in this scope
../Sensor_SHT10_BMP085_TSL2561.cpp:25: error: 'bm180' was not declared in this scope
../Sensor_SHT10_BMP085_TSL2561.cpp:29: error: 'tsl2561' was not declared in this scope
../Sensor_SHT10_BMP085_TSL2561.cpp:33: error: 'tsl2561' was not declared in this scope
../Sensor_SHT10_BMP085_TSL2561.cpp:34: error: 'INTEGATION_TIME_14' was not declared in this scope
../Sensor_SHT10_BMP085_TSL2561.cpp: In member function 'void Sensors_SHT10_BMP085_TSL2561::poll_measure()':
../Sensor_SHT10_BMP085_TSL2561.cpp:48: error: 'sht10' was not declared in this scope
../Sensor_SHT10_BMP085_TSL2561.cpp:60: error: 'bm180' was not declared in this scope
../Sensor_SHT10_BMP085_TSL2561.cpp:76: error: 'tsl2561' was not declared in this scope
make: *** [Sensor_SHT10_BMP085_TSL2561.cpp.o] Error 1
ZitatWenn du Ausschliesslich deinen einen Sensor nutzen möchtest, kannst du dir hier auch eine eigene Klasse schreiben.
Hast du eine Arduino-Lib für den Sensor?
ja, fuer den DHT22 hab ich eine lib, ich nutze den DHT z.Z. mit einem LCD
im Anhang Bild von wie es in Ecliple das Project ausschaut, was mich auch wundert ist in Includes AskSin/AskSin und AskSin/AskSin/utility ich kann es nicht loeschen
Bei dir fehlen noch ein paar andere Libs.
Die sind alle im Code auf Github mit drinn.
Die AskSin-Lib hat aber ein eigenes Subrepo. Das musst du extra auschecken. Von hier:
https://github.com/kc-GitHub/AskSin
Das ist eine geforkte Version von Trilu seiner Lib, in der wichtige Bugfixes drin sind.
@Trilu: Meinst du wir könnten das demnächst mal mergen?
Wie sieht es aktuell mit deiner Zeit aus?
Ich vermisse bei dir im Projekt auch den Libraries-Ordner.
Bei mir sieht es so aus:
danke Dirk!
endlich kann ich kompilieren ohne errors. Habs fast aufgegeben :)
Jetzt muss ich noch rausfinden wo und was auskommentieren dass nur der DHT22/SHT10 bleibt (hab bereits den BMP180 bestellt, der TSL2561 ist "teuer" finde ich)
Ausserdem noch muss ich die pins Konfiguration finden und fuer Arduino Mini Pro anpassen, also wo die Sensoren, LED's etc. angeschlossen werden.
ein Problem hab ich noch, wenn ich den DHT22 oder DHT11 and den Arduino mini Pro mit 8Mhz/3.3V anschliessen kriege ich keine werte von dem sensor aber mit jeden anderen 5V chip wie MEGA2560 oder Uno funktioniert mit gleichem code, liegt es an den 8Mhz, 3.3V oder sonst was? Ich hab es nicht mit dem code von WetterSensor getestet sonder mit eigenem.
Zitat von: Dirk am 06 Mai 2014, 23:24:28Anbei auch das Kompilierte Hex-File.
Hi,
ich habe jetzt endlich mal den Wettersensor ohne die Lux-Messung ausprobiert. (Firmware HB-UW-Sen-THPL-I_08_without_lux.hex)
Das Ergebnis ist noch schlechter als vorher:
2014-05-18_21:22:53 CUL_HM_UWS_THPL_ABCDEF T: 23.4 H: 50 Lux: 65538 P: 999 batVoltage: 2.31
2014-05-18_21:23:42 og_bd_HeizungOp T: 23.4 desired: 20.0 valve: 0
2014-05-18_21:25:35 CUL_HM_UWS_THPL_ABCDEF T: 24.0 H: 52 Lux: 65538 P: 999 batVoltage: 2.30
2014-05-18_21:26:13 og_bd_HeizungOp T: 23.4 desired: 20.0 valve: 0
2014-05-18_21:28:02 CUL_HM_UWS_THPL_ABCDEF T: 24.8 H: 40 Lux: 65538 P: 999 batVoltage: 2.30
2014-05-18_21:28:29 og_bd_HeizungOp T: 23.4 desired: 20.0 valve: 0
2014-05-18_21:30:14 CUL_HM_UWS_THPL_ABCDEF T: 20.2 H: 42 Lux: 65538 P: 999 batVoltage: 2.32
2014-05-18_21:30:31 og_bd_HeizungOp T: 23.4 desired: 20.0 valve: 0
2014-05-18_21:33:16 CUL_HM_UWS_THPL_ABCDEF T: 17.0 H: 45 Lux: 65538 P: 999 batVoltage: 2.30
2014-05-18_21:33:23 og_bd_HeizungOp T: 21.3 desired: 20.0 valve: 0
2014-05-18_21:36:00 og_bd_HeizungOp T: 21.4 desired: 20.0 valve: 28
2014-05-18_21:36:04 CUL_HM_UWS_THPL_ABCDEF T: 15.6 H: 46 Lux: 65538 P: 999 batVoltage: 2.30
2014-05-18_21:38:23 og_bd_HeizungOp T: 21.5 desired: 20.0 valve: 28
2014-05-18_21:38:37 CUL_HM_UWS_THPL_ABCDEF T: 14.8 H: 47 Lux: 65538 P: 999 batVoltage: 2.31
2014-05-18_21:40:31 og_bd_HeizungOp T: 21.3 desired: 20.0 valve: 28
2014-05-18_21:40:55 CUL_HM_UWS_THPL_ABCDEF T: 14.2 H: 54 Lux: 65538 P: 999 batVoltage: 2.32
2014-05-18_21:42:59 CUL_HM_UWS_THPL_ABCDEF T: 14.0 H: 57 Lux: 65538 P: 999 batVoltage: 2.31
2014-05-18_21:43:29 og_bd_HeizungOp T: 21.2 desired: 20.0 valve: 28
2014-05-18_21:45:53 CUL_HM_UWS_THPL_ABCDEF T: 14.7 H: 74 Lux: 65538 P: 999 batVoltage: 2.30
2014-05-18_21:46:13 og_bd_HeizungOp T: 21.2 desired: 20.0 valve: 28
Es sieht so aus, als ob der RT den ersten Wert nach dem Peeren mitbekommt, aber dann nichts mehr. Er scheint dann relativ bald aufzugeben und seinen internen Wert zu verwenden.
Gruß,
Thorsten
So, jetzt habe ich das Teil mal selbst kompiliert, die Lichtmessung ausgebaut und calcSendSlot nimmt jetzt "hm->getMsgCnt()+1". Das Ergebnis ist etwas besser als vorher, aber noch nicht perfekt:
2014-05-18_23:39:20 DirksSensor T: 22.1 H: 53 Lux: 65538 P: 999 batVoltage: 2.32
2014-05-18_23:40:05 og_bd_HeizungOp T: 21.1 desired: 12.0 valve: 0
2014-05-18_23:42:15 DirksSensor T: 21.3 H: 45 Lux: 65538 P: 999 batVoltage: 2.30
2014-05-18_23:42:25 og_bd_HeizungOp T: 21.3 desired: 12.0 valve: 0
2014-05-18_23:44:31 og_bd_HeizungOp T: 21.3 desired: 12.0 valve: 0
2014-05-18_23:44:56 DirksSensor T: 17.4 H: 47 Lux: 65538 P: 999 batVoltage: 2.31
2014-05-18_23:47:22 DirksSensor T: 15.5 H: 47 Lux: 65538 P: 999 batVoltage: 2.30
2014-05-18_23:47:26 og_bd_HeizungOp T: 15.5 desired: 12.0 valve: 0
2014-05-18_23:49:33 DirksSensor T: 14.6 H: 48 Lux: 65538 P: 999 batVoltage: 2.31
2014-05-18_23:50:07 og_bd_HeizungOp T: 15.5 desired: 12.0 valve: 0
2014-05-18_23:52:34 og_bd_HeizungOp T: 15.5 desired: 12.0 valve: 0
2014-05-18_23:52:34 DirksSensor T: 13.8 H: 49 Lux: 65538 P: 999 batVoltage: 2.30
2014-05-18_23:54:46 og_bd_HeizungOp T: 15.5 desired: 12.0 valve: 0
2014-05-18_23:55:20 DirksSensor T: 13.2 H: 49 Lux: 65538 P: 999 batVoltage: 2.30
2014-05-18_23:57:47 og_bd_HeizungOp T: 13.2 desired: 12.0 valve: 0
2014-05-18_23:57:53 DirksSensor T: 12.9 H: 50 Lux: 65538 P: 999 batVoltage: 2.30
...aber vielleicht muss sich da noch was einpendeln.
Ich hatte vorher eine Version ohne Lichtmessung aber mit dem alten Message Counter. Das sah schlechter aus.
Hi,
ich habe jetzt die Helligkeitsmessung wieder mit reingenommen und es funktioniert immer noch (oder sogar besser):
2014-05-19_00:21:03 DirksSensor T: 22.1 H: 53 Lux: 25.07 P: 999 batVoltage: 2.30
2014-05-19_00:23:21 og_bd_HeizungOp T: 22.1 desired: 18.0 valve: 0
2014-05-19_00:23:29 DirksSensor T: 22.2 H: 53 Lux: 26.4 P: 999 batVoltage: 2.31
2014-05-19_00:25:40 DirksSensor T: 22.1 H: 49 Lux: 0 P: 999 batVoltage: 2.30
2014-05-19_00:25:52 og_bd_HeizungOp T: 22.1 desired: 18.0 valve: 0
2014-05-19_00:26:22 og_bd_HeizungOp T: 22.1 desired: 18.0 valve: 0
2014-05-19_00:28:24 og_bd_HeizungOp T: 22.1 desired: 18.0 valve: 0
2014-05-19_00:28:42 DirksSensor T: 17.8 H: 51 Lux: 0 P: 999 batVoltage: 2.30
2014-05-19_00:31:16 og_bd_HeizungOp T: 17.8 desired: 12.0 valve: 0
2014-05-19_00:31:28 DirksSensor T: 15.7 H: 54 Lux: 0 P: 999 batVoltage: 2.31
2014-05-19_00:33:53 og_bd_HeizungOp T: 15.7 desired: 12.0 valve: 0
2014-05-19_00:34:00 DirksSensor T: 14.8 H: 56 Lux: 0 P: 999 batVoltage: 2.31
2014-05-19_00:36:16 og_bd_HeizungOp T: 14.8 desired: 12.0 valve: 0
2014-05-19_00:36:18 DirksSensor T: 14.6 H: 82 Lux: 0 P: 999 batVoltage: 2.30
2014-05-19_00:38:20 DirksSensor T: 16.5 H: 81 Lux: 0 P: 999 batVoltage: 2.30
2014-05-19_00:41:13 DirksSensor T: 18.3 H: 76 Lux: 0 P: 999 batVoltage: 2.31
2014-05-19_00:41:22 og_bd_HeizungOp T: 18.3 desired: 12.0 valve: 0
2014-05-19_00:43:52 DirksSensor T: 19.2 H: 72 Lux: 0 P: 999 batVoltage: 2.30
2014-05-19_00:44:06 og_bd_HeizungOp T: 18.3 desired: 12.0 valve: 0
2014-05-19_00:46:16 DirksSensor T: 19.7 H: 70 Lux: 0 P: 999 batVoltage: 2.30
2014-05-19_00:46:35 og_bd_HeizungOp T: 19.7 desired: 18.0 valve: 0
Es sind ein paar Wackler drin, aber das kann auch daran liegen, dass die Übertragung vom Kühlschrank ins Bad nicht ganz optimal ist.
Ich denke auf jeden Fall, dass es nicht an den Delays bei der Helligkeitsmessung liegt. Soweit ich das Coding verstehe, dürfen die Messungen insgesamt 1000ms dauern, egal ob mit millis() oder per delay().
Ich lasse das jetzt mal über Nacht laufen.
Ach so ja. Die Änderung:
uint32_t result = (((hm->getHMID() << 8) | (hm->getMsgCnt()+1)) * 1103515245 + 12345) >> 16;
...die "+1" scheinen den Unterschied zu machen.
Was mir noch aufgefallen ist:
void SHT10_BMP085_TSL2561::poll(void) {
unsigned long mils = millis();
// just polling, as the function name said
if ((nTime == 0) || (nTime > mils)) {
Kann das nicht nach ungefähr 49 Tagen ziemlich schief gehen? Dann ist nämlich irgendwann nTime fast am Ende und mils schon übergelaufen. Dann bleibt nTime > mils fast 49 Tage. Oder?
Gruß,
Thorsten
ja, das war damals der plan - ich gehe von der nächsten zu sendenden zeit 1000ms zurück und starte die messung.
ich war mir damals nicht ganz sicher wie lange ein messzyklus wirklich dauert.
if ((nTime == 0) || (nTime > mils))
das dürfte eigentlich kein problem geben, da die nächste zeit immer wieder auf basis der aktuellen zeit gesetzt wird.
ist ja ein unsigned integer. nehmen wir mal an ich brauche in 1000ms einen event und wir sind kurz vor den 49 tagen.
dann würde ich nTime so setzen nTime = millis() + 1000 - wobei millis() gerade 65500 wäre.
nTime wäre somit 65500 + 1000 = 965
nach der 49 tage grenze spring millis ja auch wieder auf 0 und somit sollte die if funktionieren.
Zitat@Trilu: Meinst du wir könnten das demnächst mal mergen?
Wie sieht es aktuell mit deiner Zeit aus?
angespannt ;)
wenn du mir sagst was ich machen muss (bin nicht der held mit git)
am wochenende kann ich schon mal ein bischen zeit einbringen, vorzugsweise bei schlechtem wetter.
viele grüße
horst
Zitat von: trilu am 19 Mai 2014, 12:40:13if ((nTime == 0) || (nTime > mils))
das dürfte eigentlich kein problem geben, da die nächste zeit immer wieder auf basis der aktuellen zeit gesetzt wird.
ist ja ein unsigned integer. nehmen wir mal an ich brauche in 1000ms einen event und wir sind kurz vor den 49 tagen.
dann würde ich nTime so setzen nTime = millis() + 1000 - wobei millis() gerade 65500 wäre.
nTime wäre somit 65500 + 1000 = 965
nach der 49 tage grenze spring millis ja auch wieder auf 0 und somit sollte die if funktionieren.
angespannt ;)
Ja, das ist der Fall, der funktioniert. Meine Oma (oder so?) hat aber immer gesagt "de Deifel is ä Aischhönsche":
Nehmen wir mal der Einfachheit halber an, dass millis nur 16 Bit hat. Also 0..65535. Und nehmen wir auch mal an, dass millis() gerade 64535 liefert. Dann ergibt sich
ntime = millis() + 1000 = 65535
Das läuft jetzt ein bisschen so weiter, aber ausgerechnet wenn millis 65535 wäre kommt uns ein Interrupt oder sowas dazwischen (oder einer von Dirks delays). Lass das auch mal nur eine Millisekunde dauern. Beim nächsten poll() ist dann mils = 0, ntime aber immer noch 65535. Dann dauert es lange, bis das nächste mal ntime <= mils. ...und wenn es dann soweit ist, dann müssen wir auch genau die eine Millisekunde treffen.
Es kann schon sein, dass das unwahrscheinlich ist, aber wenn es passiert, dann ist es häßlich und keiner findet den Fehler.
Ich habe übrigens den Sensor seit heute Nacht mit dem RT gepeert laufen. So wie es aussieht gab es in den letzten 13 Stunden nur einmal einen kleinen Aussetzer wo sich die beiden ein oder zweimal verpasst haben. Ich würde sagen, dass das jetzt gut läuft. (...und das mit Helligkeitssensor.)
Die Version ist die aus Dirks git von gestern Abend (Sensor als auch AskSin aus Dirks Repo.)
Baut jemand das "+1" in die offiziellen Sourcen ein?
Gruß,
Thorsten
Hallo,
leider hat es gedauert, aber nun Rückmeldung zu den Bewegungsmeldern.
Sie sind da und ich habe diese angeschlossen. VCC+GND
D3/INT1 will ich für den Eingang nutzen.
Bei 3,3 V VCC liegt am Ausgang des Melders 2,6-2,8V an wenn Bewegung erkannt und 0V im Ruhezustand.
Ins Gehäuse hab ich den noch nicht eingebaut aber er müsste passen Mittig auf der Vorderseite zwischen Batterie und dem Stab für den Helligkeitssensor. Es sit aber knapp.
Nun stehe ich aber wie der Ochse vor dem Berg was die Programmierung angeht.
Mal sehen wann es wie weitergeht.
Nico
Hallo,
die Platinen der 2. Prototypenserie sind nun endlich mal angekommen.
Leider hat sich im Teil für die RS485-Variante ein kleiner Fehler eingeschlichen.
Die Bestückungsvariante für die Funkversion ist aber fehlerfrei.
Daher werde ich noch eine Prototypen-Serie machen.
Es sind nun aber wieder Platinen da, so dass ich schon einige Sensoren fertig machen kann.
Die Interessenten schicken mir bitte eine kurze PN.
Ich habe jetzt auch die Breakout-Boards für die SHT10 Sensoren hier.
Damit könnte der Aussensensor entsprechend mit einem Temperatur/Feuschte-Sensor erweitert werden.
Siehe Bild.
@santalaus
ZitatD3/INT1 will ich für den Eingang nutzen.
Bei 3,3 V VCC liegt am Ausgang des Melders 2,6-2,8V an wenn Bewegung erkannt und 0V im Ruhezustand.
Das sollte ohne Probleme funktionieren.
ZitatNun stehe ich aber wie der Ochse vor dem Berg was die Programmierung angeht.
Was brauchst du hier für Hilfe?
@Thorsten
ZitatBaut jemand das "+1" in die offiziellen Sourcen ein?
Ja, mach ich.
@Trilu
Zitatwenn du mir sagst was ich machen muss (bin nicht der held mit git)
Du könntest deine und meine Version mal diffen, und schauen ob du mit den Änderungen einverstanden bist.
Dann kann ich das auch mergen.
Gruß
Dirk
Zitat von: Dirk am 24 Mai 2014, 01:27:01Daher werde ich noch eine Prototypen-Serie machen.
Es sind nun aber wieder Platinen da, so dass ich schon einige Sensoren fertig machen kann.
Die Interessenten schicken mir bitte eine kurze PN.
Wenn Du mal welche mit RS485 hast, dann wäre ich an mindestens zweien interessiert.
Für die Funkversion kommt eine Mail...
Zitat@ThorstenJa, mach ich.
Das bezieht sich auf das "+1". Könntest Du Dir auch anschauen, was ich zur Behandlung der millis() geschrieben habe? (Siehe http://forum.fhem.de/index.php/topic,20620.msg169842.html#msg169842 (http://forum.fhem.de/index.php/topic,20620.msg169842.html#msg169842) und http://forum.fhem.de/index.php/topic,20620.msg169954.html#msg169954 (http://forum.fhem.de/index.php/topic,20620.msg169954.html#msg169954).
Ich wollte beides in den Issue-Tracker für AskSin im GitHub eintragen, aber da gibt es keinen Issue-Tracker...
Gruß,
Thorsten
Hallo,
bezüglich der millis() beim panstamp (sollte auch beim Adurino so sein) ist ein unsignedLong und läuft nach ca. 49 Tagen über. Zudem ist millis() kritisch wenn man WDT oder GoToSleep nutzt, da wird der millis() nämlich angehalten und läuft nicht weiter.
Gruß Christoph
Zitat von: Bennemannc am 27 Mai 2014, 13:04:24bezüglich der millis() beim panstamp (sollte auch beim Adurino so sein) ist ein unsignedLong und läuft nach ca. 49 Tagen über.
Genau, aber wenn man's richtig macht, dann ist das egal. ...zumindest solange die zu messende Zeit kleiner ist als 49 Tage und die Prüfung öfter als einmal alle 49 Tage stattfindet.
Hier ist die Erklärung:
http://www.leonardomiliani.com/2012/come-gestire-loverflow-di-millis/comment-page-1/?lang=en
(http://www.leonardomiliani.com/2012/come-gestire-loverflow-di-millis/comment-page-1/?lang=en)
ZitatZudem ist millis() kritisch wenn man WDT oder GoToSleep nutzt, da wird der millis() nämlich angehalten und läuft nicht weiter.
Ich glaube, dass die AskSin-Devices das nicht machen.
Zudem ist millis() kritisch wenn man WDT oder GoToSleep nutzt, da wird der millis() nämlich angehalten und läuft nicht weiter.
Dafür habe ich in der AskSin ein paar Zeilen Code spendiert. Wenn das Device per WDT schläft, addiere ich die Zeit in der es geschlafen hat zum millis() counter.
wollte gerade mal die unterschiede anschauen und die beiden repos wieder zusammenführen.
aber ich komme keinen schritt weiter - kennt jemand eine gute anleitung?
ich arbeite unter windows....
shit, ich lass jetzt die finger davon - irgendwas habe ich zerschossen - hilfeeeeeeeeeeeee
Das schöne bei git ist, dass man alles zurück drehen kann. Zur Not muss man von vorne anfangen.
Was ging denn kaputt?
das wenn ich wüsste - ich habe einen pull request auf den fork von dirk gemacht,
und jetzt kompiliert nichts mehr. ich hatte mir die changes so weit angeschaut und wollte sie in meinen master übernehmen.
der fork von dirk kompiliert jetzt aber auch nicht mehr durch...
Kann dich gut verstehen, Habe auch manchmal mit ähnlichen Sachen zu kämpfen :o
Mache doch einen Vergleich mit dem Repository (beide alte Stände), dann siehst Du, was sich alles geändert hat. Das hilft normalerweise den Durchblick wieder zu erlangen.
Zitat von: trilu am 30 Mai 2014, 19:24:00
und jetzt kompiliert nichts mehr. ich hatte mir die changes so weit angeschaut und wollte sie in meinen master übernehmen.
Wenn die Änderungen für dich so ok sind, dann kann ich das auch bei dir rein mergen.
In den master?
Gruß
Dirk
Ja, mach mal.
Mit der Serial ID und HM ID bin ich noch nicht ganz glücklich, aber ob wir von deinem fork oder von meiner Version weitermachen spielt keine Rolle.
Ich stelle fest, ich habe keine Ahnung von git :)
Zitat von: trilu am 30 Mai 2014, 19:24:00
ich habe einen pull request auf den fork von dirk gemacht, und jetzt kompiliert nichts mehr.
Also in meiner Arduino-IDE kompilieren auch ältere Stände der Lib und der Examples nicht.
Serial.h: No such file or directory
memory.h: No such file or directoryusw.
mit dem Eclipse-Plugin funktioniert das.
Hab aber grade keine Idee was das sein sollte.
ZitatMit der Serial ID und HM ID bin ich noch nicht ganz glücklich
Was macht dich hier "unglücklich" bzw. was würdest du da anders machen?
Zitat von: Thorsten Pferdekaemper am 27 Mai 2014, 10:45:56
Das bezieht sich auf das "+1". Könntest Du Dir auch anschauen, was ich zur Behandlung der millis() geschrieben habe?
Ich hab das mit eingecheckt.
@Trilu, magst du das noch mal mergen?
Gruß
Dirk
Soweit ich gesehen habe wird die HM ID und Serial nicht ins EEprom geschrieben. Sondern ist statisch im progmem.
Wenn man sie beim starten aus dem EEprom holt, hätte man den Vorteil das man per AVR Dude einfach ein
EEprom File mit in den Arduino lädt. Für die Leute die seriell flashen könnte man sie per Random generieren lassen
und ins EEprom schreiben.
Dritte Möglichkeit - Man kann sie per serieller Konsole setzen, aber das setzt eben vorraus, dass sie im EEprom steht.
Ich denke das wäre der bessere Weg...
Zitat von: trilu am 01 Juni 2014, 12:44:22
Soweit ich gesehen habe wird die HM ID und Serial nicht ins EEprom geschrieben.
Das hab ich mit Absicht so gemacht.
Es gibt ein Flash-Tool, mit der kann jeder beim seriellen flashen eine eigene Seriennummer und die HM-ID setzen.
Das funktioniert aktuell zuverlässig.
Die eingestellten Defaultwerte werden vor dem flashen per SED, per "Suchen und Ersetzen", ersetzt. Das funktioniert aktuell zuverlässig.
Wenn man keine eigenen Daten angibt, werden die voreingestellten Daten benutzt.
Eins Vergabe der Daten per Zufall baue ich in das Flash-Tool noch ein.
Hier kannst du dir das ansehen:
https://github.com/kc-GitHub/Wettersensor/tree/master/Tools/Firmware
Gruß
Dirk
Ist ja prima, das geht ja mit eeprom fast 1:1, sind nur kleine Änderungen
Das .eep file sieht so aus:
:030000000A0B0CDC
:00000001FF
Hier habe ich nur 3 Variable rein geschrieben
Byte1 = 10, Byte2 = 11, Byte3 = 12
Vorteil, die sind sogar an definierten Stellen.
Mit AVR Dude wird einfach noch ein weiteres File hoch geladen, eben das mit der Endung .eep
Ich komme mit der seriellen Methode auch noch gut ran - das mit der Zufallszahl werde ich mir auch noch mal anschauen.
Viele Grüße
Horst
ZitatIst ja prima, das geht ja mit eeprom fast 1:1, sind nur kleine Änderungen
Wieviel Programmcode wird denn hier zusätzlich gebraucht?
Ggf. kann man das ja als alternative vorsehen. Per define auswählbar.
Zitatdas mit der Zufallszahl werde ich mir auch noch mal anschauen.
Das würde ich auch extern machen. Es sei denn im Programmspeicher ist noch Platz.
Allerdings ist der jetzt schon gut gefüllt. Daher alle Sachen die man extern machen kann möglichst extern machen.
Viele Grüße
Dirk
Hallo,
irgedwie scheint mein Pairing nicht (vollständig) zu klappen.
Bekomme in fhem ein Gerät mit "model unknown"
Was habe ich gemacht:
- fhem: update
- fhem: shutdown restart
- fhem: set CUL_0 hmPairForSec 600
- Sensor: Config Taster getätigt
Das obige habe habe ich schon mehrmals versucht, mit dem gleichen Ergebnis.
Vielleicht hat jemand einen Tipp für mich.
Grüsse Martin
Moin!
Mir ist eine 'Unschärfe' aufgefallen. Mein Sensor meldet gerade battery low, da die Spannung af 2.19V gesunken ist. Da das Gerät jedoch einen MAX-StepUp-Wandler besitzt, ist die low-Warning deutlich verfrüht. Es wäre sinnvoll, diese Grenze anhängig vor vorhandener hardware zu bestimmen.
Grüße,
Alexander
Zitat von: mmatt am 08 Juni 2014, 22:40:34irgedwie scheint mein Pairing nicht (vollständig) zu klappen.
Hi,
schau Dir mal den Beitrag hier an:
http://forum.fhem.de/index.php/topic,20620.405.html (http://forum.fhem.de/index.php/topic,20620.405.html)
Ich weiß nicht, was alles davon inzwischen mit dem normalen update mitkommt. Vielleicht musst Du die Device-spezifische Datei immer noch selbst reinkopieren.
Gruss,
Thorsten
Zitat von: hexenmeister am 08 Juni 2014, 22:49:54
Mein Sensor meldet gerade battery low, da die Spannung af 2.19V gesunken ist.
Mein Sensor meldet seit heute auch battery low (2.19V) und das nach einer Betriebszeit von nur ca. zwei Monaten. (ohne Spannungswandler) Ein so hoher Batterieverbrauch kann doch nicht normal sein, oder? Es ist der gleiche Batterietyp wie in anderen Homematic Komponenten, bei denen die Batterien allerdings länger als ein Jahr halten.
Zitat von: betateilchen am 09 Juni 2014, 11:19:16
Mein Sensor meldet seit heute auch battery low (2.19V) und das nach einer Betriebszeit von nur ca. zwei Monaten. (ohne Spannungswandler) Ein so hoher Batterieverbrauch kann doch nicht normal sein, oder? Es ist der gleiche Batterietyp wie in anderen Homematic Komponenten, bei denen die Batterien allerdings länger als ein Jahr halten.
Meiner läuft auch seit mindestens zwei Monaten. Ich habe ein Paar Billig-Akkus reingemacht, die am Anfang schon nicht voll waren. Jetzt steht die Anzeige auf 2.28V. Hast Du das Teil mit irgendwas gepeert? Dann könnte sich der fehlende "+1-Patch" (siehe hier: http://forum.fhem.de/index.php/topic,20620.msg169842.html#msg169842 (http://forum.fhem.de/index.php/topic,20620.msg169842.html#msg169842) und ein paar Beiträge früher) auswirken. Wenn sich die Partner nicht oft genug treffen, dann könnte es sein, dass sich das Device ein bisschen quält und nicht mehr schlafen geht.
Das ist nur eine Vermutung, vielleicht ist das auch Quatsch.
Gruß,
Thorsten
Hallo,
ich habe da EnerloopAkkus drin. gertsern Nacht auf einmal Spanungsabfall von knapp über 2V auf unter 1V. Kurz danach ging der Sensor aus.
Er ist nicht mit etwas anderen gepeert. Ich habe nur seit ca 14 Tagen den Bewegungsmelder angeschlossen aber noch nix programmiert.
Nico
Seit dem heutigen fhem Update meldet der Sensor plötzlich wieder 2.23V Spannung und die Batteriewarnung ist verschwunden.
Kann das schlichtweg ein Fehler in 10_CUL_HM.pm gewesen sein, der mit dem heutigen Update wieder beseitigt ist?
Ich habe CUL_HM aus SVN genommen. Die angezeigte Spannung hat sich erwartungsgemäß nicht verändert. Kann ich mir auch nicht vorstellen, wie CUL_HM darauf Einfluss nehmen soll.
Hallo
Ich bin leider beim Pairing immer noch nicht weitergekommen :-(
Ich habe mal angegebne Device-spezifische Datei die "HMConfig_SenTHPL.pm" aus dem Git in das Verzeichnis /opt/fhem/FHEM kopiert.
Nun stürzt fhem beim Pairing ab. :-(
Irgedwas stimmt da noch nicht. ?
Braucht es auch noch eine spezielle HMConfig.pm oder 10_CUL_HM.pm?
(die sollten duch ein fhem Update ja eigendlich aktuell sein)
Denke ich gebs für heute auf, ist einfach zu heiss :-)
Bin aber immer noch für einen Rat dankbar ;-)
Grüsse Martin
Zitat von: hexenmeister am 09 Juni 2014, 18:38:12
Die angezeigte Spannung hat sich erwartungsgemäß nicht verändert.
wieso habe ich ohne jegliches zutun plötzlich wieder eine höhere Batteriespannung als vor dem Update?
Zitat von: hexenmeister am 08 Juni 2014, 22:49:54
Da das Gerät jedoch einen MAX-StepUp-Wandler besitzt, ist die low-Warning deutlich verfrüht. Es wäre sinnvoll, diese Grenze anhängig vor vorhandener hardware zu bestimmen.
Diesen Punkt will ich noch über ein einstellbares Register lösen, wo man die Low-Bat-Schwelle einstellen kann.
Zitat von: betateilchen am 09 Juni 2014, 11:19:16
Ein so hoher Batterieverbrauch kann doch nicht normal sein, oder?
Definitiv nicht.
Ich habe hier ähnliche Beobachtungen gemacht.
Ich muss hier vermutlich die FW noch mal nachbessern. Da hier noch nicht alle Energiesparmaßnahmen greifen.
Zitat von: Thorsten Pferdekaemper am 09 Juni 2014, 12:16:47
Dann könnte sich der fehlende "+1-Patch" (siehe hier: http://forum.fhem.de/index.php/topic,20620.msg169842.html#msg169842 (http://forum.fhem.de/index.php/topic,20620.msg169842.html#msg169842) und ein paar Beiträge früher) auswirken.
Den Patch habe ich schon drin. Allerdings vor Pfingsten noch nicht veröffentlicht.
Das reiche ich noch nach.
Zitat von: mmatt am 09 Juni 2014, 18:41:58
Ich habe mal angegebne Device-spezifische Datei die "HMConfig_SenTHPL.pm" aus dem Git in das Verzeichnis /opt/fhem/FHEM kopiert.
Ich schau mir das noch mal an.
Zitatist einfach zu heiss :-)
Daher wird das vermutlich erst morgen :)
Gruß
Dirk
@Dirk: Register-Lösung ist auch gut :)
@Betateilchen: da muss man schon deine Batterie fragen ;)
Im ernst, der Wert wird doch nur menschenlesbar gemacht, nicht irgendwie errechnet. Kann an der Hitze liegen.
Hallo,
inzwischen sind die neuen Platinen mit der RS485-Option auch angekommen.
Ein erster schneller Test sieht auch gut aus.
Die Tage werde ich dann das Ganze noch mal ausführlich testen.
Viele Grüße
Dirk
Hallo,
wo und zu welchem Preis kann man die Platinen bekommen ?
Gruß Christoph
Zitat von: Dirk am 12 Juni 2014, 09:08:43inzwischen sind die neuen Platinen mit der RS485-Option auch angekommen.
Da kannst Du gleich mal zwei für mich reservieren...
Gruß,
Thorsten
Hallo,
ich konnte inzwischen mein Paring Problem lösen.
Ich habe eine ältere 10_CUL_HM.pm (6041 2014-06-03) genommen.
Das Gerät wird nun korrekt (und ohne fhem Absturz) erkannt. :)
Grüsse Martin
Hallo,
Zitat von: Bennemannc am 12 Juni 2014, 10:18:37
wo und zu welchem Preis kann man die Platinen bekommen ?
Ich hab diese Bestückungsvariante noch nicht durchgerechnet.
Die Version für Funk liegt derzeit je nach Sensorbestückung zwischen 25 € und 33 € incl. Gehäuse
Bei der RS485-Version fällt das Funktmodul weg, dafür kommen RS485 Tranceiver und Schaltregler usw. dazu.
Somit wird sich das in einem ähnlichen Rahmen bewegen. +/- ein Paar €.
Zitat von: Thorsten Pferdekaemper am 12 Juni 2014, 12:34:34
Da kannst Du gleich mal zwei für mich reservieren...
Thorsten
Aber klar doch.
Zitat von: mmatt am 12 Juni 2014, 19:30:10
Ich habe eine ältere 10_CUL_HM.pm (6041 2014-06-03) genommen.
Das klingt nach einem bösen Bug.
Ich schau mir das das Wochenende mal an. Ggf. muss Martin da eingreifen.
Gruß
Dirk
Update:In der Berechnung oben habe ich den Luftdrucksensor vergessen.
Somit sind es zwischen 25 € und 38 € je nach Bestückungsvariante.
Hallo Dirk,
ich hätte gerne einen mit Funk - ist da schon die FW drauf ?
Bezüglich der CUL_HM, da ist in der letzten Version ein Fehler. Martin scheint sich mal eine Auszeit genommen zu haben (zumindest heute). Die Version 6096 ist die letzte funktionierende. Im Moment sollte man kein update machen.
Gruß Christoph
Hallo Christoph,
Zitatich hätte gerne einen mit Funk
Ich Teste am Wochenende die neuen Platinen. Dann sage ich noch mal bescheid.
Zitatist da schon die FW drauf
Ja, FW + Bootloader.
Da sich die FW aber noch weiter entwickeln wird ist ein USB-Serial-Adapter zum Flashen dennoch zu Empfehlen.
Alternativ kann man die FW auch mit einem Raspberry Pi updaten.
Viele Grüße
Dirk
Hallo,
ein USB - Seriell Kabel habe ich und hier steht auch noch ein Raspi rum. Dann muss ich mir bei Dedarf nur noch die Anleitung suchen - oder habt Ihr für den Selbstbau schon ein Wiki?
Gruß Christoph
Zitat von: Bennemannc am 13 Juni 2014, 14:31:01
oder habt Ihr für den Selbstbau schon ein Wiki?
Ja, ist aber noch nicht komplett:
http://www.fhemwiki.de/wiki/Universalsensor
Gruß
Dirk
Hej Dirk,
vielen Dank für das Status-Update.
Ab Ende Juni sieht es mit meiner Zeit auch wieder ein wenig besser aus und somit wird mein Interesse an den Teilen auch immer Größer. :-)
Was mir noch aufgefallen ist: Wie sieht es denn mit einem OTA-Bootloader aus? Jan aus dem Nachbarprojekt (http://forum.fhem.de/index.php/topic,18071.0.html) hat da einen gebaut.
Würden für den die 32k vom Atmega aus noch ausreichen oder wäre ein 64k erforderlich? Wenn das für dich in Frage kommt, wären das mMn 2 gut investierte Euro, um sich zukünftiges herumbasteln bei jedem Flashen zu ersparen. Gerade, wenn man mehrere solche Boards in Verwendung hat.
Ansonsten bin ich schon sehr auf deine Testergebnisse von diesem Wochenende gespannt. :-)
So, ich hatte am Wochenende mal Zeit etwas mit meinem nagelneuen Aussensensor rumzuspielen und ich fürchte, ich werde euch in nächster Zeit etwas auf den Geist gehen müssen... Dafür schonmal *sorry* an dieser Stelle 8)
Ich hätte da mal ein paar Fragen:
-Also das Pairen an sich hat erstmal geklappt. Ich sehe das Device in FHEM und er zeigt auch "PairedTo 0xF15544". Alle 2-3 Minuten blinkt der Sensor auch, aber ich sehe leider überhaupt keine Sensor-Readings in FHEM ankommen. Ich sehe jedoch zB Reading "D-firmware" und "D-serialNr". Der Sensor einmal kurz und dann einmal lang beim Senden. Ich hab schon gelesen, dass das zweite "lang" wohl auf ein fehlendes ACK von FHEM hindeutet.
Ich verwende ein ganz normales ungepatchtes FHEM mit einem HMLAN. Ist es korrekt, dass das damit funktionieren müsste oder muss ich zB CUL_HM oder ähnliches noch anfassen? Sonst noch Ideen, was ich da machen könnte? Ist wahrscheinlich was recht blödes, da ich ein ziemlicher FHEM/HM Neuling bin. Soll ich noch etwas an Logs und Screenshots posten?
-Ich hab den Quellcode der Firmware ausgecheckt und ich konnte ihn auch in der Arduino IDE bauen. Ich musste jedoch noch in ganz oben einige Includes hinzufügen:
#include <Sensirion.h>
#include <Wire.h>
#include <BMP085.h>
Ansonsten wollte Arduino die Libs nicht bauen und ich bekam dann Linker-Fehler (undefined reference). Ist das so gedacht? Oder ist das eine Eigenart der Arduino-IDE und ihr benutzt sowieso alle Eclipse?
-Ich bräuchte noch einen USB-Serial-Adapter zum Flashen, aber mit einem Standard-RS232 (12V) Ding geht das ja nicht. Wollte mir den hier nun bei eBay bestellen:
http://www.ebay.de/itm/FT232RL-USB-auf-TTL-Konverter-Adapter-Module-3-3V-5V-500MA-fur-Arduino-PC-Neu-/331163739459?pt=DE_Computing_USB_Kabel_Hubs_Adapter&hash=item4d1ae5a543
Der sollte funktionieren, oder?
-Ich würde ganz gerne per AVR Dragon per ISP flashen und mit debugWire debuggen. Wenn ich mich nicht verguckt habe, dann liegen die Pins dafür nicht direkt auf diesen Pad-Leisten, oder? Dann muss man sich was basteln per Fädeldraht oder wie macht ihr das?
-Ich kenne das Debuggen bisher nur per AVRStudio. Gibt es jemand, der die Firmware schon mit AVRStudio kompiliert hat und damit debuggt hat? Oder wie macht ihr das?
Dankeschön!
Zitat von: vbs am 15 Juni 2014, 17:38:02-Also das Pairen an sich hat erstmal geklappt. Ich sehe das Device in FHEM und er zeigt auch "PairedTo 0xF15544". Alle 2-3 Minuten blinkt der Sensor auch, aber ich sehe leider überhaupt keine Sensor-Readings in FHEM ankommen. Ich sehe jedoch zB Reading "D-firmware" und "D-serialNr".
Hi,
ich weiß nicht, ob folgendes schon im FHEM "Standard" angekommen ist.
Schau mal nach, ob in der HMConfig.pm am Ende sowas wie das hier zu finden ist:
my $mp = "./FHEM";
opendir(DH, $mp) || return;
foreach my $m (sort readdir(DH)) {
next if($m !~ m/^HMConfig_(.*)\.pm$/);
no strict "refs";
my $file = "./FHEM/$m";
my $ret = do $file;
if(!$ret) {
main::Log3 undef, 1, "Error loading file: $file:\n $@";
}
use strict "refs";
}
closedir(DH);
Außerdem muss es eine Datei HMConfig_THPL.pm oder ähnlich geben.
Gruß,
Thorsten
Nee, gab es noch nicht. Hab ich aber jetzt reinkopiert und diese THPL-Config in Dirk's Repo gefunden und dazu gelegt.
Und nun gehts auch sofort! ;D Danke! "Kaum macht mans richtig, schon gehts"
EDIT:
Beim Starten sagt er übrigens:
Subroutine CUL_HM_ParseTHPLSensor redefined at ./FHEM/HMConfig_SenTHPL.pm line 18, <> line 96.
EDIT2:
Ich wollte eigentlich gerade ein paar Sachen, die ich bisher herausgefunden habe, im Wiki verewigen. Leider kann ich dort aber kein Account machen, da das nur Admins dürfen :-[
Zitat von: vbs am 15 Juni 2014, 19:08:32
Nee, gab es noch nicht.
Das ist merkwürdig.
Eigentlich hatte das Martin schon vor ein paar Wochen eingebaut. Somit sollte es ausreichen nur die Datei "HMConfig_SenTHPL.pm" zu kopieren.
ZitatEDIT:
Beim Starten sagt er übrigens:
Subroutine CUL_HM_ParseTHPLSensor redefined at ./FHEM/HMConfig_SenTHPL.pm line 18, <> line 96.
Hast du die Datei 2 Mal ggf. mit anderem Namen im Verzeichniss?
ZitatIch wollte eigentlich gerade ein paar Sachen, die ich bisher herausgefunden habe, im Wiki verewigen.
Was hast du noch herausgefunden?
Zitat von: Mr. P am 14 Juni 2014, 11:34:08
Was mir noch aufgefallen ist: Wie sieht es denn mit einem OTA-Bootloader aus? Jan aus dem Nachbarprojekt (http://forum.fhem.de/index.php/topic,18071.0.html) hat da einen gebaut.
Ja, das Projekt ist mir bekannt.
ZitatWürden für den die 32k vom Atmega aus noch ausreichen oder wäre ein 64k erforderlich?
Es ist weniger der Gesamtspeicher, eher der Speicher der für den Bootloaderbereich übrig bleibt. Das ist beim Atmega328 nur 2kb und da wird es mit dem OTA-Bootloader eng.
ZitatWenn das für dich in Frage kommt, wären das mMn 2 gut investierte Euro, um sich zukünftiges herumbasteln bei jedem Flashen zu ersparen
Keine Frage OTA ist prima. Ich denke bei nächsten Projekten werde ich das bestimmt berücksichtigen.
Viele Grüße
Dirk
Zitat von: Dirk am 15 Juni 2014, 22:42:07
Das ist merkwürdig.
Eigentlich hatte das Martin schon vor ein paar Wochen eingebaut. Somit sollte es ausreichen nur die Datei "HMConfig_SenTHPL.pm" zu kopieren.
Zitat von: Dirk am 15 Juni 2014, 22:42:07
Hast du die Datei 2 Mal ggf. mit anderem Namen im Verzeichniss?
Also scheinbar ist der Code, der diese Config-Files nachlädt von martin nicht in HMConfig, sondern in 10_CUL_HM eingebaut worden. Da hab ich zumindest etwas sehr ähnliches gefunden.
Da ich jetzt den Code nochmal in HMConfig eingebaut habe, hat er bei mir die Config zweimal geladen und daher die Fehlermeldung.
Zitat von: Dirk am 15 Juni 2014, 22:42:07
Was hast du noch herausgefunden?
Naja, nix was für euch nicht völlig klar ist :) Also wo man den Firmware-Quellcode findet. Dass es ein Arduino-Projekt ist und wie man es mit Arduino-IDE zum Kompilieren bekommt. Naja und jetzt eben, wie man den Sensor mit einem Stock-FHEM zum Laufen bekommt. Der nächste Schritt wird für mich sein, die Firmware selbst auf den AVR zu flashen und nach Möglichkeit debuggen zu können. Die Basics halt ;)
Zitat von: vbs am 15 Juni 2014, 23:10:00
wie man es mit Arduino-IDE zum Kompilieren bekommt.
Da ich mich mit der Arduino IDE noch etwas schwer tue und ich auch nach einigem Suchen noch keine Lösung gefunden habe:
Kannst du bitte kurz zusammenfassen, was man machen muss, um den Code von https://github.com/trilu2000/AskSin (https://github.com/trilu2000/AskSin) mit der Arduino IDE compilieren zu können?
Nur den Sketch zu öffnen reicht nicht, weil dann die Include Files nicht gefunden werden. Noch irgendwas mit den Arduino Libraries?
Vielen Dank schon mal,
Kai
Zitat von: Mr. P am 14 Juni 2014, 11:34:08
Ansonsten bin ich schon sehr auf deine Testergebnisse von diesem Wochenende gespannt. :-)
Die Tests sind bisher alle positiv verlaufen. Der Funk-Teil funktioniert wir in den vorhergegangenen 2 Versionen.
Auch der RS485-Teil funktioniert nun. Siehe hier:
http://forum.fhem.de/index.php/topic,22952.msg176991.html#msg176991
Somit kann ich die Tage auch wieder ein paar Sensoren Zusammenbauen.
Viele Grüße
Dirk
Zitat von: Dirk am 16 Juni 2014, 00:07:23
Die Tests sind bisher alle positiv verlaufen. Der Funk-Teil funktioniert wir in den vorhergegangenen 2 Versionen.
Auch der RS485-Teil funktioniert nun. Siehe hier:
http://forum.fhem.de/index.php/topic,22952.msg176991.html#msg176991
Großartig! *thumbsUp*
DAU-Frage: Spricht etwas dagegen, bei dem Board den größeren Atmega zu verbauen und sich dem OTA-Bootloader zu bedienen? Gerade bei der Häufigkeit, wie es zZ Updates zu testen gibt, will man die Sensoren schließlich nicht ständig abmontieren müssen. Und das ist jetzt noch viel interessanter geworden, da diese jetzt auch noch 1-wire können. ;-)
Ansonsten bräuchte ich letztendlich wohl 4+1 Stück (da wäre flashen OTA nicht verkehrt). Wobei natürlich die Frage ist, was die Boards letztendlich mit den einzelnen Sensoren kosten werden.
Tausend Dank an alle Beteiligten! :-)
Zitat von: kaihs am 15 Juni 2014, 23:34:43
Kannst du bitte kurz zusammenfassen, was man machen muss, um den Code von https://github.com/trilu2000/AskSin (https://github.com/trilu2000/AskSin) mit der Arduino IDE compilieren zu können?
Nur den Sketch zu öffnen reicht nicht, weil dann die Include Files nicht gefunden werden. Noch irgendwas mit den Arduino Libraries?
Die AskSin-Library hat gar kein Sketch, oder? Zumindest sehe ich keine ino-Datei. Als ich die Firmware hier kompiliert habe, habe ich die AskSin-Lib und die anderen Abhängigkeiten von hier (https://github.com/kc-GitHub/Wettersensor/tree/master/Libraries) als Libs hinzugefügt. Kompilieren ging dann, aber es gab dann Linker-Fehler, da Asksin ihrerseits diese anderen Libs benutzen wollte, was die IDE so nicht erkannt hat (also Lib benutzt andere Libs).
Ich hab dann ganz oben in der cpp der Firmware nochmal die Header der anderen Libs eingefügt und dann hat die IDE diese Sachen auch korrekt mitkompiliert und gelinkt:
#include <Sensirion.h>
#include <Wire.h>
#include <BMP085.h>Von alleine kapiert das die IDE scheinbar nicht, wenn Libs ihrerseits auf andere Libs angewiesen sind. Erklärung zum Beispiel hier: http://provideyourown.com/2011/advanced-arduino-including-multiple-libraries/
Speziell der Part "Getting Your Library to Link to another Library".
Es gibt ja im Firmware-Ordner zwei verschiedene Firmwares für Indoor und Outdoor. Wenn ich die Firmware normal mit Arduino kompilieren, habe ich dann die Indoor oder die Outdoor? Bzw. wie kann ich einstellen, welche ich kompilieren möchte. Ich habe kein Define oder ähnliches finden können :/
Zitat von: vbs am 17 Juni 2014, 21:32:57
Es gibt ja im Firmware-Ordner zwei verschiedene Firmwares für Indoor und Outdoor. Wenn ich die Firmware normal mit Arduino kompilieren, habe ich dann die Indoor oder die Outdoor? Bzw. wie kann ich einstellen, welche ich kompilieren möchte. Ich habe kein Define oder ähnliches finden können :/
Hi,
in der Datei Register.h steht das hier:
const uint8_t devParam[] PROGMEM = {
0x08, // The firmware version, 1 byte
0xF1, 0x01, // The model-ID 0xF1 0x01 = DIY (HB-UW-Sen-THPL-I)
// 0xF1, 0x02, // The model-ID 0xF1 0x01 = DIY (HB-UW-Sen-THPL-O)
Ich denke also normalerweise den für Indoor. Ich weiß aber nicht, ob das tatsächlich irgendwo einen Unterschied macht.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 17 Juni 2014, 21:53:28
Ich denke also normalerweise den für Indoor. Ich weiß aber nicht, ob das tatsächlich irgendwo einen Unterschied macht.
Technisch gesehen macht HB-UW-Sen-THPL-I (Indor) und HB-UW-Sen-THPL-O (Outdoor) das Selbe.
Ich habe nur 2 unterschiedliche Devicetypes vergeben, um im FHEM unterschiedliche Models zu Implementieren und für die CCU zwei unterschiedliche Devices mit auch unterschiedlichen Icons zu bekommen.
Zitat von: vbs am 16 Juni 2014, 17:47:42
Ich hab dann ganz oben in der cpp der Firmware nochmal die Header der anderen Libs eingefügt und dann hat die IDE diese Sachen auch korrekt mitkompiliert und gelinkt
Das sollte eigentlich gar nicht nötig sein.
Ich schau mir das aber noch mal an. Ggf. gibt es da noch einen Bug
Gruß
Dirk
Zitat von: Dirk am 17 Juni 2014, 22:11:35
Das sollte eigentlich gar nicht nötig sein.
Ich schau mir das aber noch mal an. Ggf. gibt es da noch einen Bug
Inhaltlich ist das wirklich nicht nötig. Das scheint einfach ein "Hack" zu sein, um die Arduino-IDE dazu zu bewegen, Libraries zu linken, die nur von anderen Libraries verwendet werden (nicht aber von dem Sketch selbst). Ist vielleicht einfach eine Eigenart der Arduino-IDE?
Ohne die Zusatz-Includes hatte ich "undefined Reference"-Fehler.
Danke übrigens, konnte jetzt die Indoor-FW kompilieren, flashen und läuft sogar :) Jetzt will ich nur noch das ISP-Flashen bzw. DebugWire-Debuggen in Gang bekommen...
Zitat von: vbs am 17 Juni 2014, 22:22:18
Jetzt will ich nur noch das ISP-Flashen bzw. DebugWire-Debuggen in Gang bekommen...
Wenn du willst kannst du den Bootloader benutzen der in den Sourcen mit dabei ist.
Das ist der Arduino-Bootloader mit einer kleinen Modifikation dass die LED beim Flashen und beim Starten blinkt.
Hatte fast was vergessen: Inbetriebnahme des SHT10
Aber leider auch hier: Klappt alles auf Anhieb! Laaaaangweilig :P
Beschaltung rausgesucht, drangelötet, läuft! Glückwunsch & Danke an alle Beteiligten :)
Ich hab den Sensor zum Testen erstmal nur provisorisch angelötet. Wie habt ihr den verbunden? Per Stiftleiste? Direkt aufs Board gesteckt?
Muss da ein Loch ins Gehäuse? Ist ja wahrscheinlich sonst schwierig mit der Messung der Luftfeuchte.
PS. Bitte keine Witze über meine Lötkünste
(https://dl.dropboxusercontent.com/u/24641738/sht10.JPG)
Hallo,
Zitat von: vbs am 18 Juni 2014, 21:58:51
Aber leider auch hier: Klappt alles auf Anhieb! Laaaaangweilig :P
Ich werde als Option noch eine "Abenteuer-Version" mit Fehlersuche anbieten :)
Zitat
Muss da ein Loch ins Gehäuse? Ist ja wahrscheinlich sonst schwierig mit der Messung der Luftfeuchte.
Ja, der Sensor war zum nach außen Führen geplant. Ggf. auch weiter abgesetzt vom Gehäuse.
Viele Grüße
Dirk
Zitat von: Dirk am 19 Juni 2014, 11:32:59
Ich werde als Option noch eine "Abenteuer-Version" mit Fehlersuche anbieten :)
;D
Zitat von: Dirk am 19 Juni 2014, 11:32:59
Ja, der Sensor war zum nach außen Führen geplant. Ggf. auch weiter abgesetzt vom Gehäuse.
Warum abgesetzt? Einfach um eine bessere Messposition haben zu können oder hat das noch technisch Gründe?
Mein Ansatz wäre es erstmal, den SHT10 im normalen Gehäuse zu belassen, jedoch irgendwie eine Möglichkeit zum Luftaustausch zu schaffen. Wie wäre es mit einem Loch im Gehäuse und das dann verschließen mit zB sowas: http://www.extremtextil.de/catalog/Nylon-PU-beschichtet-atmungsaktiv-100den-80g-qm::1764.html?XTCsid=9b6595d7929f33c82ea51d6a84fdc802
Also wasserdicht, aber atmungsaktiv. Was haltet ihr davon? Schon andere Ideen?
Zitat von: vbs am 19 Juni 2014, 21:13:21
Warum abgesetzt? Einfach um eine bessere Messposition haben zu können oder hat das noch technisch Gründe?
Weil, wenn man das Gehäuse in die Sonne "hängt", wegen dem Helligkeitssensor, im Gehäuse schon mal > 40 °C entstehen.
Dann misst der Temp/Feuchte-Sensor natürlich mist.
So könnte man den Sensor mit einem etwas längerem Kabel ggf. an eine schattigere Stelle verlegen.
ZitatAlso wasserdicht, aber atmungsaktiv. Was haltet ihr davon? Schon andere Ideen?
Ich vermute das wird ähnlich wie ein Zelt im Sommer?
Gruß
Dirk
Zitat von: Dirk am 19 Juni 2014, 22:00:15
Ich vermute das wird ähnlich wie ein Zelt im Sommer?
Bin mir nicht sicher, was du meinst. Luftaustausch nicht ausreichend?
Wie würdest du den SHT10 "einpacken", damit er vor Nässe geschützt ist aber doch ordentlich messen kann?
ZitatBin mir nicht sicher, was du meinst. Luftaustausch nicht ausreichend?
Das könnte schon sein, aber vermutlich nicht in der direkten Sonne.
ZitatWie würdest du den SHT10 "einpacken", damit er vor Nässe geschützt ist aber doch ordentlich messen kann?
Dein Stoff könnte schon gehen, aber ich würde den SHT dann Sonnengeschützt unterbringen. Damit der eine Sinnvolle Temperatur / Feuchte messen kann.
Gruß
Dirk
Zitat von: vbs am 19 Juni 2014, 22:22:52
Wie würdest du den SHT10 "einpacken", damit er vor Nässe geschützt ist aber doch ordentlich messen kann?
http://www.sensirion.com/de/produkte/feuchte-und-temperatur/filterkappen/filterkappe-fuer-sht1x/
Zitat von: Dirk am 09 Juni 2014, 18:58:24
Definitiv nicht.
Ich habe hier ähnliche Beobachtungen gemacht.
Ich muss hier vermutlich die FW noch mal nachbessern. Da hier noch nicht alle Energiesparmaßnahmen greifen.
Gibts denn zum Thema "hoher Energieverbrauch" schon Neuigkeiten? Ich hab grade wieder die Batteriewarnung *grummel*
Hallo,
ich hatte ja auch das Problem. Nutze allerdings Eneloop Akkus und habe den Bewegungsmelder mit angeschlossen.
Aktuell habe ich seit dem letzten mal einen Spannungabfall von 2,5irgendwas auf 2,43V
Bei mir scheint es in Ordnung.
was soll mir das jetzt sagen?
Nun hab ich doch ein kleines Problemchen festgestellt:
Und zwar ist es so, dass der Sensor beim Versenden von Readings unregelmäßig fehlschlägt. Also der Sensor blink dann kurz-lang anstatt von kurz-kurz und in FHEM kommt dann auch nix an. Das Ganze passiert irgendwie unregelmäßig, aber ich würde schätzen, dass es vielleicht bei einem Drittel der Versuche passiert. Es kann auch mal dreimal gut gehen und dann gehts wieder dreimal in die Hose.
Ist das bei euch auch so bzw. ist das normales Verhalten? Wenn nicht, dann würde ich jetzt mal Rohdaten im HMLAN aufzeichnen oder was wäre da hilfreich? Wahrscheinlich mit einer Serial-Debug-FW gucken, was der Sensor dazu sagt? Ich benutze übrigens die Firmware 0.8, aber mit dem git-Master passiert das auch.
Das passiert auch ohne angeschlossenen SHT. Ansonsten hab ich eigentlich keine Probleme bei der Kommunikation:
protoEvents done:
name :State |CmdPend |Snd |LastRcv |Resnd #CmdDel |ResndFail |Nack |IOerr
env_thps : done | - |83:06-22 11:55:09 |06-22 11:55:09| - # - | - | - | -
Hab mal ein längeres Stück Daten vom seriellen Port aufgenommen:
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2014.06.22 17:36:09 =~=~=~=~=~=~=~=~=~=~=~=
<- 14 00 A2 70 0B 69 DC F1 55 44 00 DA 00 03 F1 00 00 2B 47 09 5C (l:21)(2023)
-> NA (2719)
<- 14 01 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F1 00 00 2C A2 09 5C (l:21)(164183)
-> 0A 01 80 02 F1 55 44 0B 69 DC 00 (l:11)(164324)
<- 14 02 A2 70 0B 69 DC F1 55 44 00 DA 00 03 F1 00 00 2F 34 09 5C (l:21)(290752)
-> NA (291450)
<- 14 03 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F1 00 00 29 66 09 68 (l:21)(467185)
-> 0A 03 80 02 F1 55 44 0B 69 DC 00 (l:11)(467326)
<- 14 04 A2 70 0B 69 DC F1 55 44 00 DC 00 03 F1 00 00 23 52 09 68 (l:21)(629130)
-> 0A 04 80 02 F1 55 44 0B 69 DC 00 (l:11)(629272)
<- 14 05 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F1 00 00 16 A1 09 6E (l:21)(776514)
-> 0A 05 80 02 F1 55 44 0B 69 DC 00 (l:11)(776656)
<- 14 06 A2 70 0B 69 DC F1 55 44 00 DA 00 03 F1 00 00 0F D1 09 62 (l:21)(909606)
-> 0A 06 80 02 F1 55 44 0B 69 DC 00 (l:11)(909747)
<- 14 07 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F1 00 00 11 55 09 62 (l:21)(1092316)
-> 0A 07 80 02 F1 55 44 0B 69 DC 00 (l:11)(1092457)
<- 14 08 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F1 00 00 1B 1E 09 56 (l:21)(1260483)
-> 0A 08 80 02 F1 55 44 0B 69 DC 00 (l:11)(1260624)
<- 14 09 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F1 00 00 34 DB 09 62 (l:21)(1414391)
-> NA (1415088)
<- 14 0A A2 70 0B 69 DC F1 55 44 00 DB 00 03 F1 00 00 39 1A 09 5C (l:21)(1553769)
-> 0A 0A 80 02 F1 55 44 0B 69 DC 00 (l:11)(1553910)
<- 14 0B A2 70 0B 69 DC F1 55 44 00 DC 00 03 F1 00 00 32 C4 09 62 (l:21)(1678591)
-> 0A 0B 80 02 F1 55 44 0B 69 DC 00 (l:11)(1678733)
<- 14 0C A2 70 0B 69 DC F1 55 44 00 DD 00 03 F1 00 00 2B 20 09 62 (l:21)(1853027)
-> NA (1853723)
<- 14 0D A2 70 0B 69 DC F1 55 44 00 DE 00 03 F1 00 00 1C AD 09 6E (l:21)(2013163)
-> 0A 0D 80 02 F1 55 44 0B 69 DC 00 (l:11)(2013304)
<- 14 0E A2 70 0B 69 DC F1 55 44 00 DF 00 03 F1 00 00 1A 0B 09 62 (l:21)(2158799)
-> NA (2159495)
<- 14 0F A2 70 0B 69 DC F1 55 44 00 DF 00 03 F1 00 00 16 AE 09 6E (l:21)(2289883)
-> 0A 0F 80 02 F1 55 44 0B 69 DC 00 (l:11)(2290025)
<- 14 10 A2 70 0B 69 DC F1 55 44 00 DF 00 03 F1 00 00 19 2F 09 5C (l:21)(2470837)
-> NA (2471536)
<- 14 11 A2 70 0B 69 DC F1 55 44 00 DF 00 03 F1 00 00 21 E2 09 62 (l:21)(2637270)
-> 0A 11 80 02 F1 55 44 0B 69 DC 00 (l:11)(2637411)
<- 14 12 A2 70 0B 69 DC F1 55 44 00 E0 00 03 F1 00 00 32 B1 09 68 (l:21)(2789160)
-> NA (2789857)
<- 14 13 A2 70 0B 69 DC F1 55 44 00 E0 00 03 F1 00 00 23 7D 09 5C (l:21)(2926753)
-> 0A 13 80 02 F1 55 44 0B 69 DC 00 (l:11)(2926894)
<- 14 14 A2 70 0B 69 DC F1 55 44 00 E0 00 03 F1 00 00 25 DE 09 6E (l:21)(3049824)
-> NA (3050520)
<- 14 15 A2 70 0B 69 DC F1 55 44 00 E0 00 03 F1 00 00 23 81 09 68 (l:21)(3222506)
-> 0A 15 80 02 F1 55 44 0B 69 DC 00 (l:11)(3222646)
<- 14 16 A2 70 0B 69 DC F1 55 44 00 E0 00 03 F1 00 00 25 73 09 5C (l:21)(3380661)
-> 0A 16 80 02 F1 55 44 0B 69 DC 00 (l:11)(3380802)
<- 14 17 A2 70 0B 69 DC F1 55 44 00 E0 00 03 F1 00 00 22 D5 09 6E (l:21)(3524527)
-> 0A 17 80 02 F1 55 44 0B 69 DC 00 (l:11)(3524668)
<- 14 18 A2 70 0B 69 DC F1 55 44 00 E0 00 03 F1 00 00 21 CA 09 5C (l:21)(3653870)
-> NA (3654566)
<- 14 19 A2 70 0B 69 DC F1 55 44 00 E0 00 03 F1 00 00 20 05 09 68 (l:21)(3832823)
-> 0A 19 80 02 F1 55 44 0B 69 DC 00 (l:11)(3832963)
<- 14 1A A2 70 0B 69 DC F1 55 44 00 E1 00 03 F1 00 00 20 D3 09 6E (l:21)(3997484)
-> 0A 1A 80 02 F1 55 44 0B 69 DC 00 (l:11)(3997626)
<- 14 1B A2 70 0B 69 DC F1 55 44 00 E1 00 03 F1 00 00 20 CA 09 62 (l:21)(4147620)
-> 0A 1B 80 02 F1 55 44 0B 69 DC 00 (l:11)(4147762)
<- 14 1C A2 70 0B 69 DC F1 55 44 00 E1 00 03 F1 00 00 14 B6 09 68 (l:21)(4283232)
-> NA (4283928)
<- 14 1D A2 70 0B 69 DC F1 55 44 00 E2 00 03 F1 00 00 1E 76 09 68 (l:21)(4404548)
-> NA (4405244)
<- 14 1E A2 70 0B 69 DC F1 55 44 00 E2 00 03 F1 00 00 1D D7 09 6E (l:21)(4575512)
-> 0A 1E 80 02 F1 55 44 0B 69 DC 00 (l:11)(4575651)
<- 14 1F A2 70 0B 69 DC F1 55 44 00 E1 00 03 F1 00 00 21 06 09 68 (l:21)(4731900)
-> 0A 1F 80 02 F1 55 44 0B 69 DC 00 (l:11)(4732041)
<- 14 20 A2 70 0B 69 DC F1 55 44 00 DF 00 03 F1 00 00 1F BE 09 62 (l:21)(4874014)
-> 0A 20 80 02 F1 55 44 0B 69 DC 00 (l:11)(4874153)
<- 14 21 A2 70 0B 69 DC F1 55 44 00 DE 00 03 F1 00 00 1D 92 09 62 (l:21)(5001584)
-> 0A 21 80 02 F1 55 44 0B 69 DC 00 (l:11)(5001726)
<- 14 22 A2 70 0B 69 DC F1 55 44 00 DC 00 03 F1 00 00 1F D8 09 6E (l:21)(5178788)
-> 0A 22 80 02 F1 55 44 0B 69 DC 00 (l:11)(5178929)
<- 14 23 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F1 00 00 1F B4 09 68 (l:21)(5341449)
-> NA (5342145)
<- 14 24 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 1F EB 09 68 (l:21)(5489835)
-> 0A 24 80 02 F1 55 44 0B 69 DC 00 (l:11)(5489976)
<- 14 25 A2 70 0B 69 DC F1 55 44 00 DA 00 03 F1 00 00 1F 38 09 5C (l:21)(5623680)
-> 0A 25 80 02 F1 55 44 0B 69 DC 00 (l:11)(5623821)
<- 14 26 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 1E CC 09 6E (l:21)(5807134)
-> 0A 26 80 02 F1 55 44 0B 69 DC 00 (l:11)(5807275)
<- 14 27 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 1F 54 09 6E (l:21)(5976319)
-> 0A 27 80 02 F1 55 44 0B 69 DC 00 (l:11)(5976460)
<- 14 28 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 1D 9C 09 6E (l:21)(6130957)
-> 0A 28 80 02 F1 55 44 0B 69 DC 00 (l:11)(6131097)
<- 14 29 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 1D 30 09 5C (l:21)(6271071)
-> NA (6271767)
<- 14 2A A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 1A E9 09 6E (l:21)(6396908)
-> NA (6397604)
<- 14 2B A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 1D 09 09 6E (l:21)(6572338)
-> NA (6573035)
<- 14 2C A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 1E E9 09 6E (l:21)(6733246)
-> NA (6733942)
<- 14 2D A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 1A 87 09 68 (l:21)(6879877)
-> NA (6880574)
<- 14 2E A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 18 EA 09 5C (l:21)(7011966)
-> NA (7012662)
<- 14 2F A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 17 81 09 68 (l:21)(7193698)
-> 0A 2F 80 02 F1 55 44 0B 69 DC 00 (l:11)(7193839)
<- 14 30 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 17 3C 09 68 (l:21)(7360879)
-> 0A 30 80 02 F1 55 44 0B 69 DC 00 (l:11)(7361020)
<- 14 31 A2 70 0B 69 DC F1 55 44 00 DA 00 03 F2 00 00 0F C2 09 62 (l:21)(7513765)
-> NA (7514462)
<- 14 32 A2 70 0B 69 DC F1 55 44 00 DA 00 03 F2 00 00 14 83 09 62 (l:21)(7652126)
-> 0A 32 80 02 F1 55 44 0B 69 DC 00 (l:11)(7652268)
<- 14 33 A2 70 0B 69 DC F1 55 44 00 DA 00 03 F2 00 00 12 84 09 68 (l:21)(7775945)
-> 0A 33 80 02 F1 55 44 0B 69 DC 00 (l:11)(7776086)
<- 14 34 A2 70 0B 69 DC F1 55 44 00 DA 00 03 F2 00 00 0E 5D 09 62 (l:21)(7949628)
-> 0A 34 80 02 F1 55 44 0B 69 DC 00 (l:11)(7949770)
<- 14 35 A2 70 0B 69 DC F1 55 44 00 DA 00 03 F2 00 00 0E 7A 09 68 (l:21)(8108785)
-> 0A 35 80 02 F1 55 44 0B 69 DC 00 (l:11)(8108927)
<- 14 36 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 0E 36 09 68 (l:21)(8253411)
-> NA (8254108)
<- 14 37 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 0D A9 09 74 (l:21)(8383752)
-> 0A 37 80 02 F1 55 44 0B 69 DC 00 (l:11)(8383893)
<- 14 38 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 0C D7 09 74 (l:21)(8563708)
-> 0A 38 80 02 F1 55 44 0B 69 DC 00 (l:11)(8563849)
<- 14 39 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 0B DC 09 6E (l:21)(8729123)
-> 0A 39 80 02 F1 55 44 0B 69 DC 00 (l:11)(8729264)
<- 14 3A A2 70 0B 69 DC F1 55 44 00 DC 00 03 F2 00 00 0B 4E 09 68 (l:21)(8880263)
-> NA (8880959)
<- 14 3B A2 70 0B 69 DC F1 55 44 00 DC 00 03 F2 00 00 0A F7 09 62 (l:21)(9016874)
-> 0A 3B 80 02 F1 55 44 0B 69 DC 00 (l:11)(9017015)
<- 14 3C A2 70 0B 69 DC F1 55 44 00 DC 00 03 F2 00 00 0A A6 09 62 (l:21)(9138945)
-> 0A 3C 80 02 F1 55 44 0B 69 DC 00 (l:11)(9139086)
<- 14 3D A2 70 0B 69 DC F1 55 44 00 DC 00 03 F2 00 00 0A 2C 09 6E (l:21)(9310626)
-> NA (9311324)
<- 14 3E A2 70 0B 69 DC F1 55 44 00 DC 00 03 F2 00 00 09 CB 09 6E (l:21)(9468034)
-> NA (9468731)
Ich denke mal, dass immer die Zeilen mit "NA" eine ausgebliebene Antworten sind.
Ich hab auch mal in FHEM die Daten von HMLAN mitgeschnitten. Ein erfolgreicher Versand vom Modul wie der hier:
<- 14 01 A2 70 0B 69 DC F1 55 44 00 DB 00 03 F2 00 00 07 29 09 68 (l:21)(164183)
-> 0A 01 80 02 F1 55 44 0B 69 DC 00 (l:11)(164324)
kommt dann in HMLAN an als (sieht passend aus):
2014.06.22 20:37:15.298 0: HMLAN_Parse: HMLAN0 R:E0B69DC stat:0000 t:0404B659 d:FF r:FFC8 m:01 A270 0B69DC F15544 00DB0003F2000007290968
Die fehlgeschlagenen Aktionen (NA) sind in HMLAN gar nicht zu sehen. Ich hab jedoch auch dieses Attribut gesetzt, um nur die Daten von dem THPS zu sehen:
logIDs env_thps,sys
Zweimal kam übrigens auch sowas:
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2014.06.22 20:19:50 =~=~=~=~=~=~=~=~=~=~=~=
<- 14 00 A2 70 0B 69 DC F1 55 44 00 DC 00 03 F2 00 00 09 7D 09 5C (l:21)(2023)
-> 0A 00 80 02 F1 55 44 0B 69 DC 00 (l:11)(2164)
<- 14 01 A2 70 0B 69 DC F1 55 44 00 DC 00 03 F2 00 00 09 18 09 62 (l:21)(164165)
-> 0A 01 80 02 F1 55 44 0B 69 DC 00 (l:11)(164306)
<- 14 02 A2 70 0B 69 DC F1 55 44 00 DC 00 03 F2 00 00 08 F4 09 68 (l:21)(290737)
-> NA (291436)
<- 14 03 A2 70 0B 69 DC F1 55 44 00 D9 00 03 F2 00 00 08 80 09 62 (l:21)(467176)
-> 0A 03 80 02 F1 55 44 0B 69 DC 00 (l:11)(467316)
b> 0E 9C 84 10 26 17 25 00 00 00 0B A8 DF 0E 29 (l:15)(467848)
UNKNOWN MESSAGE, PLEASE REPORT!
<- 14 04 A2 70 0B 69 DC F1 55 44 00 D9 00 03 F2 00 00 07 E3 09 6E (l:21)(629085)
-> NA (629781)
<- 14 05 A2 70 0B 69 DC F1 55 44 00 DA 00 03 F2 00 00 07 B5 09 5C (l:21)(776467)
-> NA (777163)
Zitat von: vbs am 16 Juni 2014, 17:47:42
Die AskSin-Library hat gar kein Sketch, oder? Zumindest sehe ich keine ino-Datei.
Ich hatte naiverweise versucht die AskSin Library standalone zu compilieren.
Zitat
Als ich die Firmware hier kompiliert habe, habe ich die AskSin-Lib und die anderen Abhängigkeiten von hier (https://github.com/kc-GitHub/Wettersensor/tree/master/Libraries) als Libs hinzugefügt.
Danke für den Hinweis. das habe ich auch gemacht. D.h. ich habe sie in den sketchbook/libraries Ordner kopiert.
Dann komme ich etwas weiter.
Den Fehler, dass <Serial.h> nicht gefunden wird habe ich dadurch beseitigt, dass ich "Serial.h" inkludiere.
Jetzt scheitere ich aber an
In file included from /home/kai/sketchbook/libraries/AskSin/AskSinMain.h:33:0,
from Register.h:1,
from WetterSensor.ino:7:
/home/kai/sketchbook/libraries/AskSin/utility/Fastdelegate.h:57:48: fatal error: memory.h: No such file or directory
#include <memory.h> // to allow <,> comparisons
^
compilation terminated.
Mein avr-gcc enthält kein memory.h. Installiert ist der über die Paketverwaltung von openSuSE, avr-gcc Version 4.8.2.
Mit welchem Betriebssystemen und Compilern arbeitet ihr?
Gruß,
Kai
Sorry, ich war die letzten Tage etwas anderweitig eingespannt.
Zitat von: betateilchen am 20 Juni 2014, 14:20:05
Gibts denn zum Thema "hoher Energieverbrauch" schon Neuigkeiten? Ich hab grade wieder die Batteriewarnung *grummel*
Kannst du bitte mal den Stromverbrauch vom Sensor messen.
Was für Batterien oder Akkus benutzt du?
Zitat von: vbs am 22 Juni 2014, 11:58:36
Und zwar ist es so, dass der Sensor beim Versenden von Readings unregelmäßig fehlschlägt. Also der Sensor blink dann kurz-lang anstatt von kurz-kurz und in FHEM kommt dann auch nix an.
Das habe ich hier auch. Aber auch mit anderen fertigen Sensoren / Aktoren. Daher habe ich das bisher auf Funkstörungen geschoben.
Aktuell sendet die Firmware nur genau 1 mal. Eigentlich ist das nicht korrekt. Daher werde ich das in der nächsten FW-Version wieder ändern.
In Register.h das hier ersetzen:
HM::s_devParm dParm = {
1, // send retries, 1 byte, how often a string should be send out until we get an answer
700, // send timeout, 2 byte, time out for ACK handling
devParam // pointer to devParam, see above
};
durch
HM::s_devParm dParm = {
3, // send retries, 1 byte, how often a string should be send out until we get an answer
700, // send timeout, 2 byte, time out for ACK handling
devParam // pointer to devParam, see above
};
Dann versucht der Sensor 3 mal zu senden.
Zitat von: kaihs am 23 Juni 2014, 00:01:51
Mein avr-gcc enthält kein memory.h. Installiert ist der über die Paketverwaltung von openSuSE, avr-gcc Version 4.8.2.
Ich nutze WinAVR mit Eclipse und dem Aruino-Plugin auf Win7
Gruß
Dirk
Ich habe jetzt nochmal die Funkübertragung hoch und runter getestet und meiner Meinung nach besteht da irgendein Problem bei der Funkkommunikation. Ich hab keine handfesten Beweise, aber ich denke, dass ich es statistisch belegen kann. Und zwar hab ich (im Rahmen meiner Möglichkeiten) die Kommunikation des Sensor mit der eines echten Homematic-Wandtasters verglichen. Ein Wandtaster, weil ich da manuell Daten senden kann und auch an der LED sehen kann, ob ein ACK gekommen ist (nach bis zu 3 Versuchen).
Dies sind zunächst die seriellen Ausgaben des Sensor über ungefähr 9 Stunden:
http://pastebin.com/D3ksbRB4
Das sind 226 Transfers. 130 davon wurden nicht korrekt beantwortet (also eine Erfolgsquote von nur 42%).
Dann hab ich ungefähr 160 mal (ja, war nervig :D) den Wandtaster betätigt. Also der hat kein einziges Mal eine rote LED gezeigt. Immer brav grün. Also ACK bekommen. Dann hab ich mir noch die HMLAN-Empfangsdaten angesehen und ich habe nur zwei Fälle gesehen, bei denen ich *vermute*, dass der Wandtaster den Befehl ein zweites Mal schicken musste. Sagen wir, ich habe noch ein paar übersehen und wir gehen von 5 aus.
Das würde bedeuten, dass bei dem Wandtaster 221 von 226 Transfers erfolgreich waren. Also eine Quote von knapp 98%.
So sieht bei mir Ausgabe von protoEvents aus:
protoEvents done:
name :State |CmdPend |Snd |LastRcv |Resnd #CmdDel |ResndFail |Nack |IOerr
env_thps : done | - |246:06-25 22:07:24|06-25 22:07:24| - # - | - | - | -
env_virtActor : done | - |315:06-25 21:38:49| - | - # - | - | - | -
env_virtActorDim : - | - | - | - | - # - | - | - | -
fl_eingangTaster : - | - | - | - | - # - | - | - | -
fl_wandTaster : - | - | - |06-25 21:38:49| - # - | - | - | -
ku_wandTaster : - | - | - | - | - # - | - | - | -
sz_ambientLight : done | - |10:06-25 00:29:09 |06-25 00:29:09| - # - | - | - | -
sz_presenceTaster : - | - | - |06-25 07:49:39| - # - | - | - | -
sz_spotLight : done | - |10:06-25 00:15:28 |06-25 00:15:28| - # - | - | - | -
wz_hmRt : done | - |1:06-25 11:17:36 |06-25 22:07:18| - # - | - | - | -
wz_hmTc : done | - |9:06-25 20:49:41 |06-25 22:07:43| - # - | - | - | -
wz_lightCrystal : done | - |63:06-25 21:45:15 |06-25 21:45:15| - # - | - | - | -
wz_lightDesk : done | - |61:06-25 21:45:14 |06-25 21:45:14| - # - | - | - | -
wz_lightRed : done | - |72:06-25 21:54:56 |06-25 21:54:56| - # - | - | - | -
wz_lightSpot : done | - |28:06-24 21:39:14 |06-24 21:39:14| - # - | - | - | -
wz_wandTaster : - | - | - |06-25 08:39:41| - # - | - | - | -
================================================================================================================
sum 0 |0 |815 |72 |0 #0 |0 |0 |0
Da wird kein einziger Resend verzeichnet.
Also für mich sieht es so aus, als wäre die Funkkommunikation mit "normalen" HM-Geräten sehr stabil und im Normalfalle werden nahezu alle Transfers erfolgreich abgewickelt.
Mit dem Sensor hier ist bei mir die Quote nicht so gut (<50%). Daher denke ich, dass da irgendwo noch ein Wurm drin steckt. Ich hab natürlich keine Idee wo.
Selbst das Einbauen der 3 Retries würde das nicht komplett lösen, da teilweise bis zu 6 Transfers in Folge fehlschlagen.
Wie ist eure Meinung dazu? Ich habe nicht so die Erfahrung mit Funktechnik und ich hab das ganze jetzt nur mit laienhaften Tests untersucht. Ich lass mich gerne belehren, wenn ich etwas missverstanden oder missinterpretiert habe.
Zitat von: Dirk am 24 Juni 2014, 10:47:47
Kannst du bitte mal den Stromverbrauch vom Sensor messen.
Was für Batterien oder Akkus benutzt du?
2 x AA hochwertige Alkaline Batterien. Gestern abend um 18:45 hat der Sensor das Sensor komplett eingestellt. Die Batteriespannung war dabei auf 2.14V gesunken.
Messen kann ich erst nach meinem Urlaub.
Hallo,
ich habe einen Aussensensor mit MAX chip und als ich irdümlich einen Akku und eine Batterie eingelegt hatte hat der Sensor sogar mit einer Spannung von 1,23V noch ohne Probleme Funktioniert und das war als der Akku leer war und nur mehr 0,2V Zellenspannung hatte.
Nun habe ich einen neuen Satz Batterien vor 2 Wochen eingelegt und ich Zeichne die Batteriespannung auf, aber seht selbst die Bilder der Graphen.
LG
Franz
Hallo,
das sieht so aus, als wenn kein Sleepmodus eingebaut ist. Ich hatte so etwas als ich mit dem Panstamp versucht habe meine S0 Zähler zu überwachen. Nachdem ich den WDT (1sec) eingebaut habe, wurde das besser, aber die Sendeintervalle waren sehr unregelmäßig. Da millis() nicht läuft, habe ich jetzt den WDT mit einer sehr kurzen Zeit (6ms) eingestellt und zähle die Schlafabschnitte. Das klappt gut (max. Drift + 30 sec bei 15 Minuten Sendeintervall) und die Akku sind jetzt seit 2 Monaten drin (immer noch über 1,2 V).
Gruß Christoph
Zitat von: Bennemannc am 26 Juni 2014, 10:38:32
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.
Zitat von: Franz74 am 26 Juni 2014, 09:59:34
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.
Zitat von: betateilchen am 26 Juni 2014, 09:36:39
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
Was ist eure Meinung zu dem häufigen Fehlern bei den Sendeversuchen?
Hallo
Zitat von: vbs am 29 Juni 2014, 00:25:06
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.
ZitatSelbst 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
Hi,
hab den Fred auf Dirks Anfrage wieder geöffnet.
Warum der geschlossen war - keine Ahnung.
Gruß, Uli
Zitat von: UliM am 30 Juni 2014, 21:34:27
Hi,
hab den Fred auf Dirks Anfrage wieder geöffnet.
Warum der geschlossen war - keine Ahnung.
Gruß, Uli
Vielen Dank!
LG
Franz
Zitat von: Mr. P am 30 Juni 2014, 21:50:34
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
Ich bin nochmal dem Übertragungsproblem nachgegangen (http://forum.fhem.de/index.php/topic,14140.msg180923.html#msg180923 (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?
hallo vbs,
ZitatAlso 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
Zitat von: frank am 05 Juli 2014, 16:02:10
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.
Zitat von: frank am 05 Juli 2014, 16:02:10
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.
Zitat von: frank am 05 Juli 2014, 16:02:10
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.
Zitatohne Burst -> geht nicht
was genau bedeutet geht nicht? message wird gesendet, aber nirgendwo empfangen?
ZitatSchwankt 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.
Zitat von: frank am 05 Juli 2014, 16:53:16
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.
Zitat von: frank am 05 Juli 2014, 16:53:16
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?
ZitatDas 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?
Zitat von: frank am 05 Juli 2014, 17:55:03
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.
Zitat von: frank am 05 Juli 2014, 17:55:03
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.
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)"
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....
Getestet hab ich das ja schon. Mit 10 ms wird es wie gesagt etwas besser, aber löst (zumindest bei mir) das Problem nicht. Selbst mit 3 Retries hab ich dann immer noch fehlgeschlagene Übertragungen. Selbst bei 30 ms schlagen ab und zu noch welche fehl. Ich habe jetzt seit ein paar Stunden mit 40 ms am Laufen und habe jetzt 3500 Nachrichten fehlerfrei übertragen.
Alle Tests eben inklusive der 3 Retries.
Übrigens denke ich, dass du momentan im nicht-Burst-Modus das Trägersignal bzw. Präambel gar nicht setzt (eben nur die Standard 4-Bit-Präambel, die immer kommt), da vor dem delay(1) der TX-Mode gar nicht gesetzt wird, oder?
Bei mir sieht das im Moment so aus. Also TX-Mode wird gesetzt und dann je nachdem ob Burst oder nicht, eine 360 bzw 40 ms Präambel gesendet:
cmdStrobe(CC1101_STX );
if (burst) {
_delay_ms(360);
} else {
_delay_ms(40);
}
vielleicht kenne ich mich mit dem cc1101 zu wenig aus, aber ich schalte nur den übertragungsmodus ein, eine präambel wird zu diesem zeitpunkt nicht gesendet.
ich komme aus dem IDLE und sende STX an den chip, d.h.
Frequency synthesizer is turned on, can optionally be calibrated, and then settles to the correct frequency. Transitional state. Typ. current consumption: 8.4 mA.
wenn ich dann was in den fifo rein schreibe, werden die preamble bytes gesendet, zumindest mein verständnis.
ich glaube viel eher, dein sendemodul oder dein empfänger haben ein frequenzproblem.
der synthesizer muss sich ja auf die richtige frequenz einpendeln - welche hardware nutzt du?
Zitat von: trilu am 05 Juli 2014, 19:03:43
vielleicht kenne ich mich mit dem cc1101 zu wenig aus, aber ich schalte nur den übertragungsmodus ein, eine präambel wird zu diesem zeitpunkt nicht gesendet.
ich komme aus dem IDLE und sende STX an den chip, d.h. wenn ich dann was in den fifo rein schreibe, werden die preamble bytes gesendet, zumindest mein verständnis.
Ich bin Anfänger, also kein Anspruch auf Richtigkeit 8) Aber meiner Meinung nach passiert folgendes, wenn man in den TX-Mode schaltet:
- Wenn Daten im TX-FIFO sind, dann werde diese gesendet (vorangestellte wird die konfigurierte 4-Bit-Präambel)
- Wenn keine Daten im TX-FIFO sind, dann sendet der Chip Präambeln bis Daten in den TX-FIFO geschrieben werden
Aus der CC1101-Doku:
ZitatWhen enabling
TX, the modulator will start transmitting the
preamble. When the programmed number of
preamble bytes has been transmitted, the
modulator will send the sync word and then
data from the TX FIFO if data is available. If
the TX FIFO is empty, the modulator will
continue to send preamble bytes until the first
byte is written to the TX FIFO.
Also im Moment läuft das in der Lib so (im Burst-Modus):
- TX-Mode einschalten (da noch keine Daten im TX-FIFO sind, fängt der Chip an, Präambeln zu senden
- 360 ms warten (Chip sendet weiter Präambeln)
- Nutzdaten in den TX-FIFO schreiben, die sofort versendet werden
- TX-Mode verlassen
Zitat von: trilu am 05 Juli 2014, 19:03:43
ich glaube viel eher, dein sendemodul oder dein empfänger haben ein frequenzproblem.
der synthesizer muss sich ja auf die richtige frequenz einpendeln - welche hardware nutzt du?
Durchaus möglich. Aber ich würde dann eigentlich erwarten, dass ich dann immer mal wieder Übertrangungsprobleme hätte, wenn da etwas mit den Frequenzen nicht stimmt, oder? Das Problem hätte ich doch nicht lösen können, indem ich eine längere Präambel sende? Ich würde dann immer mal wieder CRC-Fehler oder so erwarten.
Ich nutze den Außensensor von Dirk und einen HMLAN als Empfänger.
Gibt es denn jemanden, bei dem diese Kombination ohne Übertrangungsfehler (bzw. Erfolgsquote jenseits 90%) out-of-the-box funktioniert. Also Dirk sagte, dass er auch ab und zu Aussetzer hat. Ich weiss aber nicht, ob das bei ihm so schlimm ist wie bei mir.
Zitat von: vbs am 05 Juli 2014, 19:56:46
Ich nutze den Außensensor von Dirk und einen HMLAN als Empfänger.
Gibt es denn jemanden, bei dem diese Kombination ohne Übertrangungsfehler (bzw. Erfolgsquote jenseits 90%) out-of-the-box funktioniert.
Ob Außen oder Innensensor sollte eigentlich egal sein. Bis auf die Sensorbeschaltung und die mechanischen Abmessungen sind die im Prinzip identisch.
Ich werde die Tage auch noch mal ein paar Versuche machen.
Bei meinem Sensor auf dem Balkon kamen in den letzten Stunden etwa 50-70 % der Messages an, wenn ich davon ausgehe dass diese etwa alle 2,5 - 3 Min. Gesendet werden.
Somit sollten bei 100% etwa 22 Nachrichten pro Stunde ankommen.
Allerdings habe ich hier noch kein Retry aktiviert.
Die Sensoren empfange ich aktuell mit der CCU und leite die per XML-RPC an FHEM weiter.
Gruß
Dirk
Ahh, hi Dirk! :)
Sehr interessant, 50-70% ist das, was ich normalerweise auch so habe im Urzustand. Falls du mal dazu kommen solltest, wäre es interessant, ob sich das bei dir auch so wesentlich verbessert, wenn du den Burst-Mode erzwingst beim Senden. Ich komme dann auf irgendwas nahe 100% (99,irgendwas). Also ohne Retry.
Aber ich weiss, dass du im Moment sehr busy bist... also wenn du das im Moment nicht hinkriegst, ist das natürlich verständlich...
hallo vbs,
Zitat von: trilu am 05 Juli 2014, 19:03:43
vielleicht kenne ich mich mit dem cc1101 zu wenig aus, aber ich schalte nur den übertragungsmodus ein, eine präambel wird zu diesem zeitpunkt nicht gesendet.
ich komme aus dem IDLE und sende STX an den chip, d.h.
Frequency synthesizer is turned on, can optionally be calibrated, and then settles to the correct frequency. Transitional state. Typ. current consumption: 8.4 mA.
wenn ich dann was in den fifo rein schreibe, werden die preamble bytes gesendet, zumindest mein verständnis.
ich glaube viel eher, dein sendemodul oder dein empfänger haben ein frequenzproblem.
der synthesizer muss sich ja auf die richtige frequenz einpendeln - welche hardware nutzt du?
versuch doch mal an der stelle den synthesizer zu kalibrieren. 868,3 mhz oder etwas mehr. vielleicht ist die versorgungsspg für die funkmodule grenzwertig oder sie sind auf 868,0mhz voreingestellt.
Ok, habe mir mal die Frequenzen näher angesehen. Also die schlechte Nachricht zuerst: Meiner Meinung nach stimmt das (leider) erstmal alles so. Die Frequenz ist eingestellt auf 868,2998657 MHz. Beim Initialisieren wird einmal per Hand die Kalibration angestartet. Weiterhin wird die Option genutzt, die bei jedem Wechsel in den TX-Mode erneut eine Kalibration durchführt. Also meiner Meinung nach erstmal alles so, wie es sein sollte.
Aber: Ich hab mal etwas an der Frequenz rumgedreht und es stellte sich raus, dass wenn ich die Frequenz leicht absenke, dann verschwindet das Problem und es kommen ca. 99% der Nachrichten an!! Die Frequenz zu erhöhen hat jedoch den Fehler sofort noch weiter verstärkt. Da war auch bei kleinsten Erhöhungen praktisch keine Kommunikation mehr möglich.
Also ich hab jetzt die besten Ergebnisse mit einer Frequenz von 868,2895508 (anstatt 868,2998657) MHz. Bei 648 Übertragung gab es da 5 Retries. Das Beste: die anderen Änderungen (Senden einer längeren Präambel bei Nicht-Burst-Geräten) können damit scheinbar komplett entfallen. Benutze im Moment wieder den Original-Firmware Code nur mit der geänderten Frequenz. Wie es sein soll ;)
Also ich bin erstmal happy :D Erstmal großen Dank an alle Beteiligten (vor allem trillu und frank) für den Tipp mit der Frequenz!! ;)
Was ich allerdings nicht weiß ist, wie sehr die Frequenz zB beim HMLAN von Gerät zu Gerät schwankt. Nicht das ich jetzt mit dem Wert von 868,2895 MHz genau für mein Geräte optimiert habe und bei anderen machts das vielleicht schlimmer. :(
Im Anhang mal die gepatchte Firmware. Entspricht 1:1 dem aktuellen Master aber eben mit der genannten Frequenzänderung. Vielleicht mag das mal jemand testen. Interessant wäre, ob Leute, die vorher keine Probleme hatten, weiterhin keine Probleme haben und ob bei Leuten, die das Problem haben, es damit gelöst/besser wird. Ich werde natürlich auch noch etwas weiter testen...
Achso: Retries sind in der Firmware auf 3 eingestellt.
Hallo Dirk !
ZitatDie Tests sind bisher alle positiv verlaufen. Der Funk-Teil funktioniert wir in den vorhergegangenen 2 Versionen.
Auch der RS485-Teil funktioniert nun. Siehe hier:
Bedeutet das, dass man die RS485 Version jetzt bei Dir per PM ordern kann ?
Gruß, Marc
freut mich das es jetzt ohne burst so gut klappt. mir ist noch eine weitere idee eingefallen :-)
in der cc1101 init setze ich den funk auf volle power
writeReg(CC1101_PATABLE, PA_MaxPower); // configure PATABLE
vielleicht verändert das auch die frequenz oder es gibt interferenzen....
@vbs.
Das sollten wir nochmal weiter beobachten.
Ich werde auch mal verschiedene Empfänger vergleichen.
CCU, HM-LAN, CUL
Und mir mit dem SRD mal ansehen auf welcher Frequenz da wirklich gesendet wird.
@Marc
Die Hardware für RS485 ist fertig, und ja, Ich kann dir so eine Platine fertig machen.
Die Firmware ist aber noch im Entstehen. Da ist Thorsten aktuell grade drann. Aktuell gibt es eine Firmware wo man an die Platine 1-Wire Temperatursensoren anschließen kann.
http://forum.fhem.de/index.php/topic,22952.msg176991.html#msg176991
Gruß
Dirk
Hi !
Zitat von: Dirk am 06 Juli 2014, 17:18:06
@Marc
Die Hardware für RS485 ist fertig, und ja, Ich kann dir so eine Platine fertig machen.
Wunderbar, Bestellung ist per PM raus :) Hat es eigentlich einen Grund, dass Du die
HM485 Module nach wie vor in einem eigenen GIT pflegst und nicht im normalen FHEM
Development Trunk ?
Gruß, Marc
Zitat von: marc2 am 06 Juli 2014, 23:34:30
Hat es eigentlich einen Grund, dass Du die HM485 Module nach wie vor in einem eigenen GIT pflegst und nicht im normalen FHEM
Development Trunk ?
Eigentlich nur, weil die Module immer noch nicht ganz fertig sind.
Naja, das Modul, das ganz fertig ist, und an das nie wieder Hand angelegt werden muss, gibt es ja auch nicht ;)
Gruß, Marc
Also bei mir läuft der Sensor nun mit der leicht abgesenkten Frequenz wie geschnitten Brot seit ein paar Tagen. Alle Nachrichten kommen an...
Mal ne Frage zu Innen-/Außensensor:
Welchen Vorteil hat eigentlich der Innen- ggü. dem Außensensor? Sensormäßig können die ja offensichtlich beide Lufdruck/Temperatur/Helligkeit und Luftfeuchtigkeit. Aber der Außensensor ist ja obendrein wasserdicht...
Zitat von: vbs am 10 Juli 2014, 01:20:51
Also bei mir läuft der Sensor nun mit der leicht abgesenkten Frequenz wie geschnitten Brot seit ein paar Tagen. Alle Nachrichten kommen an...
Das klingt ja gut.
Dann kann ich das am WE ja in die Firmware mit einbauen.
ZitatWelchen Vorteil hat eigentlich der Innen- ggü. dem Außensensor? Sensormäßig können die ja offensichtlich beide Lufdruck/Temperatur/Helligkeit und Luftfeuchtigkeit. Aber der Außensensor ist ja obendrein wasserdicht...
- Vom Design her würde ich mir den Inensensor auch an die Wand hängen.
- Der Außensensor kann nur mit einem externen SHT10 auch Feuchte messen. Im abgedichteten Gehäuse währen Temperatur und Feuchte wohl nicht so interessant. Für Luftdruckmessung muss in das Gehäuse ein kleines Loch gebohrt, oder die Dichtung weggelassen werden.
- Die Batterielaufzeit vom Innensensor ist länger, da AA- anstelle AAA-Zellen
Gruß
Dirk
Zitat von: Dirk am 10 Juli 2014, 09:39:04
- Vom Design her würde ich mir den Inensensor auch an die Wand hängen.
- Der Außensensor kann nur mit einem externen SHT10 auch Feuchte messen. Im abgedichteten Gehäuse währen Temperatur und Feuchte wohl nicht so interessant. Für Luftdruckmessung muss in das Gehäuse ein kleines Loch gebohrt, oder die Dichtung weggelassen werden.
- Die Batterielaufzeit vom Innensensor ist länger, da AA- anstelle AAA-Zellen
Ohne jetzt zu wissen, wie das Innenleben der S300TH-Sensoren aussieht, aber ich hab so meine Zweifel, ob die Elektronik wirklich abgedichtet wurde und doch erfüllen die außen montierten ihre Pflicht nach wie vor so gut, wie es auch die innen montierten tun.
Was ich damit sagen/fragen will: Glaubt ihr nicht, dass man die Innen-Sensoren auch für den Außenbetrieb nutzen kann, sofern gewährleistet ist, dass kein direkter (Spritz-)Wasserkontakt vorhanden ist? Zumindest im deutschen Raum, wo die Luftfeuchtigkeit für gewöhnlich nicht so hoch ist, müsste das doch möglich sein, oder? :-)
Die S300TH-Modelle sind auch nicht dicht.
Daher kann man den Innensensor auch Außen z.B. unter einen Dach montieren. Er sollte halt spritzwassergeschützt angebracht werden.
Den Außensensor hatte ich eher zum Messen der Helligkeit gebaut. Meiner hängt am KS300 Und da darf es auch schon mal drauf regnen.
Ich habe bei mir den SHT10 mit im Außengehäuse untergebracht. Ich hab in das Gehäuse zwei 10mm-Löcher reingebohrt und die Löcher dann mit atmungsaktivem Nylon (http://www.extremtextil.de/catalog/Nylon-PU-beschichtet-atmungsaktiv-100den-80g-qm::1764.html?XTCsid=9b6595d7929f33c82ea51d6a84fdc802) abgedichtet. Ist damit weiterhin wasserdicht aber luftdurchlässig. Damit lässt sich prima Temperatur und auch Luftfeuchtigkeit messen.
Hab ich getestet indem ich einen Oregon-Indoor-Temperatur/Feuchtesensor für zwei Tage (draußen) danebengelegt habe und dann die Messwerte verglichen habe. Die Kurven von beiden Sensoren sahen dann sehr ähnlich aus.
Ist zugegebenermaßen nicht besonders formschön geworden :) Vielleicht mache ich das irgendwann nochmal ordentlich...
Ich hab übrigens noch recht viel von dem Nylon übrig, da ich einen Quadratmeter gekauft habe und, wie man sieht, nur ungefähr zwei fingernagelgroße Stücke benutzt habe. Wenn da jemand etwas von haben will, dann verschicke ich gerne ein paar Stückchen...
(https://dl.dropboxusercontent.com/u/24641738/sht10/DSC_0052.JPG)
(https://dl.dropboxusercontent.com/u/24641738/sht10/DSC_0053.JPG)
(https://dl.dropboxusercontent.com/u/24641738/sht10/DSC_0051.JPG)
Das ist auch eine interessante Lösung.
Zitat von: vbs am 10 Juli 2014, 12:03:16
Die Kurven von beiden Sensoren sahen dann sehr ähnlich aus.
Wie verhhält sich das bei direkter Sonneneinstrahlung?
Zitat von: Dirk am 10 Juli 2014, 12:11:24
Wie verhhält sich das bei direkter Sonneneinstrahlung?
Habe vorhin versucht, beide Sensor auf die Sonnenseite zu hängen. Leider hat sich der Oregon von da strikt geweigert, Daten zu senden (bzw. der RFXTRX sie zu empfangen). Kann also leider nur mit einer Kurve des THPL in der Sonne dienen (von ca. 13:15 bis 16:00):
(https://dl.dropboxusercontent.com/u/24641738/sht10/sonne.jpg)
Interessant, dass der Luftdruck so nervös auf Sonneneinstrahlung reagiert...
So sieht ein "normaler" Tag auf der Schattenseite aus (war ziemlich regnerisch):
(https://dl.dropboxusercontent.com/u/24641738/sht10/normal.jpg)
EDIT:
Ich seh gerade: die Achsenbeschriftungen sind vertauscht bei dem jeweils ersten Graphen...
Zitat von: Dirk am 26 Juni 2014, 15:22:02
Kannst du mal den Stromverbrauch messen.
Zitatbetateilchen am 26 Juni 2014, 09:36:39
Messen kann ich erst nach meinem Urlaub.
Das Merkwürdige daran ist, dass die Innensensoren sich bisher hier unauffällig verhalten.
Ich werde das am Wochenende mal analysieren.
Hallo Dirk,
ich habe heute gemessen, der Sensor zieht irgendwas über 2mA wenn ich meinem Messgerät glauben kann - auf jeden Fall viel mehr als die hier immer propagierten uA.
Es handelt sich übrigens um einen Aussensensor (im Innenbetrieb)
Ich hab hier mal ein Bild von dem Innensensor gefunden. Wie kann da eigentlich Helligkeit gemessen werden? Durch die schmalen Schlitze an der Seite?
(http://hfma.de/images/FHEM/CC1101-Sensor_fertig.jpg)
Nein, Dirk hat ein Loch in den Deckel gebohrt und einen Lichtleiter eingesetzt...
Viele Grüße
Horst
Zitat von: betateilchen am 10 Juli 2014, 21:28:15
Das Merkwürdige daran ist, dass die Innensensoren sich bisher hier unauffällig verhalten.
ich habe heute gemessen, der Sensor zieht irgendwas über 2mA wenn ich meinem Messgerät glauben kann
Das ist definitiv zu viel.
Im Standby dürfen das nur wenige µA sein. Beim senden sind es kurzzeitig einige mA.
Das sieht nach einem Hardwareproblem aus.
Du bekommst dann eine PM
Zitat von: vbs am 11 Juli 2014, 12:08:03
Wie kann da eigentlich Helligkeit gemessen werden? Durch die schmalen Schlitze an der Seite?
Das ist eine Option. Allerdings ist der Messbereich dann sehr klein.
Alternativ, da der Helligkeitssensor nur optional ist, kommt da ein ca. 5mm großes Loch ins Gehäuse. Darein, über den Helligkeitssensor kommt ein Acrylstab der als Lichtleiter dient.
Das sieht dann so aus wie in diesem Beitrag:
http://forum.fhem.de/index.php/topic,20620.msg152064.html#msg152064
Dort ist aber noch ein 3mm Acrylstab eingebaut. Mit 5mm geht es besser.
Gruß
Dirk
Zitat von: vbs am 10 Juli 2014, 16:34:18
Interessant, dass der Luftdruck so nervös auf Sonneneinstrahlung reagiert...
So starke Schwankungen bei habe ich hier nicht.
Die sehen auch nicht so Temperaturabhängig aus.
Wie Luftdurchlässig ist den dein Nylon?
Kann es sein, dass das Nylon die Luft zwar durchlässt, aber nur schwehr?
Dann würde sich bei höherer Temperatur der Luftdruck im Gehäuse erhöhen.
Geiles Ding ! Danke an Dirk, und allen die mitgewirkt haben.
Ich bekomme seit 2Tagen zuverlässig 22/23 Messwerte pro Stunde.
Bzgl Luftdruck/Sonneneinstrahlung steht im Datenblatt "During operation the sensor is sensitive to light, which can influence the accuracy of the measurement (photo-current of silicon)."
Ich finde in den über 40 Seiten nicht, ob wir ein Attribut für höhe über nn haben ?
z.Zt helfe ich mir mit
attr TestSensor userReadings mslpressure:pressure {sprintf("%.1f",(ReadingsVal("TestSensor","pressure",0) / ((1-235/44330)**5.255))) }
wobei 235 die Höhe über nn ist.
Grüße
Ja klar, das ist so. Das Nylon ist ziemlich dicht. Also bei plötzlichen Schwankungen dauert der Luftaustausch etwas. Hab es halt bei mir nicht direkt in der Sonne hängen und dann siehts ok aus.
Bei Bedarf müssten man mit mehr/größeren Löchern experimentieren.
Hab aber auch kein Material gefunden, das wasserdicht ist, aber noch atmungsaktiver ist...
fütter doch mal google mit "gore tex vent element" da gibt es so einiges.
Zitat von: vbs am 12 Juli 2014, 12:40:22
Ja klar, das ist so. Das Nylon ist ziemlich dicht. Also bei plötzlichen Schwankungen dauert der Luftaustausch etwas. Hab es halt bei mir nicht direkt in der Sonne hängen und dann siehts ok aus.
Bei Bedarf müssten man mit mehr/größeren Löchern experimentieren.
Hab aber auch kein Material gefunden, das wasserdicht ist, aber noch atmungsaktiver ist...
Macht doch unten kleine Löcher ins Gehäuse. Solange die klein genug sind passiert doch nichts. 0,5 mm und die Oberflächenspannung des Wassers reicht, dass nichts rein läuft.
Viele Grüsse
Trilu
Zitat von: juppzupp am 12 Juli 2014, 12:38:43
Bzgl Luftdruck/Sonneneinstrahlung steht im Datenblatt "During operation the sensor is sensitive to light, which can influence the accuracy of the measurement (photo-current of silicon)."
Stimmt, Da war ja noch was.
Ich habe im Außensensor noch Filterfolie drüber.
Daher wirkt sich das bei mir nicht so aus.
ZitatIch finde in den über 40 Seiten nicht, ob wir ein Attribut für höhe über nn haben ?
Die Höhe wird global definiert.
attr global altitude 235[/quote]
Gruß
Dirk
Ich habe mal wieder die Firmware aktualisiert.
Wir sind jetzt bei Version 0.10
Änderungen:
v0.9
- Patch von Thorsten: http://forum.fhem.de/index.php/topic,20620.msg169842.html#msg169842. Dadurch bekommt der Sensor ein besseres verhalten wenn er gepeert ist.
v.010
- Die On-Zeit der LED habe ich halbiert. Dadurch sollte etwas Energie gespart werden was auf die Laufzeit der Batterien positive Auswirkungen haben sollte
- Frequenz auf 868,2895508 MHz geändert. Siehe hier: http://forum.fhem.de/index.php/topic,20620.msg181749.html#msg181749. Auch bei mir kommen damit deutlich mehr Pakete ohne Resend an der Zentrale an
- Retry-Count auf 5 gesetzt. Der Sensor sendet jetzt bis 5 mal, falls ein Paket nicht angekomen ist
Die neuen Versionen sind hier:
https://github.com/kc-GitHub/Wettersensor/blob/master/Tools/Firmware/Flash-Tool-Windows.zip?raw=true
https://github.com/kc-GitHub/Wettersensor/blob/master/Tools/Firmware/Flash-Tool-Linux_RaspberryPi.tgz?raw=true
Diese Punkte stehen noch auf der ToDo-Liste:
- Low-Battery-Schwelle per Register einstellbar machen
- Retry-Count per Register einstellbar machen
- evtl. 1-Wire-Temperatur Sensoren an den Sensor einbinden
Gruß
Dirk
Die neue Version läuft bei mir seit ca. 3 Stunden. Keine Probleme. :)
kann ich bei mir auch nachvollziehen. Wahrscheinlich eine Änderung von Martin wo noch ein kleines Artefakt übrig blieb. Aber das Mode schalten klappt ja.
Wieso sich dein Mode allerdings verstellt, würde mich ja an deiner Stelle doch genauer interessieren...
Zitat von: unimatrix am 16 Juli 2014, 21:01:57
Wieso sich dein Mode allerdings verstellt, würde mich ja an deiner Stelle doch genauer interessieren...
Hm, das kann ich grade nicht zuordnen.
aehm. k.a. was da schief lief. das sollte in einen völlig anderen Thread. Sorry!
Ich würde mich gerne mal um Bewegungsmelder kümmern und wollte mal gerne hören, was zu diesem Thema euer aktueller Stand ist.
Ich hab mal den Thread durchsucht, aber ziemlich wenig gefunden zum Thema. Hat schon jemand erfolgreich einen Bewegungsmelder in Hard- und/oder Software angebunden? Oder gibt es zumindest schon konkrete Ideen, welche Modelle in Frage kämen?
Moin zusammen,
ich verfolge diesen Thread nun schon seit einiger Zeit und muss den Sensor in nächster Zeit wohl auch mal austesten.
Mir kam da aber auch noch ein anderer Anwendungsfall in den Sinn. Und zwar zur Aquarienüberwachung.
Wäre es denn wohl ohne großen Aufwand möglich, Sensoren für PH-Wert, Leitwert, Füllstand (Kapazitiv?), etc. in der Firmware zu implementieren?
Hallo,
ich habe auch schon über einen "Pool" Sensor / Aktor nachgedacht, dazu würde ich einen PH und ORP Sensor neben der Temperaturmessung brauchen und damit die Umwälzpumpe (je nach Wassertemperatur) und einige Dosierpumpen Steuern.
Sensoren habe ich diese hier gefunden:
http://www.exp-tech.de/index.php?manu=m74_Atlas-Scientific.html
Leider sind die Sensoren nicht so günstig und ich noch Arduino Neuling...
LG
Franz
Ich habe grade kein Datenblatt zu dem Sensor gefunden.
Wie übermittelt der Sensor seine Daten? 1-Wire, I2C, UART?
seriell 8)
https://www.atlas-scientific.com/_files/_datasheets/_circuit/pH_Circuit_5.0.pdf
Das ist doch nur die Ansteuerplatine. Da muss noch der Sensor dran.
Den kann man doch bestimmt auch direkt auslesen. Sofern dessen Protokoll bekannt ist.
Ansonsten, Sensoren mit serieller Schnittstelle sind eigentlich mit ein paar Codezeilen implementiert.
Aber der "Teufel" liegt bekanntlich im Detail.
Ich fürchte, man wird um die Messplatine nicht rumkommen ;)
https://www.atlas-scientific.com/_files/_datasheets/_sensor/pH-sensor-datasheet.pdf
So wie es aussieht hast du recht.
Die Auswertelektronik ist nicht trivial und müsste auch abgeglichen werden.
Auf alle Fälle ist der PH-Sensor gar nicht mal so günstig.
Das Auslesen über die Serielle Schnittstelle geht dann allerdings um so einfacher.
Zitat von: Dirk am 18 Juli 2014, 18:23:04
Auf alle Fälle ist der PH-Sensor gar nicht mal so günstig.
- und hat nur eine Lebensdauer von 3 Jahren
- und muss nach jedem Trockenfallen neu kalibriert werden
- und so weiter...
ich glaub, mit dem Teil hätte ich keinen Spaß :P
Ich habe den Wiki-Beitrag etwas überarbeitet:
http://www.fhemwiki.de/wiki/Universalsensor
In der Hoffnung ich habe alles wichtige erfasst um das zu einer Zusammenfassung von diesem Tread zu machen.
Ansonsten, jeder ist gerne eingeladen den Artikel zu aktualisieren :)
Viele Grüße
Dirk
Zitat von: Dirk am 18 Juli 2014, 21:55:57
Ich habe den Wiki-Beitrag etwas überarbeitet:
http://www.fhemwiki.de/wiki/Universalsensor
In der Hoffnung ich habe alles wichtige erfasst um das zu einer Zusammenfassung von diesem Tread zu machen.
Ansonsten, jeder ist gerne eingeladen den Artikel zu aktualisieren :)
Viele Grüße
Dirk
Cool vielen Dank Dirk! Jetzt stellt sich mir nur noch die Frage der Bezugsquelle? *ganzliebguck* ;-)
Nach einige erfolgreichen Tests kann ich glaube die Prototypenphase als erfolgreich beendet erklären.
Ich habe heute auch die Auftragsbestätigung für die Fertigung der Platinen incl. Pastenschablone für eine "kleine Serie" bekommen. Ich werde nun noch einige Bauteile ordern.
Ich denke gegen Mitte / Ende August kann dann die Auslieferung der Sensoren an alle bisherigen Interessenten beginnen.
Ich würde dann jeden auf meiner Liste per PM kontaktieren und dann noch mal die genaue Bestückungsvariante und die gewünschten Stückzahlen abfragen.
Viele Grüße
Dirk
Cool! :)
Meiner läuft mit FW 0.9 sehr stabil, die beiden Ausreisser sind selbst verschuldet, da ich fhem zum hängen gebracht hatte.
Messages pro Stunde :
Zitat von: Dirk am 19 Juli 2014, 21:27:43
Ich denke gegen Mitte / Ende August kann dann die Auslieferung der Sensoren an alle bisherigen Interessenten beginnen.
Ich würde dann jeden auf meiner Liste per PM kontaktieren und dann noch mal die genaue Bestückungsvariante und die gewünschten Stückzahlen abfragen.
Viele Grüße
Dirk
ich würde mich ebenfalls einklinken und Sensoren ordern, wenn ich es nicht schon getan habe... weiß ich grad nicht mehr... lese aber ständig mit.
Hiermit möchte ich dann ebenfalls auf die Liste... Danke
Ich würde gerne auch auf die Liste. Danke!
Schließe mich auch an!
unimatrix hab ich mit aufgenommen.
P.A.Trick stand schon drauf :)
Update:
moonsorrox hab ich auch auf die Liste gesetzt.
Habe auch Interesse an einem Innenraumsensor.
Gruß
Luigi
Hallo,
für mich einen Außensensor (Funk) Temperatur, Feuchtigkeit, Helligkeit
Gruß Christoph
Ich hätte gerne auch nen Außensensor mit allem drum und dran. (Funk)
Hat schon jemand efolgreich den Innensensor mit einem Bewegungsmelder ausgestattet? Das ist für mich der Haupt-Beweggrund so einen (oder mehrere) zu kaufen.
Danke,
Sebastian
Zitat von: Dirk am 23 Juli 2014, 09:35:45
unimatrix hab ich mit aufgenommen.
P.A.Trick stand schon drauf :)
Update:
moonsorrox hab ich auch auf die Liste gesetzt.
Scheiß Demenz ;-)
Hallo Dirk,
ich hätte auch Interesse an 1x Aussensensor und 1x Innensensor (Funk).
Danke & Gruss
Tobias
Hallo Dirk,
der Innensensor läuft mit Version 0.9 bisher stabil, hätte gerne auch noch einen Außensensor mit allem drum und dran. (Funk)
Danke
Klaus
PS: Danke auch für das überarbeitete Wiki
tpm88 und kvo1: ihr steht mit auf der Liste und bekommt in den nächsten Tagen Post.
Gruß
Dirk
Hallo Dirk,
bin heute erst auf Deinen tollen Aussensensor gestossen. Ich Interessiere mich insbesondere für die Helligkeitsmessung aussen.
Nimmst Du noch Bestellungen entgegen? Ich würde einen Aussensensor nehmen!
gruß
Adam
würde es sich nicht anbieten für die serien nummer einen i2c mac chip zu verwenden? oder einen 1-wire ds1820.
bei der i2c version ist meist gleich noch ein kleines eeprom dabei.
gruss
andre
Hallo Dirk,
ich bin interessiert an
2 x Aussensensor (Funk) mit Helligkeitssensor
Kannst Du mich noch auf die Liste der Interessenten setzen?
Tolle Arbeit von Euch!
Gruß Marcus
Zitat von: justme1968 am 25 Juli 2014, 08:47:46
würde es sich nicht anbieten für die serien nummer einen i2c mac chip zu verwenden? oder einen 1-wire ds1820.
Ich finde Die Idee nicht so gut.
Die Device-Adressen bestehen nur aus 3 Bytes (Bei HM-Wired 4). Die Wahrscheinlichkeit dass die Adresse eines bestehenden oder neuen Devices die gleiche Adresse hat ist zwar sehr gering, aber nicht unwahrscheinlich. Daher muss es bei einem Konflikt dann die Möglichkeit geben die Adresse des Homebrew-Devices zu ändern.
Gruß
Dirk
der vordere teil der mac adresse ist fest und hersteller spezifisch. der hintere teil ist eindeutig so lange der ic vom gleichen hersteller kommt. du hast also eigentlich genau deine 3 oder 4 eindeutigen bytes.
gruss
andre
Ja, aber die Adresse währ dann fest und nicht änderbar.
Bei einer Kollision mit einem nicht-Homebrew-Device, kann man dann eines der Geräte nicht verwenden.
Gruß
Dirk
P.s. etwas mehr kostet die Lösung auch. Und die Seriennummer muss man dann auch noch aus der Adresse ableiten.
Das "kostet" zusätzlich etwas Code.
Da ist das Statische speichern im Flash meiner Meinung nach einfacher.
was die kollision mit 'echten' hm devices angeht hast du recht.
ich mag die idee trozdem und vor allem den extra eeprom der auch noch dabei wäre :)
gruss
andre
Hallo Adam und marcus42,
ich habe euch auf die Liste gesetzt.
Gruß
Dirk
Hallo,
Ich habe gestern ein paar Stunden den ganzen Thread durchgelesen und muss jetzt erst mal eins loswerden:
Respekt an alle die bei diesem Projekt mitarbeiten, das ist echt ne super Leistung !!!
Vor allem könnte sich EQ3 mal etwas Kreativität abschaun ....
Ich hätte aber auch noch ne Frage :
Für mich wäre eine Ansteuerung eines Rauchmelders interessant. Im Netz habe ich folgendes bei Ebay u.a. gefunden:
http://www.ebay.de/itm/MQ-7-CO-Carbon-Monoxide-Detection-Sensor-Module-fur-Arduino-Gas-Sensor-Module-/191092025322?pt=DE_Haus_Garten_Heimwerker_Sicherheitstechnik&hash=item2c7df8e7ea (http://www.ebay.de/itm/MQ-7-CO-Carbon-Monoxide-Detection-Sensor-Module-fur-Arduino-Gas-Sensor-Module-/191092025322?pt=DE_Haus_Garten_Heimwerker_Sicherheitstechnik&hash=item2c7df8e7ea)
Ich bin da nicht soooo bewandert, aber der sollte sich doch an den Sensor anschliessen lassen, oder ?
Hat jemand Erfahrung mit solchen Modulen ?
Ok Ok bestimmt kommen jetzt auch Antworten wegen der Leistung die das Modul zieht aber öfter Batterien wechseln wäre für mich ok.
Gruß
Pascal
Hallo Dirk,
bin noch dabei, alles mal durchzlesen, aber "Hut ab" tolle Entwicklungsarbeit. Der Sensor spiegelt eigentlich die "geekigen" Möglichkeiten von FHEM auf Hardware- / Sensorebene wieder.
Falls möglich, bitte setze mich auch noch auf die Liste für einen Innensensor!
Wie gesagt - ich lese mich noch ein. Könnte man deine Arbeiten auch dazu nutzen, allgemein über den CC1101 Arduinos mit deiner Firmware mittels Homematic einzubinden?
Vielen Dank & Gruß,
Markus
Hallo,
Ich will doch noch mal das Thema OTA-Bootloader ansprechen und ggf. etwas Hoffnung machen.
Das Datenblatt vom Atmega328p und die Angabe zur Bootloadergröße hat mich nämlich etwas verwirrt.
Der Atmega328p hat nämlich 4090 Bytes Bootloader-Speicher. Nicht wie ich fälschlicherweise angenommen hatte nur 2048 Bytes. Im Datenblatt ist nämlich von Word die Rede.
Also 2048 * 2 Bytes.
Ich habe grade mal den Asksin OTA Bootloader kompiliert. Das bin-File 4010 Bytes groß. Also sollte das auch in den 4k-Bootloader des 328p passen.
Bekommen wir den Bootloader also doch noch auf den aktuellen Sensor?
Gruß
Dirk
Zitat von: Dirk am 03 August 2014, 17:18:29
Ich will doch noch mal das Thema OTA-Bootloader ansprechen und ggf. etwas Hoffnung machen.
[...]
Bekommen wir den Bootloader also doch noch auf den aktuellen Sensor?
Na das wär natürlich was, wenn sich das gerade noch so ausgehen würde. :-)
Reinpassen sollte es. Ich habe schonmal vor einiger Zeit versucht den Bootloader auf einen 328p zu portieren (allerdings auf einem Panstamp) weil ich gerne meine FB-Heizungssteurung an die man nur sehr schlecht dran kommt OTA-updatefähig haben wollte. Ich habe allerdings die Versuche dann zunächst abgebrochen weil ich auch das Ding gerne einbauen wollte um damit rumspielen zu können.
Das Ding war schon grundsätzlich flashbar, Tests mit LED-Blinken usw gingen auch, aber das Ding ist bei dem INIT vom CC1101 immer abgbrochen. Meine Vermutung war dass dies an den Arduino Portnummern lag. Der Bootloader ist ja kein Arduino Sketch, jedoch wird über die arduino.h einiges deklariert und definiert so dass es so "Halb-Arduino" ist.
Problem war dann aber auch gewesen, dass ich es mit der dem Bootloader beiligenden UART-Bibliothek noch nicht einmal geschafft habe, eine serielle Debug-Ausgabe zu bekommen. Hier habe ich bisher einfach aufgehört weiter nachzuforschen. Ich bin sicher dass es letztlich gehen würde.
Baut man die Debug-Ausgaben ganz aus bekommt man den Bootloader auch noch kleiner ...was beim 328 eher noch das Problem sein könnte, dass der ja eh schon mit 32KByte FLash "klein ist" und man vll. die 4 KByte nicht hergeben mag.
Also ich nutze den Chip45 Bootloader, um nen Atmega per Bluetooth zu flashen. Vielleicht wäre das ja auch was. Funktioniert jedenfalls 1A. Es gibt auch ne schicke GUI dazu, die das Flashen sehr einfach macht.
Edit: Sorry, vergesst was ich geschrieben habe. Da bräuchte der Sensor ja auch Bluetooth. Hatte wohl zu viel Sonne ;-)
Hallo Marcus,
sorry ich hatte deinen Beitrag übersehen.
Zitat von: m2th3o am 29 Juli 2014, 20:47:28
Falls möglich, bitte setze mich auch noch auf die Liste für einen Innensensor!
Bis drauf.
ZitatKönnte man deine Arbeiten auch dazu nutzen, allgemein über den CC1101 Arduinos mit deiner Firmware mittels Homematic einzubinden?
Ja. Die Firmware bassiert auf der AskSin-Lib von Trilu.
Mit der Lib kann man dann auch noch mehr machen.
Gruß
Dirk
Zitat von: unimatrix am 03 August 2014, 17:41:29
Problem war dann aber auch gewesen, dass ich es mit der dem Bootloader beiligenden UART-Bibliothek noch nicht einmal geschafft habe, eine serielle Debug-Ausgabe zu bekommen. Hier habe ich bisher einfach aufgehört weiter nachzuforschen. Ich bin sicher dass es letztlich gehen würde.
Ich schau mir das bestimmt die Tage mal an. Das hat aber keine Priorität.
Vielleicht findet sich ja auch jemand der hier unterstützen möchte.
ZitatBaut man die Debug-Ausgaben ganz aus bekommt man den Bootloader auch noch kleiner ...was beim 328 eher noch das Problem sein könnte, dass der ja eh schon mit 32KByte FLash "klein ist" und man vll. die 4 KByte nicht hergeben mag.
Ich vermute auf <= 2kb werden wir das dadurch trotzdem nicht bekommen?
Der aktuelle Code vom Sensor ist 26.992 Bytes groß. Das sollte also auch in 28k rein passen.
Gruß
Dirk
helfe gerne mit ich hatte es nur wie gesagt zunächst liegenlassen.
Anbei die von mir angepasste Arduino.h (der 328p hat keinen PortA, ggf. liegt hier in meiner Anpassung schon der Fehler, die Portnummern machen mich wahnsinnig...), sowie das angepasste Makefile und das angepasste cc.h mit den neuen Portnummer. Alles andere hätte in der perfekten Welt eigentlich gleich bleiben können...
Ich habe es bisher NUR auf einem Panstamp getestet, da ich für meinen Arduino noch keine Funkmodule habe.
Die Anpasungen hatte ich auch testweise schon gemacht. Sonst hat er für den Atmega328p nicht kompiliert. Mein Makefile ist aber etwas anders. Die Startadresse für den Bootloader bei 4k Bootsize sollte doch bei 0x7000 liegen?
Ich habe testweise auch mal alles Debugausgaben rauskommentiert. Da kommt man immer noch auf 3354 Bytes. Somit brauchen wir die 4k Bootloader.
Gruß
Dirk
7000 ist natürlich richtig. "Leider" gerade im Büro...komisch...das erklärt aber nicht warum bei mir nix ging. Hätte ja auch mit 6000 laufen müssen (also überhaupt laufen, UART ausgabe usw., auch wenn natürlich dann kein flashen ginge)
Hallo zusammen,
mist, es hat mich einfach nicht losgelassen.
Aber ich kann den Sensor nun auch OTA flashen. ;D
Ich habe das Gitrepo von jabdoa2 mal auf die schnelle geforkt und hier die passenden Änderungen vorgenommen:
https://github.com/kc-GitHub/Asksin_OTA_Bootloader
Jetzt müsste man das Ganze nur noch etwas universeller bauen, dass man für verschiedene Setups nicht verschiedene Quellen braucht.
Was habe ich alles gemacht?
- Das Makefile an den Atmega328p angepasst. Incl. ein paar kleiner Erweiterungen wie Anzeige der Codegröße nach dem Kompilieren. Das kann aber noch schöner gemacht werden
- Die Portdefinitionen für den Atmega328p angepasst, und die Pins an dem die LED und das CC1101-Modul hängen
- Die Seriennummer im Bootloader angepaßt: (SEN0THPL02). Da die Seriennummer hier eh im Bootloader steht, würde ich dafür die Firmware des Sensors auch nochmal anpassen, dass dieses dann die Seriennummer vom Bootloader verwendet. Vielleicht werde ich noch ein Flash-Tool bauen. Damit man den Bootloader flashen kann ohne den neu zu kompilieren und trotzdem eine eigene Seriennummer verwenden kann.
- Damit der Code in den 4k Bootloaderbereich des 328p passt, habe ich die Debuginfos etwas "verstümmelt". Man kann aber noch lesen was gemeint ist.
- Im covert.php habe ich für den Atmega328p die spm_pagesize auf 128 geändert. Hier muss man auch nochmal ran, um das Script universeller zu bauen.
Was mich etwas zur Verzweiflung gebracht hat: Wieso ist die hmid des Bootloaders fest auf AB:CD:EF eingestellt? Das hatte ich nämlich geändert und dann gemerkt das das so sein muss.
Gruß
Dirk
also wenn ihr mal soweit seid wäre ich gern bereit einen eurer Wunderkästen käuflich zu erwerben :)
Hi Dirk,
super dass du das durchgezogen hast. Ich gebe zu ich hatte beim letzten mal nicht den notwendigen Antrieb. Wenn man den CRC Check nutzen will muss man noch die CODE_LEN und den Parameter im sreg_cat anpassen.
Noch ein Vorschlag zur Diskussion: Der Bootloader kann ja auch in den BL-Code Bereich schreiben. Da er nicht ganz 4K ausfüllt, ist im Flash an der oberen Grenze Platz für die Seriennummer. Der Bootloader könnte bei seinem ersten Start auf eine Magic Number prüfen (crc) und wenn diese nicht stimmt generiert er zufällig eine Seriennummer, packt diese ans obere Ende des Flash-Speichers, generiert die CRC und fertig. Die Seriennummer wird beim Einschalten ja über BidCos gesendet, so dass man sie dann leicht herausfindet. Diese könnte außerdem auch von der Applikation genutzt werden. So könnte man sich viele Devices mit dem identischen Hex-File flashen und hätte trotzdem unterschiedliche Seriennummern. (ggf. auch HMID mit abdecken)
das eq3 flashtool erwartet aber bereits zum starten die sn.
ja, das ist klar. Man müsste sich die SN zunächst aus dem FHEM Log raussuchen, mit richtigem Log Level sieht man sie anhand der Message.
Zitat von: micomat am 04 August 2014, 19:44:06
also wenn ihr mal soweit seid wäre ich gern bereit einen eurer Wunderkästen käuflich zu erwerben :)
Ich setze dich mit auf die Liste der Sammelbestellung. Da gibt es die nächsten Tage eine Info zum weiteren Ablauf.
Zitat von: unimatrix am 04 August 2014, 20:15:34
Wenn man den CRC Check nutzen will muss man noch die CODE_LEN und den Parameter im sreg_cat anpassen.
Das hatte ich mir schon gedacht. Das schalte ich bestimmt noch mit ein.
ZitatNoch ein Vorschlag zur Diskussion: Der Bootloader kann ja auch in den BL-Code Bereich schreiben. Da er nicht ganz 4K ausfüllt, ist im Flash an der oberen Grenze Platz für die Seriennummer.
Ich würde die gerne die Adresse / Seriennummer beim initialen Flashen mit übergeben.
Auch um Code für die Zufallsbestimmung, Magic Number Prüfung usw. zu sparen.
Mit den 4k vom 328 sind wir schon ziemlich knapp.
Wenn man den Quellcode mit Linux übersetzt kann man übrigens auch noch ein paar Bytes gegenüber WinAVR sparen.
Gruß
Dirk
Zitatja, das ist klar. Man müsste sich die SN zunächst aus dem FHEM Log raussuchen, mit richtigem Log Level sieht man sie anhand der Message.
wenn aber nur der bootloader drauf ist, gibt es ja noch kein log/funk.
Zitat von: Dirk am 04 August 2014, 18:34:13
Aber ich kann den Sensor nun auch OTA flashen. ;D
Hallo Dirk,
sprich der Atmega hat nicht nur eine serielle Schnittstelle, sondern die serielle Schnittstelle zum Flashen läuft über Funk (und muss dann von fhem entsprechend über CUL o.ä. bedient werden)?
Wenn das läuft, ist das ziemlich cool. Hut ab!
Gruß PeMue
Zitat von: frank am 04 August 2014, 20:58:40
wenn aber nur der bootloader drauf ist, gibt es ja noch kein log/funk.
Wenns kein Funk gibt, wie kann man dann über Funk flashen? ;) ... nein aber im ernst. Das erste was der Bootloader macht, ist, folgende Message zu senden
14 00 00 10 23 25 B7 00 00 00 00 SERIAL_NUMBER
Diese kann man mitloggen und dann kennt man die zufällig generierte Nummer. Es wäre nur eine Möglichkeit. Man könnte dieses Verhalten einbauen und trotzdem die Möglichkeit belassen, die Seriennummer manuell festzulegen (durch bearbeiten des .bin-Files). "Vergisst" man die Vergabe der SN, dann hat der BL zumindest nicht die Standard-Seriennummer (die sich unter umständen mit einem anderen Device "beisst" sondern eine zufällig generierte.
Zitat von: PeMue am 04 August 2014, 21:40:18
sprich der Atmega hat nicht nur eine serielle Schnittstelle, sondern die serielle Schnittstelle zum Flashen läuft über Funk (und muss dann von fhem entsprechend über CUL o.ä. bedient werden)?
Ja.
Zitat von: PeMue am 04 August 2014, 21:40:18
Wenn das läuft, ist das ziemlich cool. Hut ab!
Der Dank gilt den Autoren des Bootloaders. Ich habe diesen nur an den Atmega328p angepasst.
@unimatrix
Wieso verwendet der Bootloader und flash-ota eine Statische Adresse (ABCDEF) um das Device im Bootloader-Mode anzusprechen?
Normalerweise hat jedes Device eine unique Adresse?
Gruß
Dirk
ZitatDas erste was der Bootloader macht, ist, folgende Message zu senden
danke, alles klar. war mir nicht aufgefallen. ich kannte es sonst nur beim setzen des pairingmodus, wenn die fw schon läuft.
Wieso die HM ID so lautet, weiß ich nicht, ich nahm immer an, das ist eine Erfindung von eq3. Es wird ja immer nur ein Device zu einem Zeitpunkt geflasht insofern sollte das unproblematisch und auch letztlich unwichtig sein...(natürlich darf genau diese HMID für kein richtiges Gerät genommen werden)
Zitat von: blackstonesb am 29 Juli 2014, 09:43:40
Ich hätte aber auch noch ne Frage :
Für mich wäre eine Ansteuerung eines Rauchmelders interessant. Im Netz habe ich folgendes bei Ebay u.a. gefunden:
http://www.ebay.de/itm/MQ-7-CO-Carbon-Monoxide-Detection-Sensor-Module-fur-Arduino-Gas-Sensor-Module-/191092025322?pt=DE_Haus_Garten_Heimwerker_Sicherheitstechnik&hash=item2c7df8e7ea (http://www.ebay.de/itm/MQ-7-CO-Carbon-Monoxide-Detection-Sensor-Module-fur-Arduino-Gas-Sensor-Module-/191092025322?pt=DE_Haus_Garten_Heimwerker_Sicherheitstechnik&hash=item2c7df8e7ea)
Ich bin da nicht soooo bewandert, aber der sollte sich doch an den Sensor anschliessen lassen, oder ?
Hi Pascal,
den kann man sicher zusätzlich als Rauchsensor einsetzen. Aber vermutlich entsteht CO bei einem Brand erst relativ spät in ausreichender Menge. Daher würde ich den Sensor nicht alleine als einsetzen um einen Brand zu detektieren.
Grundsätzlich lassen sich viele Sensoren an die Platine anschließen. Die Sensoren sollten bei Batteriebetrieb möglichst mit 3,3 V Spannung auskommen. Bei Netzteilversorgung kann man die Sensoren auch mit 5 V betreiben, dann braucht man zum AVR hin aber einen Pegelwandler auf 3,3 V um die Sensoren an den AVR zu bekommen. Da reicht meist auch ein einfacher Spannungsteiler.
Man muss für die Sensoren halt noch den entsprechenden Code bauen.
Gruß
Dirk
Hi Dirk,
Danke für die schnelle Antwort.
Den Sensor gibts auch als Rauchmelder mit 3v. Hab hier noch ein paar Interessante gefunden:
http://www.allnet.de/de/allnet-brand/produkte/diy-doityourself/arduino/arduino00/
Aber was den Code angeht, geht das leider über meine Fähigkeiten.
Gruß
Pascal
Hallo,
habe mir gerade den gesamten Thread angetan und bin begeistert.
Hätte gerne zunächst auch 1 Innensensor, wenn noch möglich.
Andreas
Hi Andreas,
ich habe dich mit auf die Liste gesetzt.
Gruß
Dirk
Hallo,
wie lange wird denn gesammelt bzw. wann werden die Teile geordert ?
Steht der Preis schon fest ?
Gruß Christoph
Hi Christoph,
Zitat von: Bennemannc am 08 August 2014, 06:58:53
wie lange wird denn gesammelt bzw. wann werden die Teile geordert ?
Steht der Preis schon fest ?
Ich habe vor dem Urlaub die Platinen bestellt. Gestern kam die Versandbestätigung.
Je nach Bestückungsvariante und Ausstattung wird der Preis um die 20 - 40 EUR liegen.
Die Bestellung der restlichen Bauteile mach ich die Tage fertig, dann steht der Preis fest.
Gruß
Dirk
Kannst Du mich auch auf die Liste setzen (1 Innensensor, Gehäuse habe ich selbst, also nur den "Kram" für rein)? Danke
ZitatKannst Du mich auch auf die Liste setzen
Bist drauf.
Hallo Dirk,
ich hätte gern zwei Außensensoren, vielen Dank.
Volker
Volker, du bist auch auf der Liste.
Hallo zusammen,
ich habe vorhin an alle Interessenten der Sammelbestellung eine Nachricht mit weiteren Details gesenden.
Falls ich jemanden vergessen habe, bitte eine kurze PM an mich.
Viele Grüße
Dirk
Hallo Dirk,
wäre es prinzípiell auch möglich, mit diesem Sensor Impulse zu lesen und zu übertragen?
Ich denke dabei sowol an S0, D0 bzw. auch die Impulse von meinem EM 1000 WZ (http://www.elv.de/controller.aspx?cid=683&detail=10&detail2=285972).
Ich weiß, dass man da den Sketch umprogrammieren muss, aber falls das machbar wäre, könnte man die Dinge, die im Zählerkasten so ablaufen, übertragen und monitoren.
Vermutlich fehlt aber da auch noch das fhem Modul :-[
Bei mir sind mir langsam zu viele Empfänger im Haus und irgendwie wird Homematic immer interessanter für mich.
Wenn es noch geht, würde ich gerne zum Probieren einen Innensensor kaufen.
Danke + Gruß
Peter
Hi Peter,
Zitatwäre es prinzípiell auch möglich, mit diesem Sensor Impulse zu lesen und zu übertragen?
Ja, klar. genügend Pins sind noch frei.
Das war auch noch die Idee hinter dem Sensor. Dass man mit der Hardware ggf. auch eigene Entwicklungen umsetzen kann.
Am besten geht das über eine kleine Erweiterungsplatine welche man oben auf die freien Pins stecken kann.
ZitatVermutlich fehlt aber da auch noch das fhem Modul :-[
Das Modul ist sogar schon da. Das muss nur etwas erweitert werden.Und CUL_HM ist dafür schon ausgelegt. Als Beispiel kannst du dir HMConfig_SenTHPL.pm ansehen.
Du musst also nur einen eigenen Devicetype definieren und in einer eigenen HMConfig_whatever.pm die Nachrichten auswerten.
ZitatWenn es noch geht, würde ich gerne zum Probieren einen Innensensor kaufen.
Mit Batteriebetrieb oder für externe Spannungsversorgung?
Gruß
Dirk
Hallo Dirk,
Danke für die schnelle Antwort. Ich verkable gerade meine Telefone neu, da die neue Fritz Box nur noch zwei Telefone beidenen kann *grr* :-[
ZitatMit Batteriebetrieb oder für externe Spannungsversorgung?
Mit Batteriebetrieb bitte. Mit einer Buchse (und dann ohne Akku) kann der Sensor ja vermutlich auch mit externer Spannungsversorgung betrieben werden, oder?
Danke + Gruß
Peter
Hallo Dirk,
wäre evt. noch Platz auf der Liste? Ich hätte Interesse für einen Innen- und einen Außensensor.
Gruß
Peter
Hallo,
ich hätte gern einen Außensensor (Funk) Temperatur, Feuchtigkeit, Luftdruck, Helligkeit und einen Innensensor (Funk) Temperatur, Feuchtigkeit, Helligkeit.
Ist noch Platz auf der Liste ?
Hallo Dirk,
würde mich auch gerne für 1-2 Aussensensoren anmelden :)
lg, Ici
Hallöchen,
einen Außensensor hätte ich auch gern, wenn noch was zu haben ist.
Gruß
Ingo
Gesendet von meinem GT-I9506 mit Tapatalk
@ PeMue, PumpkinEater, cactus-online, Icinger und automatisierer.
Ich habe euch weitere Infos per PM gesendet.
Gruß
Dirk
Hi dirk. Welche induktivitätsspule hast du für den max1724 verwendet und wo hast du sie gekauft?
Gibt's von dem Projekt auch einen Schaltplan?
Danke schonmal!
http://www.fhemwiki.de/wiki/Universalsensor-THPL
Zitat von: Dirk am 14 Juli 2014, 09:41:26
v.010
- Die On-Zeit der LED habe ich halbiert. Dadurch sollte etwas Energie gespart werden was auf die Laufzeit der Batterien positive Auswirkungen haben sollte
- Frequenz auf 868,2895508 MHz geändert. Siehe hier: http://forum.fhem.de/index.php/topic,20620.msg181749.html#msg181749. Auch bei mir kommen damit deutlich mehr Pakete ohne Resend an der Zentrale an
- Retry-Count auf 5 gesetzt. Der Sensor sendet jetzt bis 5 mal, falls ein Paket nicht angekomen ist
Hi,
Ich bin jetzt auch auf die 0.10 gegangen, habe aber immer noch ein paar "Ausfälle" am Tag. So ungefähr 10mal fehlt dem gepeerten RT ein Wert und ein bis zweimal am Tag fehlen ihm ungefähr 10-15 Minuten. Ein einzelner fehlender Wert ist kein Problem, aber nach so ungefähr 15 Minuten scheint sich der RT dann vorerst nicht mehr auf den Sensor zu verlassen und macht sein eigenes Ding (bis das Peering wieder klappt). Das Blöde dabei ist, dass meine Sollwerte auf den externen Sensor eingestellt sind. Das führt dazu, dass der RT manchmal die Heizung anwirft, obwohl es noch warm genug ist.
Gruß,
Thorsten
Zitat von: Tobias am 15 August 2014, 15:23:47
Hi dirk. Welche induktivitätsspule hast du für den max1724 verwendet und wo hast du sie gekauft?
Wie im Datenblatt empfohlen: http://de.rs-online.com/web/p/products/7255165/
Zitat von: Thorsten Pferdekaemper am 18 August 2014, 10:36:49
Ich bin jetzt auch auf die 0.10 gegangen, habe aber immer noch ein paar "Ausfälle" am Tag. So ungefähr 10mal fehlt dem gepeerten RT ein Wert und ein bis zweimal am Tag fehlen ihm ungefähr 10-15 Minuten.
Ggf. müsste man hier noch mal nach dem Peering schauen.
Hast du den Sensor parallel noch an FHEM gepaired? kannst du da schauen ob hier auch Telegramme verloren gehen.
Ggf. liegt das noch immer am timing. Und der RT und der Sensor verliefen ihre Synchronisierung?
Benutzt noch jemand die Sensoren als Perringpartner an einem RT?
Gruß
Dirk
Zitat von: Dirk am 18 August 2014, 11:04:55
Benutzt noch jemand die Sensoren als Perringpartner an einem RT?
Noch nicht... aber hoffentlich bald! :-)
ich bin mir mittlerer weile nicht mehr ganz sicher wie gut die funkmodule sind und wie hoch die serienstreuung bzgl der frequenztreue ist. vielleicht sollten wir den rssi wert mal auswerten. der liegt ja bei jeder transaktion vor, er gehört nur mal ausgelesen und an die serielle konsole ausgegeben.
ich werde das mal in der neuen lib einbauen...
vielleicht braucht es dann eine automatische frequenzanpassung :-)
Hallo Dirk,
wenn es noch möglich ist hätte ich gerne einen Aussensesor und zwei Innensensoren, Funkversionen
Gurß
Karl
Zitat von: Dirk am 18 August 2014, 11:04:55Hast du den Sensor parallel noch an FHEM gepaired? kannst du da schauen ob hier auch Telegramme verloren gehen.
Ggf. liegt das noch immer am timing. Und der RT und der Sensor verliefen ihre Synchronisierung?
Hi Dirk,
ja, der Sensor ist auch in FHEM gepaired. Um diese Fehler zu finden habe ich mir einen Plot gemacht, der die Temperatur des Sensors und die des RT übereinander legt. (Siehe die obere Kurve im Anhang.) Wenn die Synchronisierung passt, dann liegen diese beiden Kurven fast exakt aufeinander.
Ansonsten gibt's Abweichungen. Das ergibt dann sowas wie kurz vor 08:00 und die fünf kleinen "Spikes".
Natürlich kann das Ereignis kurz vor 8 auch daran liegen, dass der RT kurz mal die Verbindung zum HMLAN verliert, aber ich hatte auch schon andere Kurven, bei denen sich die grüne Linie unabhängig von der rosa Linie geändert hat.
Ich habe aber noch nie gesehen, dass die rosa Kurve "flat" wird. Soweit ich sehe, funktioniert das Senden zu FHEM immer.
Gruß,
Thorsten
Moin zusammen,
als blutiger FHEM-Anfänger bin ich auf der Suche nach Sensoren für Temperatur und Feuchtigkeit über diesen Thread gestolpert. Und hoffe jetzt einfach mal, dass ich nicht just zu spät bin, um noch 4 Innensensoren bekommen zu können.
Viele Grüße
Fabian
Wenn genauere Preise für die Aussen- und Innentemperatursensoren vorliegen, würde ich mich über eine PN freuen 8)
@schka17, redfeathers, Hauswart
Ich habe euch eine PM geschickt.
Hallo Dirk,
ich habe noch ein paar Fragen zur Hardware:
Zitat von: Dirk am 18 August 2014, 15:17:54
Sensoren mit Batterie ohne bzw. mit MAX1724
Sensoren mit externer Spannungsversorgung
Wie bestückst Du die Hardware für die Sensoren mit externer Spannungsversorgung? Nimmst Du da den RS485 Teil? Welche Spannung braucht man dann?
Könnte man alternativ nicht auch 5 V an den Batteriepins einspeisen (wenn man einen MAX1724 bestückt hat)?
Aus elektrotechnischer Sicht würde ich den Batteriebetrieb ohne MAX1724 wegen der Akkulaufzeit bzw. Stabilität der Spannungsversorgung nicht wirklich empfehlen.
Zitat von: Dirk am 18 August 2014, 15:17:54
Ich habe es die letzten Tage geschafft für das Board den OTAU-Bootloder zu portieren. Ich werde die Boards mit Funk-Modul daher vermutlich schon mit dem OTAU-Bootloader versenden.
...
Ich kann auf Wunsch dir aber auch den seriellen Bootloader flashen. Dann ist eine Firmwareupdate immer über den USB-Serial-Adapter möglich.
Vermutlich ist die Wahl entweder OTAU Bootloader (und dann Programmieren über fhem) oder serieller Bootloader, korrekt?
Mit ISP (und entsprechend angeschlossenem Programmer bzw. Raspberry Pi und Verkabelung bzw. Skript) müsste es aber möglich sein, den Bootloader einfach auszutauschen.
Allerdings wäre es mAn in der Dokumentation hilfreich, einen Hinweis auf die zu setzenden Fuses zu machen (da tu ich mir immer schwer), und wenn es falsch ist, kann es sein, dass der Prozessor nicht mehr will ...
Viele Grüße
PeMue
Hi,
nochmal zur 0.10er Firmware. Ich habe den Eindruck, dass es damit eher schlechter geworden ist. Im Anhang sieht man, dass das Peering dreimal verloren gegangen ist. Man sieht auch, dass FHEM die Temperaturen sowohl vom RT als auch vom Sensor weiterhin empfangen hat. Nach so ungefähr einer Stunde fängt sich das jedesmal wieder, aber das reicht aus, um das Ventil unnötigerweise öffnen zu lassen.
(Der Sensor sitzt einen Meter höher als das Ventil, außerdem zeigt er sowieso immer etwas mehr an. Ansonsten schlägt halt die Homematic-Logik zu, dass ein ungepeerter RT früher anfängt zu heizen.)
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 19 August 2014, 23:19:35
nochmal zur 0.10er Firmware. Ich habe den Eindruck, dass es damit eher schlechter geworden ist.
Hm, an der ganzen Timing-Logik hatte ich gar nix verändert.
Leider habe ich keinen RT. Könntest du da etwas unterstützen.
[/quote]
Gruß
Dirk
Hi PeMue,
Zitat
Wie bestückst Du die Hardware für die Sensoren mit externer Spannungsversorgung? Nimmst Du da den RS485 Teil? Welche Spannung braucht man dann?
So ist es. An Stelle des Batteriehalters wird ein Schaltregler bestückt der aus ca. 6-7 bis 30 V 5 V erzeugt. Dahinter ist ein kleiner Liniarregler der für den AVR und die Sensoren aus den 5 V die benötigten 3,3 V macht. Der MAX ist in dieser Bestückungsvariante nicht bestückt.
ZitatKönnte man alternativ nicht auch 5 V an den Batteriepins einspeisen (wenn man einen MAX1724 bestückt hat)?
Da der Max1724 aber bis zu 5,5 V Eingangsspannung verdaut, kannst du deine 5V auch an die Pins des Batteriehalters direkt anschließen.
ZitatAus elektrotechnischer Sicht würde ich den Batteriebetrieb ohne MAX1724 wegen der Akkulaufzeit bzw. Stabilität der Spannungsversorgung nicht wirklich empfehlen.
Kommt drauf an welche Sensorbestückung gewählt wird. Der Atmega328p und der BMP180 laufen sicher bis runter zu 1,8V.
In dieser Kombination macht auch ein Betrieb ohne Max durchaus Sinn. Mit Max kann man halt noch ein paar mV mehr aus den Batterien quetschen.
Auch SHT10 und den Helligkeitssensor betreibe ich teilweise ohne Max. Allerdings wird dann die Mindestspannung für diese Sensoren schon recht schnell unterschritten. Daher würde die Batterielaufzeit hier nur recht kurz sein.
ZitatVermutlich ist die Wahl entweder OTAU Bootloader (und dann Programmieren über fhem) oder serieller Bootloader, korrekt?
Man muss auch beachten das der OTA-Update aktuell nur mit HM-USB-CFG oder einem CUxx mit serieller Schnittstelle wie CUL oder CSM funktioniert. Mit der CCU2 sollte es später auch gehen, aber wohl nicht in Verbindung mit dem "alten" (runden) HM-LAN Adapter. Es sei denn der bekommt das nötige FW-Update.
ZitatMit ISP (und entsprechend angeschlossenem Programmer bzw. Raspberry Pi und Verkabelung bzw. Skript) müsste es aber möglich sein, den Bootloader einfach auszutauschen.
Ja, das kann man. Man kann auch aus einem Arduino einen ISP machen. Man könnte sogar einen der Sensoren kurzzeitig über den seriellen oder auch über den OTAU-Bootloader zu einem ISP umflashen. Dann braucht man nur noch einen UART-USB-Adapter dazu.
ZitatAllerdings wäre es mAn in der Dokumentation hilfreich, einen Hinweis auf die zu setzenden Fuses zu machen (da tu ich mir immer schwer), und wenn es falsch ist, kann es sein, dass der Prozessor nicht mehr will ...
Das wird es noch geben. Ich werde auch wieder ein Flash-Tool bauen, bzw. liegt das hier schon rum, mit dem man beim Flashen des Bootloaders Seriennummer und HM-ID angeben kann, ohne den Quellcode neu zu bauen. Auch werden dann damit die Fusebits schon richtig gesetzt
Viele Grüße
Dirk
Zitat von: Dirk am 20 August 2014, 00:01:40
Da der Max1724 aber bis zu 5,5 V Eingangsspannung verdaut, kannst du deine 5V auch an die Pins des Batteriehalters direkt anschließen.
Oder anstelle des Batteriehalters eine (Micro-)USB-Buchse anlöten und über eine der in Haushalten mittlerweile immer mehr verfügbaren USB-Anschlüsse betreiben. ;-)
Zitat von: Dirk am 19 August 2014, 23:34:39
Hm, an der ganzen Timing-Logik hatte ich gar nix verändert.
Leider habe ich keinen RT. Könntest du da etwas unterstützen.
Hi,
prinzipiell ja, aber erst in so etwa vier Wochen. Dann habe ich ja vielleicht auch noch mehr von den Dingern und kann besser rumspielen.
Gruß,
Thorsten
Hallo Dirk,
Zitat von: Dirk am 20 August 2014, 00:01:40
Man muss auch beachten das der OTA-Update aktuell nur mit HM-USB-CFG oder einem CUxx mit serieller Schnittstelle wie CUL oder CSM funktioniert. Mit der CCU2 sollte es später auch gehen, aber wohl nicht in Verbindung mit dem "alten" (runden) HM-LAN Adapter. Es sei denn der bekommt das nötige FW-Update.
Ja, das kann man. Man kann auch aus einem Arduino einen ISP machen. Man könnte sogar einen der Sensoren kurzzeitig über den seriellen oder auch über den OTAU-Bootloader zu einem ISP umflashen. Dann braucht man nur noch einen UART-USB-Adapter dazu.
Das wird es noch geben. Ich werde auch wieder ein Flash-Tool bauen, bzw. liegt das hier schon rum, mit dem man beim Flashen des Bootloaders Seriennummer und HM-ID angeben kann, ohne den Quellcode neu zu bauen. Auch werden dann damit die Fusebits schon richtig gesetzt
Viele Grüße
Dirk
wann wird ungefähr "später" sein ? Ich habe leider nur die CCU2. Mein CUL ist ein 433 MHz-CUL, kommt somit zum OTA-Update eher nicht in Frage. Wird das Flashtool auf der CCU laufen ?
lg.
TF
@Thorsten: Entschuldige die Frage - aber was ist ein "RT"?
@Dirk: Welchen Bootloader sollte man nehmen? Hast du da mal einen Link?
Zitat von: cactus-online am 21 August 2014, 08:22:39
wann wird ungefähr "später" sein ? Ich habe leider nur die CCU2.
Vielleicht in 1, 2 oder 3 Wochen. Kann ich noch nicht genau sagen. Das muss ich noch testen. Ggf. brauche ich dazu Unterstützung da ich keine CCU2 habe.
ZitatMein CUL ist ein 433 MHz-CUL, kommt somit zum OTA-Update eher nicht in Frage. Wird das Flashtool auf der CCU laufen ?
Die CUL's 443 und 886 unterscheiden sich nur Hardwareseitig wegen der Antennenanpassung. Man kann mit dem CUL433 aber auch im 866Mhz-Bereich senden und empfangen. Zwar mit Reichweiteneinbußen. Aber über kurze Distanzen sollte das Update dann also auch mit dem CUL443 funktionieren.
Zitat von: thunder1902 am 21 August 2014, 08:42:19
@Dirk: Welchen Bootloader sollte man nehmen? Hast du da mal einen Link?
Wenn du über Funk updaten willst / kannst, dann den OTAU Bootloader nehmen:
https://github.com/kc-GitHub/Asksin_OTA_Bootloader
Das Flash-Tool habe ich aber noch nicht veröffentlicht. Daher musst du deine Adressdaten im Moment noch vor dem Kompilieren festlegen.
Und FW-Version 0.11 solltest du für den Sensor benutzen. Diese benutzt die Adressdaten aus dem Bootloder. Dann muss man die nicht bei jedem Update ändern. Den muss ich aber auch noch einchecken. Das mache ich die Tage aber noch.
Ansonsten nimm erst mal den Seriellen Bootloader. Der und das Flash-Tool sind im Github:
https://github.com/kc-GitHub/Wettersensor
RT ist übrigens der Raum-Thermostat. Mit dem kann man den Sensor Peeren im die Temperatur abgesetzt vom Thermostat zu messen.
Und hier gibt es beim Peering ab und zu noch aussetzer.
Zitat von: thunder1902 am 21 August 2014, 08:42:19
@Thorsten: Entschuldige die Frage - aber was ist ein "RT"?
Das ist kurz für "HM-CC-RT-DN", also das hier: http://www.elv.de/homematic-heizkoerperthermostat-1.html (http://www.elv.de/homematic-heizkoerperthermostat-1.html)
Gruß,
Thorsten
Zitat von: Dirk am 21 August 2014, 09:31:07
Vielleicht in 1, 2 oder 3 Wochen. Kann ich noch nicht genau sagen. Das muss ich noch testen. Ggf. brauche ich dazu Unterstützung da ich keine CCU2 habe.
Kann ich machen.
Zitat von: Dirk am 21 August 2014, 09:31:07
Wenn du über Funk updaten willst / kannst, dann den OTAU Bootloader nehmen:
https://github.com/kc-GitHub/Asksin_OTA_Bootloader
Das Flash-Tool habe ich aber noch nicht veröffentlicht. Daher musst du deine Adressdaten im Moment noch vor dem Kompilieren festlegen.
Und FW-Version 0.11 solltest du für den Sensor benutzen. Diese benutzt die Adressdaten aus dem Bootloder. Dann muss man die nicht bei jedem Update ändern. Den muss ich aber auch noch einchecken. Das mache ich die Tage aber noch.
Da ich noch kein HM-CFG-LAN habe - kann man da auch eine beliebige Adresse vorab nehmen, um mal den Upload zu testen?
Zitat von: Dirk am 21 August 2014, 09:31:07
Ansonsten nimm erst mal den Seriellen Bootloader. Der und das Flash-Tool sind im Github:
https://github.com/kc-GitHub/Wettersensor
Ich wollte diesen Bootloader mal auf meinen Arduino Mini Pro mit dem XLoader draufspielen (mit einem weiteren Mini Pro als ArduinoISP). Leider sagt er immer nach einer Weile Aktivität "Upload failed". Welches Flash-Tool nimmst du da her? In deinem angesprochenen GitHub habe ich kein Flash-Tool gefunden, bei dem man keine HM-ID an/eingeben muss...(oder ist dieses "iconv.exe" das Tool, das du meinst?).
- kann man auch den normalen Bootloader von der Arduino-Umgebung hernehmen??
Noch eine Frage :-)
- kannst du (oder jemand anderes) noch den avrdude-Befehl für die Fuses nennen? Ich glaube, man muss ja den Quarz abschalten, so wie ich das im Schaltbild gesehen hab....??
Schonmal Danke für's Antworten - ich hoffe, meine Fragen sind nicht zu lästig... :-)
Zitat von: thunder1902 am 22 August 2014, 14:14:01
- kannst du (oder jemand anderes) noch den avrdude-Befehl für die Fuses nennen?
Vielleicht meinst du ja was ganz anderes als ich glaube, aber wie die Fuses gesetzt werden, hat Dirk doch in in seiner readme.md beschrieben:
avrdude -p m328p -P usb -c usbasp -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m
Zitat von: Mr. P am 22 August 2014, 14:17:01
avrdude -p m328p -P usb -c usbasp -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m
... und mit dem Datenblatt des Atmega328 kann man auch herausfinden, welche Fuse was macht. Allerdings war da was mit PonyProg (das hoffentlich keiner mehr braucht), daß die Bedeutung des Ankreuzen rumgedreht wird ???
Genau das ist, was mir immer wieder Kopfzerbrechen macht >:(
Gruß PeMue
Module sind bei mir angekommen und und funktionierten auf Anhieb, wirklich super!
Aber eine Frage wäre da, mein "vollbestückter" Sensor Typ 06 sendet alle 10 Sekunden, während Typ 02 sich nur alle 2-3 Minuten mal meldet. Ist das absicht/bekannt?
Grüße, Marcel
Zitat von: MarcelK am 22 August 2014, 23:00:07
mein "vollbestückter" Sensor Typ 06 sendet alle 10 Sekunden, während Typ 02 sich nur alle 2-3 Minuten mal meldet. Ist das absicht/bekannt?
Ah, kann sein dass ich hier noch die Test-Firmware drauf habe.
Damit teste ich die Sensoren, um nicht immer 2,5 Min. warten zu müssen.
Dann darfst du an dem Sensor gleich das OTA-Update ausprobieren :)
Die FW ist im Anhang.
sudo ./flash-ota -f HB-UW-Sen-THPL-I_11b.eq3 -s <SERIAL_NUMBER>Gruß
Dirk
Zitat von: MarcelK am 22 August 2014, 23:00:07
Module sind bei mir angekommen und und funktionierten auf Anhieb, wirklich super!
Nicht sag, dass Dirk sie schon fix-fertig gelötet gehabt hat? :o
Zitat von: Dirk am 22 August 2014, 23:07:43
Die FW ist im Anhang.
Gaaanz sicher? :-)
Zitat von: Mr. P am 23 August 2014, 11:45:55
Die FW ist im Anhang.
Gaaanz sicher? :-)
Nein, da ist nichts im Anhang :D
Gruß PeMue
Mist, ich bin mir sicher dass ich die Datei angehängt hatte. Dabei war es gestern doch noch gar nicht so spät.
Ich habe den ursprünglichen Beitrag editiert.
Gruß
Dirk
Zitat von: Dirk am 22 August 2014, 23:07:43
Dann darfst du an dem Sensor gleich das OTA-Update ausprobieren :)
sudo ./flash-ota -f HB-UW-Sen-THPL-I_11b.eq3 -s <SERIAL_NUMBER>
Irgedwie hab ich nen gerade nen Knopf ;-)
Um den Sensor per OTA zu flashen, muss doch zuerst der OTA-Bootloader drauf.
Und den OTA-Bootloader bekommt man nur mit einem ISP-Programmer drauf.
Ebenfalls muss man den OTA Bootloader mit der eigenen Serieal zuerst kopilieren.
Also gleich ein Firmware Update mit dem Flash-Tool "flash-ota" wird wohl nicht gehen ?
Grüsse Martin
PS: ist das x.eq3 und x.hex das Gleiche ?
wenn deine bestellung mit ota bootloader war, ist der doch schon drauf.
ZitatPS: ist das x.eq3 und x.hex das Gleiche ?
nein. wie im sudo-befehl zu erkennen ist, das eq3-file nehmen.
Zitat von: mmatt am 23 August 2014, 16:41:23
Um den Sensor per OTA zu flashen, muss doch zuerst der OTA-Bootloader drauf.
Der OTAU Bootloader ist schon drauf.
ZitatEbenfalls muss man den OTA Bootloader mit der eigenen Serieal zuerst kopilieren.
Diese Daten stecken im Bootloader.
ZitatAlso gleich ein Firmware Update mit dem Flash-Tool "flash-ota" wird wohl nicht gehen ?
Doch, genau so. Das ist ja der Sinn von dem Bootloader, dass man das ohne ISP selber machen kann.
ZitatPS: ist das x.eq3 und x.hex das Gleiche ?
Das eq3-File ist für den OTAU Bootloader aufbereitet. Also das nehmen.
Das Hex-File nimmt man, um per Seriellen Bootloader zu flashen bzw. auch zum Flashen mit dem ISP
Gruß
Dirk
Vielen Dank soweit.
Ich dachte, die Sensoren haben generell den seriellen Bootloader drauf :-)
Grüsse Martin
Zitat von: mmatt am 23 August 2014, 17:08:35
Ich dachte, die Sensoren haben generell den seriellen Bootloader drauf :-)
Das war früher mal so :)
Die aktuellen haben standardmäßig den OTAU-Bootloader drauf. Der Serielle Bootloader ist dann optional.
Gruß
Dirk
Vielen Dank an Dirk ! Es funktioniert wirklich auf Anhieb - wenn man nicht wie ich vergessen hat, das Addon in die CCU einzuspielen.
Allerdings sehe ich auch Sensoren, die gar nicht da sind. Ich hatte das so verstanden, dass diese ausgeblendet werden ... . Im log ist es korrekt zu lesen:
20:43:23 23.08.2014 HB-UW-Sen-THPL-O UWS0812635:1
Temperatur 24.50°C, unbekannte Meldung (HUMIDITY=NO_SENSOR), Luftdruck 1007hPa, unbekannte Meldung (LUMINOSITY) 678.02, unbekannte Meldung (BatteryVoltage) 3.15V
...
Ich habe leider nichts dazu gefunden, daher muss ich noch eine Frage loswerden. Wo/wie schließe ich das Breakout-Board im Außensensor an und welcher der beiden Temperaturfühler wird eigentlich an die CCU gemeldet ?
Zitat von: cactus-online am 23 August 2014, 20:49:53
Allerdings sehe ich auch Sensoren, die gar nicht da sind. Ich hatte das so verstanden, dass diese ausgeblendet werden
Das ausblenden macht nur FHEM. Bzw. zeigt FHEM Sensoren nicht an, dessen Werte es noch nicht empfangen hat.
Das kann die CCU so nicht, bzw. ich weis aktuell nicht wie.
Ansonsten brächte man für jede Sensorkombination ein eigenes XML-File in der CCU.
ZitatWo/wie schließe ich das Breakout-Board im Außensensor an
Ich stelle dazu nacher noch ien Bild ein.
Zitatund welcher der beiden Temperaturfühler wird eigentlich an die CCU gemeldet ?
Ohne externe SHT10 wird die Temperatur vom Luftdrucksensor gelesen.
Mit externen SHT10 wird die Temperatur und die Feuchte vom SHT10 gelesen.
Gruß
Dirk
Prima. Dann warte ich und werde "Hand anlegen".
Noch eine Sache: In der CCU kann ich für Temperatur und Luftfeuchte, nicht jedoch für Luftdruck und Helligkeit, Diagramme anlegen. Wo muss ich 'ran um hier etwas zu ändern ?
Zitat von: cactus-online am 23 August 2014, 21:55:28
In der CCU kann ich für Temperatur und Luftfeuchte, nicht jedoch für Luftdruck und Helligkeit, Diagramme anlegen.
Mit den Diagrammen der CCU hab ich mich noch gar nicht beschäftigt.
Das müsste ich mir noch ansehen. Vermutlich fehlt da noch ein bestimmter Eintrag im XML-File
Zitat von: Dirk am 22 August 2014, 23:07:43
sudo ./flash-ota -f HB-UW-Sen-THPL-I_11b.eq3 -s <SERIAL_NUMBER>
An meiner FHEM Installation hängt nur der HM-LAN, daher hab ich es mit der offiziellen HM Software mit HM-CFG-USB an einem Windows-Laptop versucht. Sollte doch eigentlich kompatibel sein, oder? Sah auch recht gut aus, bis immer so um 80% rum (nach ~50Sekunden), dann ist der Vorgang mit Übertragungsfehler abgebrochen (LED hat auch aufgehört zu blinken) und startet nach kurzer Zeit von Neuem. Befindet sich jetzt sozusagen in einer Flash-Schleife ;-) Irgendeine Idee? Im Notfall spiel ich's mit dem ISP neu auf, aber wäre ja schon cool wenn das so gehen würde.
Beste Grüße, Marcel
Zitat von: Dirk am 23 August 2014, 22:03:35
Mit den Diagrammen der CCU hab ich mich noch gar nicht beschäftigt.
Das müsste ich mir noch ansehen. Vermutlich fehlt da noch ein bestimmter Eintrag im XML-File
Gibt es irgendwo eine Doku zu diesen device.xml's ? Ich habe mir jetzt gerade mal die originalen eq3.xml's angesehen und kann leider keinen Ansatzpunkt finden.
Zitat von: cactus-online am 24 August 2014, 11:05:39
Gibt es irgendwo eine Doku zu diesen device.xml's ? Ich habe mir jetzt gerade mal die originalen eq3.xml's angesehen und kann leider keinen Ansatzpunkt finden.
Mit Sicherheit. Aber wohl nicht für uns. Das müssen wir selber dokumentieren.
Sorry, wenn ich nochmal blöd frage:
Die Vorgehensweise, um den Temperatursensor auf einen Ebay-Arduino-Mini-Pro zu flashen, ist folgende:
1. Fuses einstellen (avrdude -p m328p -P usb -c usbasp -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m)
2. Bootloader per ISP flashen. Dazu entweder OTA oder Seriellen Bootloader nehmen. Dazu avrdude hernehmen.
3. Dirk's Firmware mit dem Tool im Ordner "Flash-Tool-Windows", flash.cmd per ISP flashen.
4. mit der HMConfig_SenTHPL.pm den Sensor in Fhem einbinden.
Richtig???
Also IMHO haben die fertigen Arduino Mini Pro´s einen Bootloader schon drauf.
Warum also nochmal einen neu flashen?
Zitat von: thunder1902 am 25 August 2014, 09:54:31
3. Dirk's Firmware mit dem Tool im Ordner "Flash-Tool-Windows", flash.cmd per ISP flashen.
Das Flash-Tool ist für das Updaten per Seriellem Bootloader gedacht. Für den OTAU-Bootloader den man per ISP flashen muss, habe ich das Flashtool noch nicht veröffentlicht.
Daher müsstest du dir aktuelle eine eigene Version mit deinen gewünschten Adressdaten kompilieren.
Ich stelle das die Tage aber noch online.
Zitat von: Tobias am 25 August 2014, 10:14:15
Warum also nochmal einen neu flashen?
Falls man den OTAU-Bootloader möchte.
Gruß
Dirk
Nicht jeder Mini Pro aus China hat auch einen Bootloader drauf... :-)
Zitat von: Tobias am 25 August 2014, 10:14:15
Also IMHO haben die fertigen Arduino Mini Pro´s einen Bootloader schon drauf.
Warum also nochmal einen neu flashen?
Zitat von: Dirk am 25 August 2014, 02:32:06
Mit Sicherheit. Aber wohl nicht für uns. Das müssen wir selber dokumentieren.
Scheint so, leider. http://matthiasm.com/homematic-HM-PB-2-WM55.html (http://matthiasm.com/homematic-HM-PB-2-WM55.html) ist schon mal ein Anfang.
Zitat von: MarcelK am 24 August 2014, 09:23:58
Sah auch recht gut aus, bis immer so um 80% rum (nach ~50Sekunden), dann ist der Vorgang mit Übertragungsfehler abgebrochen (LED hat auch aufgehört zu blinken) und startet nach kurzer Zeit von Neuem.
Hier die Ausgabe des Bootloaders falls das interessant sein sollte:
AskSin OTA Bootloader V0.6
TX: bootloader sequence
Wait for CB Msg
Got msg to start config
Sw to 100k
Wait for CB Msg
Got msg to start config
TX: ACK
Start receive firmware
...[188 Punkte insgesamt, die Forum-Software kürz das aber aus irgendeinem Grund auf 3 runter]...FATAL: Wrong msgId detected!
FATAL: Wrong msgId detected!
Block length differ with page size
FATAL: Wrong msgId detected!
Block length differ with page size
FATAL: Wrong msgId detected!
Block length differ with page size
FATAL: Wrong msgId detected!
Block length differ with page size
FATAL: Wrong msgId detected!
[...]
Timeout
CRC fail: Reboot
Danach habe ich in einem Anfall geistiger Umnachtung (war auch schon sehr spät :o) die Fuse-Settings für den m644 auf den m328 gespielt und damit das ISP Interface abgeschaltet... hoffe den Chip bei Gelegenheit per HVPP nochmal retten zu können.
[quote author=MarcelK link=topic=20620.msg194613#msg194613 date=1408959125]
FATAL: Wrong msgId detected!
Block length differ with page size
Solche Fehler hatte ich, wenn der CUL und der Sensor sehr dicht bei bei einander standen. Bzw. Wenn das Kabel zum UART sehr dicht bzw. über der Antenne vom CUL lag.
ZitatDanach habe ich in einem Anfall geistiger Umnachtung (war auch schon sehr spät :o) die Fuse-Settings für den m644 auf den m328 gespielt und damit das ISP Interface abgeschaltet...
IHH. Ich habe hier auch noch ein Paar AVR's die ich "retten" muss.
Zitathoffe den Chip bei Gelegenheit per HVPP nochmal retten zu können.
Das hier:
http://mightyohm.com/blog/2008/09/arduino-based-avr-high-voltage-programmer/
sieht interessant aus. Das werde ich mal testen.
Zitat von: cactus-online am 25 August 2014, 11:26:08
Scheint so, leider. http://matthiasm.com/homematic-HM-PB-2-WM55.html (http://matthiasm.com/homematic-HM-PB-2-WM55.html) ist schon mal ein Anfang.
Das kannte ich noch gar nicht. Danke für den Link.
Zitat von: Dirk am 25 August 2014, 11:47:46
Solche Fehler hatte ich, wenn der CUL und der Sensor sehr dicht bei bei einander standen. Bzw. Wenn das Kabel zum UART sehr dicht bzw. über der Antenne vom CUL lag.
Auffällig war eben dass es immer an der gleichen Stelle passiert ist. Kann's mal mit noch mehr Abstand versuchen wenn ich es je wieder zum laufen bekomme ;-)
Zitat von: Dirk am 25 August 2014, 11:47:46
Das hier:
http://mightyohm.com/blog/2008/09/arduino-based-avr-high-voltage-programmer/
sieht interessant aus. Das werde ich mal testen.
Ich benutz den AVR Dragon, der kann praktisch alles und kost nicht viel. Wobei ich HVPP bisher noch nie versucht habe, nur ISP und JTAG. Wollte es eben testen, leider fehlen mir die passenden Jumper-Kabel und im Labor hier gibt's sowas auch nicht, grmpf. Gibt's halt ne Zwangspause bis die Lieferung da ist >:(
Zitat von: Dirk am 25 August 2014, 11:47:46
Das kannte ich noch gar nicht. Danke für den Link.
Ja leider ist die Info von wegen Statistik/Diagramm aber hier auch nicht gefunden worden.
ZitatAn meiner FHEM Installation hängt nur der HM-LAN, daher hab ich es mit der offiziellen HM Software mit HM-CFG-USB an einem Windows-Laptop versucht.
hast du eventuell das falsche file benutzt? für die win software muss das eq3-file noch konvertiert werden.
tar -czf payload.tar.gz payload.eq3 # create .tar.gz for homematic windows tool
Zitat von: frank am 25 August 2014, 13:29:28
hast du eventuell das falsche file benutzt? für die win software muss das eq3-file noch konvertiert werden.
tar -czf payload.tar.gz payload.eq3 # create .tar.gz for homematic windows tool
Danke, aber den Schritt habe ich natürlich gemacht, sonst wäre der Flash Vorgang gar nicht soweit gekommen (die eq3 Software ist da ohnehin extrem pingelig, selbst wenn die Endung .tgz statt .tar.gz ist schlägt der Vorgang schon fehl).
Hej zusammen,
meine Sensoren sind heute angekommen und habe vorhin versucht, den ersten anzubinden. Also .hm-File in den lib-Ordner gespielt und FHEM neu gestartet.
Anschließend wurde er per autocreate erkannt, laut Readings hat auch das Pairing funktioniert. Jetzt finde ich zwar regelmäßig Raw-Messages im Logfile (im Hauptlogfile mit logIDs), aber außer wenn ich den Knopf am Sensor drücke, bekomme ich keine Meldungen in den Registern angezeigt (und da auch nur Register für Firmware und Seriennummer).
Außer das bei den Attributen 'model' als 'unknown' und der 'subType' leer ist, kann ich keine Fehler finden. Neustarts hab ich schon ein paar Mal probiert.
Hat vielleicht einer derjenigen, die ihre Sensoren ebenfalls bereits erhalten haben, einen Tipp für mich, worauf ich noch achten sollte?
Thx a lot! :-)
Hi Mr. P. Ich hab auch zwei Anläufe gebraucht. Nachdem die File drin war hab ich nochmal alles aus der cfg gelöscht und neu von fhem eintragen lassen. Ich hab den Model-Typ gemäß der pm selbst gesetzt. Weiß aber nicht, ob ich das gemusst hätte.
Gruß
Markus
Gesendet von iPad mit Tapatalk
Hej Markus,
danke für die Antwort. Nachdem autocreate 'model' und 'subType' nicht von selbst eingetragen hatte, hab ich auch schon versucht, die Parameter aus dem .pm-File einzutragen... leider ohne Erfolg. :-/
Zitat von: Mr. P am 25 August 2014, 23:00:31
Nachdem autocreate 'model' und 'subType' nicht von selbst eingetragen hatte, hab ich auch schon versucht, die Parameter aus dem .pm-File einzutragen... leider ohne Erfolg. :-/
Sorry falls die Frage dämlich vorkommt, aber manchmal sind's ja die einfachen Dinge... FHEM hast Du nach Einspielen der pm Datei ins FHEM Verzeichnis aber schon neu gestartet?
Ich musste übrigens kein Model manuell eintragen.
Zitat von: MarcelK am 25 August 2014, 23:15:52
Sorry falls die Frage dämlich vorkommt, aber manchmal sind's ja die einfachen Dinge... FHEM hast Du nach Einspielen der pm Datei ins FHEM Verzeichnis aber schon neu gestartet?
Ja, hab ich gemacht - hatte ich vorhin aber auch schon geschrieben. ;-)
Zitat von: Mr. P am 25 August 2014, 23:20:11
Ja, hab ich gemacht - hatte ich vorhin aber auch schon geschrieben. ;-)
Übersehen, sorry. Passen die File-Permissions? Anscheinend wird das PM nicht geladen, sonst könnte FHEM das Model erkennen. Alles andere (pairing etc.) geht auch ohne, ist also kein Hinweis darauf dass es vorhanden ist.
Zitat von: MarcelK am 25 August 2014, 23:31:30
Passen die File-Permissions? Anscheinend wird das PM nicht geladen, sonst könnte FHEM das Model erkennen. Alles andere (pairing etc.) geht auch ohne, ist also kein Hinweis darauf dass es vorhanden ist.
File-Permissions passen, ja.
Ich kann mir auch nichts anderes vorstellen, als das es nicht geladen wird. Leider gibt es mWn keine Möglichkeit zu überprüfen, ob es geladen wurde oder nicht. :-/
So, lasse die HMConfig_SenTHPL.pm jetzt manuell in der 10_CUL_HM.pm includen und siehe da... alles funktioniert.
Werde einmal mit Martin reden, woran es liegen kann, dass das File automatisch nicht gefunden wird.
Habe alle Sensoren online und warte jetzt einmal ein paar Stunden ab, bis sie sich akklimatisiert haben. Bin schon auf die Zahlen in der Früh gespannt. :-)
Ein kurzes Feedback zur Luftdruckmessung:
Diese scheint bei mir sehr genau zu treffen. Der gemessene Luftdruck, korrigiert nach der barometrische Höhenformel (ich habe http://rechneronline.de/barometer/ verwendet) deckt sich sehr genau mit den Werten, die mir für den benachbarten Flughafen angezeigt werden. Ideal wäre natürlich, wenn wir schon einen korrigierten Luftdruck übermittelt bekämen (hat Dirk aber schon auf die Wunschliste für Features der Firmware geschrieben ;-) ).
Für eine Beurteilung der Wettersituation kann man sich wohl aber auch jetzt sehr gut auf den Messwert verlassen.
Das Modul liefert doch zwei Luftdruckwerte: Einmal den gemessenen und einmal den korrigierten, sofern Du das globale Attribut altitude für Deinen Standort in fhem gepflegt hast. Welcher Luftdruckwert fehlt Dir denn jetzt noch?
Er benutzt den Sensor an einer CCU. Der Sensor liefert nur den Luftdruck. Die Korrektur für den Luftdruck bezogen auf Meereshöhe mach das FHEM-Modul. Das kann die CCU so (noch) nicht.
Gruß
Dirk
Kann bitte jemand, mit einem voll bestückten Sensor, ein xmllist posten?
Würde das Device gerne bei andFHEM einpflegen lassen - habe selbst aber nur Versionen ohne Luftdruck.
Thx a lot! :-)
Nur so aus Interesse: Berücksichtigt das FHEM-Modul eigentlich auch die aktuelle Temperatur bei der Berechnung ?
Nein, in FHEM benutze ich aktuell nur eine ganz einfache Form der Höhenformel:
$pressureNN = $pressure + ($altitude / 8.5)
Zitat von: Mr. P am 27 August 2014, 11:56:21
Kann bitte jemand, mit einem voll bestückten Sensor, ein xmllist posten?
Würde das Device gerne bei andFHEM einpflegen lassen - habe selbst aber nur Versionen ohne Luftdruck.
Hab mal eine angegangen.
Die gilt für Model HB-UW-Sen-THPL-O und Model HB-UW-Sen-THPL-I. Also für den geasmmten Subtype THPLSensor
Gruß
Dirk
Zitat von: Dirk am 27 August 2014, 12:19:30
Hab mal eine angegangen.
Die gilt für Model HB-UW-Sen-THPL-O und Model HB-UW-Sen-THPL-I. Also für den geasmmten Subtype THPLSensor
Thx a lot! :-)
Btw. habe seit 30 Stunden einen der Sensoren mit einem RT gepeert und seither gibt es keinerlei Ausreißer am RT, dass er auf den internen Sensor zurückgegriffen hätte.
So, der AtMega328 ist dank meines selbstgebastelten MIF HVPP-Adapters (Maximum Insertion Force, erst wenn der Daumen weh tut ist der Kontakt gut genug zum Programmieren 8)) gerettet :D Heute kam dann schon die Lieferung an Ersatz-CPUs, von daher hätte ich mir den Aufwand sparen können, aber war eine Erfahrung wert...
Punkt zwei, das Flash-Problem. Tatsächlich ist das ein Bug im Bootloader. Die Variable expectedMsgId wird als 16-bit definiert, aber mit einem 8-bit Wert verglichen. Wenn die vorherige MsgId nun zufällig 0xFF war (was zumindest bei der Windowssoftware deterministisch immer an der selben Stelle der Fall war), dann wird nach Addition von 1 folglich 0x0100 mit 0x0000 verglichen -> Fail.
Abhilfe:
- uint16_t expectedMsgId = data[1] + 1;
+ uint8_t expectedMsgId = data[1] + 1;
Drittes Problem: Der selbstcompilierte Bootloader funktionierte zwar, die Firmware hatte danach aber nicht die gewünschte Model, Seriennummer und ID. Mein GCC ordnete die Variablen hm_Type, hm_serial und hm_id in der .addressSection Section einfach neu in die Reihenfolge hm_serial, hm_id und danach erst hm_type. Als Abhilfe habe ich jetzt einfach mal 3 getrennte Sektionen mit exakt definierter Start-Adresse verwendet.
So, war ein etwas steiniger Weg, aber konnte den Adapter nun mit der Windows-Software flashen und er sendet jetzt auch nur noch brav alle 2-3 Minuten ;D
Danke nochmal für das coole Teil und beste Grüße, Marcel
Zitat von: Dirk am 27 August 2014, 11:52:08
Er benutzt den Sensor an einer CCU.
Danke für die Info, so weit war ich im Thread wohl nicht zurückgegangen ;)
Zitat von: cactus-online am 27 August 2014, 12:06:27
Nur so aus Interesse: Berücksichtigt das FHEM-Modul eigentlich auch die aktuelle Temperatur bei der Berechnung ?
Ich habe schon vor längerem beide Korrekturrechnungen durchgeführt und verglichen, einmal mit und einmal ohne berücksichtigte Temperatur. Der Unterschied ist vernachlässigbar und liegt unter 1 hPa.
Zitat von: MarcelK am 27 August 2014, 22:26:54
Punkt zwei, das Flash-Problem. Tatsächlich ist das ein Bug im Bootloader.
IHH, Danke für's finden.
Ich checke das dann gleich mal ein.
ZitatMein GCC ordnete die Variablen hm_Type, hm_serial und hm_id in der .addressSection Section einfach neu
Ok, dann werde ich das auch noch entsprechend Ändern. Hast du hier irgendwelche Optimierungen eingeschaltet?
Was hast du da für einen Programmer bzw. Was ist das für ein Board?
Gruß
Dirk
Zitat von: Dirk am 27 August 2014, 22:47:22
Ok, dann werde ich das auch noch entsprechend Ändern. Hast du hier irgendwelche Optimierungen eingeschaltet?
Nein, hab einfach nur das original Makefile verwendet. Vom Standard her dürfte die Order aber auch nicht garantiert sein und gcc macht da gerne mal Dinge die man so nicht erwartet. Und vor allem von Version zu Version anders...
Zitat
Was hast du da für einen Programmer bzw. Was ist das für ein Board?
Das ist der erwähnte AVR Dragon (http://www.atmel.com/tools/avrdragon.aspx) von Atmel. Kann ISP, JTAG, HVSP, HVPP und sogar DebugWire. An Devices kann es ziemlich viel, inklusive der ATxmega und AT32 Serien, die hab ich aber noch nicht getestet. Kost in der Regel rund 65€, nur das Gehäuse muss man selbst feilen ;) Ich hab alle Pins auf nen 40er Flachband gelegt und kann dann mit alten IDE Kabeln verschiedene Adapter basteln und entsprechend anschließen. Manche löten aber auch direkt ein TexTool drauf oder ätzen sich diverse Adapterplatinen.
Grüße, Marcel
Zitat von: MarcelK am 27 August 2014, 23:20:03
Vom Standard her dürfte die Order aber auch nicht garantiert sein
Ja, stimmt. Das sind jetzt ja einzelne Variablen. Die kann der gcc natürlich beliebig umsortieren. Ich habe das Makefile auch mit nachgezogen.
Kannst ja mal ins git schauen dass ich nix vergessen habe.
ZitatDas ist der erwähnte AVR Dragon (http://www.atmel.com/tools/avrdragon.aspx) von Atmel.
Ah, ok. Ich hatte den irgendwie anders in Erinnerung.
Gruß
Dirk
Zitat von: Dirk am 27 August 2014, 23:46:38
Ja, stimmt. Das sind jetzt ja einzelne Variablen. Die kann der gcc natürlich beliebig umsortieren. Ich habe das Makefile auch mit nachgezogen.
Kannst ja mal ins git schauen dass ich nix vergessen habe.
Ja, sieht gut aus, sollte passen denke ich.
Grüße, Marcel
Hallo,
mal eine etwas andere Frage: Ich beschäftige mich mit dem Gedanken (der Krams aus China ist leider noch nicht da, daher nur ein Gedankenspiel ...) aus dem Sensor ein Sensorthermometer zu machen, d.h. den Sensor mit einer Anzeige zu versehen. Das dürfte soweit nicht schwer sein. Allerdings wäre es perfekt, neben der Innentemperatur, auch die Aussentemperatur anzuzeigen.
Vielleicht ist das ja eine ganz blöde Frage, aber ich bin ja neu in dem Thema - es mag mir vielleicht verziehen sein. Könnte man die Außentemperatur am Innensensorthermometer irgendwie bekommen, von der CCU oder vom Außensensor selbst ?
lg.
TF
Zitat von: cactus-online am 28 August 2014, 08:23:31
aus dem Sensor ein Sensorthermometer zu machen, d.h. den Sensor mit einer Anzeige zu versehen. Das dürfte soweit nicht schwer sein.
Was für ein Display hast du hier in Planung. Das muss ja entweder für Batteriebetrieb entsprechend wenig Energie verbrauchen oder du mußts das Ganze dann extern versorgen.
ZitatKönnte man die Außentemperatur am Innensensorthermometer irgendwie bekommen, von der CCU oder vom Außensensor selbst ?
Dafür muss man wohl ein neuen Gerätetyp bauen. Ich würde die Daten aber nicht von der CCU beziehen, sondern das Teil mit einem weiteren Sensor peeren von dem es die Temperatur bezieht.
Da die aktuelle Firmware ziemlich start Arduino-Komponenten einsetzt, ist der Programmspeicher schon gut gefüllt. Daher muss man hier wohl etwas umbauen damit der Code dann noch in die verbleibenden 28k passt. Falls es ganz eng wird, könnte man zur Not den Bootloader einsparen. Dann hätte man noch weitere 4k zur Verfügung.
Gruß
Dirk
Ich dachte an ein LCD-Display. Die Sache ist die, meiner besseren Hälfte werde ich niemals beibringen, dass sie Ihr Smartphone zücken soll, nur um die Raumtemperatur abzulesen :-( .
Wie gesagt, mich interessiert in erster Linie, ob es sich lohnt einen Gedanken daran zu verschwenden, die Außentemperatur auch anzuzeigen, dann könnte ich mir die bisher verstreut vorhandenen verschiedenen Innenthermometer mit jeweils einem eigenen Außensensor endlich sparen.
Aber ich fange ja erst an mich mit der Materie zu beschäftigen. Ich habe mir einfach mal einen Haufen Zeugs bestellt und schaue mal, wie das in natura aussieht.
http://www.aliexpress.com/snapshot/6205919720.html
http://www.aliexpress.com/snapshot/6205919710.html
http://www.aliexpress.com/snapshot/6205919719.html
Wobei man dann wieder schnell bei der leidigen Gehäusefrage landet.
http://www.aliexpress.com/item/86-boxes-of-high-quality-plastic-shell-DIY-LCD1602-LCD-window-can-also-be-fitted-with/1645567100.html ist ja nicht so prickelnd ... .
Wenn du es mit Batterie betreiben willst, dann würde ich dir ein eInk-Display ans Herz legen.
(http://www.seeedstudio.com/depot/images/product/einksld.jpg)
wenn dich etwas mit display interessiert schau dir mal diesen thread an: http://forum.fhem.de/index.php/topic,20956.0.html
ist leider noch nicht so weit wie der sensor von dirk aber es gibt auf software seite schon einiges. im thread sind auch screenshots und videos von der bedienung.
gruss
andre
in der bastelecke gibt es auch einen tread mit ein fhem modul für dieses epaper display. :)
gruss
andre
Ja das e-ink Display hat schon etwas. Allerdings ist es auch arg teuer. Meine jetzigen Thermometer/Wetterstation mit LCD Display halten aber mit Batterie auch gut über ein Jahr. Ich schätze mal, mit einem klassischen LCD-Display sollte der Energieverbrauch auch noch überschaubar sein. Ich werde ja sehen, wenn das Zeugs da ist und ich überhaupt soweit bin, mit der Hardware etwas vernüftiges anzustellen.
Ich bin immer noch völlig im unklaren wegen der Außentemperatur, das wäre meiner Mitbewohnerin aber sehr wichtig ;-) .
Deine Displays von unten brauche tatsächlich eine externe Spannungsversorgung.
Zitat von: cactus-online am 28 August 2014, 10:39:14
Ich schätze mal, mit einem klassischen LCD-Display sollte der Energieverbrauch auch noch überschaubar sein.
Hier braucht man aber einen MC der das auch entweder treiben kann, oder man braucht wieder eine Lösung mit Display und Controller. Da währ die E-Ink-Lösung schon sehr praktisch.
ZitatIch bin immer noch völlig im unklaren wegen der Außentemperatur, das wäre meiner Mitbewohnerin aber sehr wichtig ;-) .
Schon mal an ein Tablet gedacht, was an der Wand hängt? Da kannst du auch noch jede Menge anderer Infos anzeigen und gleichzeitig Aktionen auslösen.
Zitat von: Dirk am 28 August 2014, 10:44:15
Schon mal an ein Tablet gedacht, was an der Wand hängt? Da kannst du auch noch jede Menge anderer Infos anzeigen und gleichzeitig Aktionen auslösen.
Ja. Aber ich denke, dass meine Frau wenn sie im Schlafzimmer steht und aufs Thermometer schauen will, nicht erst eine Etage tiefer gehen möchte, weil das Display im Flur/Wohnzimmer/.. hängt vice versa ;-) .
Das Tablet ist ja schon in Vorbereitung, CCU.IO sei dank bekommt man das ja recht WAF-kompatibel hin.
ZitatJa. Aber ich denke, dass meine Frau wenn sie im Schlafzimmer steht und aufs Thermometer schauen will, nicht erst eine Etage tiefer gehen möchte, weil das Display im Flur/Wohnzimmer/.. hängt vice versa ;-) .
ich habe schon von einem schönen rosafarbenen 7-zoll tablet für 40 euro gelesen. also wenn das nicht was fürs schlafzimmer ist.
gruss frank
Zitat von: cactus-online
Das Tablet ist ja schon in Vorbereitung, CCU.IO sei dank bekommt man das ja recht WAF-kompatibel hin.
/quote]
Schreib mal wie du das genau gelöst hast, wenn du fertig bist. Suche auch noch was Sinnvolles. Ein Tablet für das Wohnzimmer / Esszimmer
Und ein paar kleinere Anzeigen in das Schlaftzimmer, Bad und an die Haustüre.
Dafür dann einen extra Beitrag im Forum :-)
Ich verstehe nicht ganz was Du meinst. Wenn Du eine CCU hast dann kannst Du Dir CCU.IO (irgendwo) installieren und eine Web-Oberfläche zusammenklicken. Beispiel wie es aussehen kann findest Du unter http://dashui.ccu.io/. Ansonsten gibt es genug Threads dazu unter http://homematic-forum.de/forum/viewforum.php?f=48 . Ist aber eben nicht FHEM.
soll eine Fhem basierende Lösung sein. Im Forum steht einiges. Trotzdem ist jede neue Idee interessant.
Hallo,
kann man bei dem Outdorsensor einen "Korrekturfaktor" für die Temperatur eingeben? Ich habe den zur Zeit im Wohnzimmer liegen. Dort sind drei andere Thermometer die alle zwischen 22,7 und 22,0 Grad anzeigen. Der Sensor zeigt aber 24,4 - geht also ca 2 Grad vor. Liegt das an dem Gehäuse ? Ich habe ein Breakoutboard mit einem SHT 10 bestellt. Kann es sein, das dann andere Werte kommen ?
Gruß Christoph
Mit dem Attribut userreadings kann man korrigieren.
Zitat von: juppzupp am 28 August 2014, 18:51:59
Mit dem Attribut userreadings kann man korrigieren.
Ich glaube Christoph ist auf eine Möglichkeit aus, den Offset bereits im Sensor zu setzen.
Ist auch das Einzige, was Sinn macht. Denn wenn du zB den Sensor mit einem RT peeren willst, ist es zwar nett, dass FHEM weiß, wie warm es wirklich ist, dir aber nicht viel bringt, wenn Thermostat ständig glaubt, es ist zwei Grad wärmer und deshalb das Ventil zu lässt. ;-)
Zitat von: Bennemannc am 28 August 2014, 18:39:29
kann man bei dem Outdorsensor einen "Korrekturfaktor" für die Temperatur eingeben?
Ist mWn bislang noch nicht umgesetzt. Aber ist keine schlechte Idee. :-)
Hallo,
userReadings ist klar, aber dann muss ich auch die regexp für das Logging ändern. Ich glaube ich warte mal auf das Breakoutboard. Dirk sagte, dass dann die Temperatur vom SHT10 kommt und nicht mehr vom Luftdrucksensor. Vielleicht ist das ja genauer.
Gruß Christoph
Der Temperatursensor im BMP180 ist tatsächlich nicht so genau. Das Datenblatt sagt was von bis zu +/- 2°C
Der SHT ist mit +/- 0,5 °C deutlich genauer.
Edit: Wobei das auch nur bei Zimmertemperatur gilt. Genauer kann man das im Datenblatt nachlesen:
http://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/Humidity/Sensirion_Humidity_SHT1x_Datasheet_V5.pdf
Gruß
Dirk
Wobei die sht das auch nur unter Laborbedingungen schaffen.
Temperatur messen ist (in dem preislichen Bereich in dem wir uns bewegen) eh als relativ zu verstehen.
Hallo,
ok - ich habe ja auch jetzt einen Drift von 0,7 Grad, wobei zwei die Gleiche Temperatur anzeigen. Das eine ist ein HM Temperaturanzeige und das andere ein Oregon Thermometer. Die 22,0 Grad zeigt der RD an der Heizung.
Also werde ich auf den SHT10 warten.
Was macht Ihr eigentlich bei dem Outdoor Gehäuse, wenn auch die Luftfeuchtigkeit gemessen werden soll? Unten Löcher reinmachen oder den Sensor nach außen verlagern? Ich wollte das Teil eigentlich ziemlich Regengeschützt unter dem Dachüberstand montieren und dann Löcher reinmachen.
Gruß Christoph
Der BMP reagiert empfindlich auf Lichteinstrahlung , lag der bei der höheren Abweichung evtl in der Sonne(auch indoor)?
Hallo Juppzupp,
ne - Du meinst dir 33 Grad von heute Mittag ;). Die passten auch nicht, aber das war wohl ein Wärmestau im Gehäuse weil das Teil in der Sonne lag 8). Im Moment liegt das Teil auf dem Couchtisch, hier dämmert es bereits und der Himmel ist bedeckt. Also daher kann die Abweichung nicht kommen.
Gruß Christoph
Zitat von: Bennemannc am 28 August 2014, 19:40:14
Was macht Ihr eigentlich bei dem Outdoor Gehäuse, wenn auch die Luftfeuchtigkeit gemessen werden soll? Unten Löcher reinmachen oder den Sensor nach außen verlagern? Ich wollte das Teil eigentlich ziemlich Regengeschützt unter dem Dachüberstand montieren und dann Löcher reinmachen.
Ich hab mich für draußen auch für ein Indoor-Gehäuse entschieden. Denn auf der einen Seite konnte ich es so wie du regengeschützt unterbringen und zum Anderen ist es um einiges besser belüftet, wodurch sich Feuchtigkeit nicht länger hält, als es wetterbedingt ohnehin ist (die S300TH hatten auch kein extra abgedichtetes Gehäuse und haben sowohl In- als auch Outdoor bis zum Schluss problemlos funktioniert).
Beim Outdoor-Gehäuse hingegen kommt zwar die Feuchtigkeit irgendwann mal rein, aber ich hatte die Befürchtung, dass diese dann nicht mehr so toll raus geht (zumindest, wenn man nur ein Loch an der Unterseite hätte) und das wäre mMn etwas kontraproduktiv. Also wenn, dann den Sensor irgendwie nach außen führen und das Gehäuse ordentlich abdichten.
Hallo,
also ein Loch ist mit Sicherheit nicht genug. Was sollte passieren ? Wenn es gut belüftet ist, bildet sich auch keine Kondenz. Ich überlege gerade, ob man die Leiterbahnen und Kontakte nicht leicht mit Klarlack behandeln sollte damit hohe Luftfeuchtigkeit keine Probleme verursacht.
Gruß Christoph
Tauch alles bis auf den Sensor in plastidip. Tolles zeug!
Hallo,
das wird schwierig, da der Luftdrucksensor auf dem Board ist genauso wie der Lichtsensor.
Gruß Christoph
Vorher abkleben. Habe ich mit nem ähnlichem sensorboard gemacht, läuft seit 360 tagen ohne Probleme. (Draussen)
Kleiner Themenwechsel:
Da der untere Grenzwert für die Batterie (zur Zeit noch) nicht als Register konfigurierbar ist, habe ich mich auf die Suche nach entsprechendem Wert im Code gemacht und bin dabei auf die 22 gestoßen. Ohne es mir näher angesehen zu haben, nehme ich einmal an, dass damit 2,2V gemeint sind.
Wenn ich mich richtig erinnere, sollten die mit dem MAX1724 ausgestatteten Sensoren noch zumindest bis 1,6V recht zuverlässig ihren Dienst verrichten.
Daher die beiden Fragen:
1) wäre es aufwändig, den Wert als Register konfigurierbar zu machen und
2) wenn meine Annahme stimmt und ich BATTERY_MIN_VOLTAGE vor dem kompilieren auf 16 umstelle, kommt dann ab 1,6 oder ab 1,5V die Battery low Warnung?
Thx a lot! :-)
ZitatOhne es mir näher angesehen zu haben, nehme ich einmal an, dass damit 2,2V gemeint sind.
#define BATTERY_MIN_VOLTAGE 22Korrekt, das sind 2,2 V
ZitatWenn ich mich richtig erinnere, sollten die mit dem MAX1724 ausgestatteten Sensoren noch zumindest bis 1,6V recht zuverlässig ihren Dienst verrichten.
1,4 V sollten hier auch noch sicher Laufen. Daher könnte man mit dem Max den LowBat-Schwellwert auf 1,6V setzen. Vielleicht sogar auf 1,5.
Zitatwäre es aufwändig, den Wert als Register konfigurierbar zu machen und
Ich vermute das ist relativ. Wenn man das einmal gemacht hat geht's schnell. :)
Das wollte ich mir demnächst aber auch noch vornehmen.
Zitat von: Dirk am 28 August 2014, 22:56:44
Das wollte ich mir demnächst aber auch noch vornehmen.
Warum wundert mich das bei dir nicht? *thumbsUp* :-)
Bin schon gespannt, wie hoch der Batterieverbrauch in dem Sensor ist. Musste beim Umstellen von den alten S300TH auf die Neuen ganz verwundert feststellen, dass die Batterien nach zumindest 20 Monaten Laufzeit (Indoor) immer noch knapp 2,6V anzubieten hatten.
Da der Sensor nicht nur stur sendet, wird der Verbrauch vermutlich höher sein... Dennoch bin ich sehr gespannt, wie er sich macht. :-)
ZitatBin schon gespannt, wie hoch der Batterieverbrauch in dem Sensor ist.
Hier hab ich noch nicht alles machbare in der Firmware ausgeschöpft. Da muss ich auch noch mal ran. Das wird auch als nächstes kommen.
Ich lasse zur Zeit Vergleichmessungen laufen. Dabei stellt sich heraus, dass ein im Gehäuse des Außensensors befindliches Berakout-Modul in Bezug auf den Feuchtewert wohl nur sinnvoll zu verwenden ist, wenn dort riesige Löcher gebohrt werden (ich habe nur ein kleines ca. 1mm Loch wegen der Luftdruckmessung). Der direkt daneben angebrachte Innensensor zeigt deutlich mehr Volantilität bei der Luftfeuchtigkeit.
Eine Veränderung in Bezug auf den Temperaturwert durch das Breakoutmodul würde ich eher nicht erwarten. Hier zeigen bei mir der Außensensor mit Breakoutmodul und der Innensensor fast den gleichen Wert an. Was auch zu erwarten ist, da in meinem Fall beide den gleichen Temp/Feuchtesensor verwenden. Allerdings kann ich sagen (nur nicht mehr grafisch belegen), dass auch bei einem Vergleich zwischen Außensensor ohne Breakoutmodul und Innensensor die Temperaturwerte nahezu identisch waren. Die Abweichungen resultieren aus einer geringfügig anderen Ausrichtung zur Sonne.
Ein externer anderer Sensor bei irgendeinem meiner Nachbarn zeigt, dass die Werte auch absolut betrachtet wohl ziemlich OK sind. Das bestätigt auch die Vergleichmessung zwischen Innensensor und Temperaturwert des HM-CC-RT-DN Heizkörperthermostat.
Hallo,
ich hatte auch nicht an ein Loch 1mm gedacht sondern an 5Stück 3mm oder so an der Unterseite. Das mit den Temperaturen ist schon klar, aber bei mir misst ja derzeit der Luftdrucksensor die Temperatur mit und der hat (laut Datenblatt s.O.) eine größere Tolleranz wie der TH Sensor.
Gruß Christoph
Bei mir war die Abweichung bei der Messung mittels Lufdrucksensor eben auch vernachlässigbar und nicht in der oben angegeben Größenordnung.
Hallo Dirk
Kannst du mir mal den Hersteller bzw. Typ deines Aussengehäuses mit klarem Deckel nennen ?
Gruss Peter
Bin zwar nicht Dirk ;)
es aber könnte dieses sein:
http://www.tme.eu/de/details/g201c/universal-gehaeuse/gainta/#
Zitat von: hexenmeister am 30 August 2014, 14:23:21
es aber könnte dieses sein:
Das ist korrekt. Oder hier ist das auch erhältlich:
http://www.elv.de/industrie-aufputz-gehaeuse-ip65-modell-g201c.html
Gruß
Dirk
Hi,
habe soeben meine Sensoren erhalten und in Betrieb genommen.
ein paar kleine Anmerkungen:
- ist das device nicht gepairt sendet es nach "ffffff". Es sollte nach Broadcast senden, das ist "000000"
- register burstRx hat den Wert "255" (der 0xff). Wenn es eingeschaltet ist sollte es 0x01 sein - so ist es "üblich"
- batVoltage sollte m.E. nicht im State sein - ok, kann man einstellen... aber in state ist per default der "main-state" des device - das ist nicht Batterie
- das device ist demnach als conditionalBurst konzipiert. Demnach sollte man auch das Kommando burstXmit zulassen.
wird das Wiki noch ausgebaut? z.B. der Umgang mit der Helligkeit. HM gibt bei Helligkeitswerten immer einen Wert in % an - 0.5% stufen, also werte von 0 bis 200. Steht sicher etwas im Threat, werde einmal suchen. sollte aber in das Wiki
ansonsten alles prima - gute Arbeit, danke
Martin
Hallo Martin,
danke für das Feedback.
Zitat- ist das device nicht gepairt sendet es nach "ffffff". Es sollte nach Broadcast senden, das ist "000000"
So ist es in der Lib eigentlich auch definiert. muss ich mir mal ansehen und ggf. fixen.
Zitat- batVoltage sollte m.E. nicht im State sein - ok, kann man einstellen... aber in state ist per default der "main-state" des device - das ist nicht Batterie
Da hast du recht. Eigentlich var die Batteriespannung auch nur zum debuggen. Das sollte man ggf. wieder ausbauen.
Ansonsten wo würdest du das unterbringen?
Zitatwird das Wiki noch ausgebaut?
Definitiv.
ZitatHM gibt bei Helligkeitswerten immer einen Wert in % an - 0.5% stufen, also werte von 0 bis 200.
Der Sensor liefert die Werte in Lux. Also keine Helligkeit in %. Allerdings nur im Außengehäuse. Mit Filterfolie nur noch etwa 26% davon.
Gruß
Dirk
Zitat von: Dirk am 30 August 2014, 23:47:38
Da hast du recht. Eigentlich var die Batteriespannung auch nur zum debuggen. Das sollte man ggf. wieder ausbauen.
Ansonsten wo würdest du das unterbringen?
Am besten analog zu den RTs. Also als eigenes batteryLevel-Reading. :-)
Edit:
Würdest du es noch über ein Register konfigurierbar machen, ob die LED bei der Übertragung aufblinken soll? Könnte mir vorstellen, dass sich damit der Energieverbrauch langfristig auch noch etwas verringern lässt (und so ganz nebenbei würde es auch verhindern, dass meine Frau in der Nacht immer wieder erschrickt, weil an der Oberseite des Gehäuses etwas heraus blitzt). :-)
Thx a lot!
Anmerkungen zum Code
- im unpack werden die letzten beiden A8 nicht gebraucht
- der channelstate sollte (default) das gleiche beinhalten, wie der device state, daher erst am Ende schreiben
- battery-level nicht in state
- luminocity berechnung nur, wenn der wert gültig ist
- burstXmit erlauben
=> geht burst wirklich?
Anmerkungen zur FW:
- ein Sensor sendet seine Nachrichten nicht die Zentrale sondern als broadcast. Daher sind die Flags anders zusetzen:
Anstelle von
A270 F82D96 1743BF 00A8570000006400C80BEE
ist ein
8470 F82D96 000000 00A8570000006400C80BEE
oder
8670 F82D96 000000 00A8570000006400C80BEE
üblich. Das bedeutet:
- an alle meine Freunde (broadcast oder multicast ... weiß nicht genau)
- sende kein ACK bei regelmäßigen Infos - das reduziert die messagelast des IO erheblich
Zitat von: Dirk am 28 August 2014, 09:22:29
Dafür muss man wohl ein neuen Gerätetyp bauen. Ich würde die Daten aber nicht von der CCU beziehen, sondern das Teil mit einem weiteren Sensor peeren von dem es die Temperatur bezieht.
Gruß
Dirk
OK. Ich werde das wohl erst verstehen, wenn ich mehr selbst "gebastelt/probiert/programmiert" haben. Grundsätzlich scheint es also aber eine Möglichkeit zu geben. Die FW müsste entweder die Info irgendwie von der CCU bekommen (wohl eher schwierig) oder vom Außensensor ? Dazu bräuchte die FW aber die Möglichkeit mit einem Außensensor zu peeren ? Oder ist die vorstehende Info (http://forum.fhem.de/index.php/topic,20620.msg196064.html#msg196064) so zu verstehen, dass der Sensor ohnehin alles für jeden in die Welt pustet und die FW nur noch wissen muss, wem sie eigentlich zuhören muss ?
btw: Batteriespannung finde ich nicht nur zu Debug-Zwecken wichtig.
Hallo Dirk und hexenmeister
Danke für die Gehäuseinfos ;D
Gruss Peter
ich habe eine Frage zu der Helligkeitsanzeige, diese erscheint bei mir gar nicht. Sicher muss ich in den Attributen das richtige "model" angeben, aber das wäre dann nicht der HM_WDS10_TH_O, genauso das "subtype".
Das muss von Hand eingestellt werden, oder wie mache ich das..? In den Readings erscheint nichts mit "luminosity"
Welche Attribute sollten überhaupt vorhanden sein..?
Zitat von: moonsorrox am 31 August 2014, 16:25:54
ich habe eine Frage zu der Helligkeitsanzeige, diese erscheint bei mir gar nicht.
Bei allen Sensoren?
Kannst du mal einen Screen von den Readings posten. Ggf. auch mal die Ausgabe vom Eventmonitor.
Zitat von: Dirk am 31 August 2014, 18:08:13
Bei allen Sensoren?
ich habe nur den einen für innen und den Aussensensor probiert, den 3. mache ich noch
Hier mal die Screens wobei der Innensensor für das Wohnzimmer mir seit 15.55 Uhr gar nichts mehr schickt..! 8)
Hast du das Device manuell angelegt?
Bei dir fehlt auch batVoltage
Und Model ist auch nicht gesetzt. Da sollte HB-UW-Sen-THPL-I oder HB-UW-Sen-THPL-O gesetzt sein.
Lösche das Device noch mal und lasse es nochmal per Autocreate anlegen.
nein nicht manuell, alles per autocreate... habe jetzt den dritten so gelassen - also die Bezeichnungen - und auch per autocreate anlegen lassen.
Er hat mir model "HB-UW-Sen-THPL-I" nicht angelegt, wenn ich manuell danach suche gibt es dieses auch nicht nicht...!
hier mal die screens
Ich glaube die HMConfig_SenTHPL.pm wird bei dir nicht geladen.
Die Datei befindet sich auch im FHEM-Verzeichniss. Zugriffsrechte sind auch korrekt?
Zitat von: Dirk am 31 August 2014, 19:26:23
Ich glaube die HMConfig_SenTHPL.pm wird bei dir nicht geladen.
wo sollte die genau liegen in fhem oder FHEM
Zitat von: Dirk am 31 August 2014, 19:26:23
Die Datei befindet sich auch im FHEM-Verzeichniss. Zugriffsrechte sind auch korrekt?
ja das ganze /opt Verzeichnis ist hat Besitzer fhem Gruppe dialout
Zitat von: moonsorrox am 31 August 2014, 19:40:39
wo sollte die genau liegen in fhem oder FHEMja das ganze /opt Verzeichnis ist hat Besitzer fhem Gruppe dialout
Direkt in FHEM. dort wo z.B. auch 00_CUL.pm liegt.
nee, gibt es nicht... verstehe ich nicht... mache immer brav die Updates, da sollte es doch bei sein oder nicht.?
Doch, 00_CUL.pm muss es geben.
Schau mal in /opt/fhem/FHEM. Dort muss es eine 00_CUL.pm geben und hier gehört auch HMConfig_SenTHPL.pm rein.
00_CUL.pm ist da aber die andere nicht
Zitat von: moonsorrox am 31 August 2014, 19:52:41
00_CUL.pm ist da aber die andere nicht
Dann HMConfig_SenTHPL.pm hier her kopieren und FHEM neu starten.
Dann sollte es funktionieren.
Die Sensoren dann aber nochmal löschen und neu anlernen.
grad nochmal ein Update gemacht aber die ist nicht dabei, woher bekomme ich die dann.?
schau mal den screen
Die kommt hier her:
https://github.com/kc-GitHub/Wettersensor/raw/master/Tools/FHEM/HMConfig_SenTHPL.pm
Ich werde die Tage aber die Installationsanleitung noch ins Wiki mit aufnehmen.
Das ist im Tread hier recht unübersichtlich.
OK, denn da habe ich schon geschaut aber da steht ja nichts mit der Installation.
Frage noch zum anlernen nur kurz drücken, weil bei anderen Homematic Geräten ist immer 3sec.
Ich bekomme nämlich grad keine mit autocreate, habe alles wieder rausgelöscht, aber kein Code... naja ich probiere nachher nochmal, habe erst mal die Schnauze voll ;)
ZitatFrage noch zum anlernen nur kurz drücken, weil bei anderen Homematic Geräten ist immer 3sec.
Ja, Da der Taster ausschließlich für die Konfiguration ist, muss man nur kurz drücken.
Nach dem Drücken blinkt die LED kurz. Dann ist der Sensor im Config-Mode.
hmPairForSec muss zuerst gestartet werden. Dann die Taste drücken.
Zitat von: Dirk am 31 August 2014, 20:12:18
hmPairForSec muss zuerst gestartet werden. Dann die Taste drücken.
is klar...
Ich habe jetzt mal beide Innensensoren angelernt er gibt mir bei einem aber nur dieses
define CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 CUL_HM 8FB1E9
attr CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 IODev HMUSB
attr CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 actCycle 000:10
attr CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 actStatus alive
attr CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 autoReadReg 4_reqStatus
attr CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 firmware 0.11
attr CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 model HB-UW-Sen-THPL-I
attr CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 room CUL_HM
attr CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 serialNr UWS8059465
attr CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 subType THPLSensor
define FileLog_CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 FileLog ./log/CUL_HM_HB_UW_Sen_THPL_I_8FB1E9-%Y.log CUL_HM_HB_UW_Sen_THPL_I_8FB1E9
attr FileLog_CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 logtype text
attr FileLog_CUL_HM_HB_UW_Sen_THPL_I_8FB1E9 room CUL_HMder andere hat nur dieses gegeben:
define CUL_HM_HB_UW_Sen_THPL_I_E742C9 CUL_HM E742C9
attr CUL_HM_HB_UW_Sen_THPL_I_E742C9 room CUL_HM
define FileLog_CUL_HM_HB_UW_Sen_THPL_I_E742C9 FileLog ./log/CUL_HM_HB_UW_Sen_THPL_I_E742C9-%Y.log CUL_HM_HB_UW_Sen_THPL_I_E742C9
attr FileLog_CUL_HM_HB_UW_Sen_THPL_I_E742C9 logtype text
attr FileLog_CUL_HM_HB_UW_Sen_THPL_I_E742C9 room CUL_HMwarum so unterschiedlich, ich meine ich kann das ja beim zweiten so eintragen, aber sollte eigentlich gleich sein bis auf die CUL_HM xxxxxx
Der Erste sieht gut aus.
So wie es aussieht war der zweite aber nicht nicht gelöscht.
OK... 8)
habe echt alles raus gelöscht... weg mit dem Schmutz :P
egal mache ich nochmal...! 8)
tja zu mehr wie dazu kann ich den Außensensor nicht überreden:
Hab das mehrmals probiert, keine Chance... screenshot ist dabei was an Readings kommt
bekomme auch keine Logeinträge, evtl. sind die Sensoren zu weit weg vom HMUSB sodass nichts ankommt...
war wohl so, ich hatte die oben in der 1. Etage hier am PC damit ich den Aussensensor beobachten kann, dass war wohl zu weit weg...! Jetzt kommen die Werte...!
Na da bin ich mal gespannt ob der Weg draußen nicht zu weit weg ist, wo ich den platzieren möchte ::)
define CUL_HM_HB_UW_Sen_THPL_O_EAD5C7 CUL_HM EAD5C7
attr CUL_HM_HB_UW_Sen_THPL_O_EAD5C7 room CUL_HM
define FileLog_CUL_HM_HB_UW_Sen_THPL_O_EAD5C7 FileLog ./log/CUL_HM_HB_UW_Sen_THPL_O_EAD5C7-%Y.log CUL_HM_HB_UW_Sen_THPL_O_EAD5C7
attr FileLog_CUL_HM_HB_UW_Sen_THPL_O_EAD5C7 logtype text
attr FileLog_CUL_HM_HB_UW_Sen_THPL_O_EAD5C7 room CUL_HM
Hallo,
hast Du mit Lichtsensor bestellt ? Dann fehlen die Werte. Der Luftdrucksensor macht nur Temperatur. Für Temperatur und Feuchtigkeit wird eine Breakoutboard mit SHT10 benötigt. Das kann man nachordern und auflöten (warte derzeit auf die Lieferung).
Gruß Christoph
Zitat von: Bennemannc am 01 September 2014, 06:58:43
hast Du mit Lichtsensor bestellt ? Dann fehlen die Werte.
ja habe ich, dass Problem welches ich meinte ist das sobald ich das Teil anlege fehlt da einiges, es wird nur ein zweizeiliges define angelegt so wie weiter oben gezeigt.
Da ich von meinem einen Innensensor aber weiß wie es aussehen soll, lege ich die fehlenden Attribute von Hand an, dann wird mir auch alles angezeigt.
Aber ich kann den Sensor nicht dazu überreden, alles durch Autocreate anzulegen, ich habe das Spiel bestimmt 5 mal hinter mir, genauso der zweite Innensensor den bekomme ich nicht erstellt, es kommt auch nur ein zweizeiliges define plus Filelog.
Trage ich dann die attr dazu geht ja alles, er zeigt mir bis jetzt alles an auch die "luminosity"
Werde das heute nochmals machen...!
Ich habe das Wiki um die Maße des Lochs für den Acrylstab für das Innengehäuse erweitert:
http://www.fhemwiki.de/wiki/Universalsensor#Der_Helligkeitssensor
ZitatDer Helligkeitssensor braucht zum sinnvollen Einsatz natürlich die Möglichkeit vom Umgebungslicht beleuchtet zu werden. Da der Sensor im Innengehäuse nahe der Lüftungsschlitzen sitzt, wird dieser dadurch bereits beleuchtet. Allerdings fällt hier nur wenig Licht auf den Sensor. Daher ist bei dieser Messmethode die erreichbare Auflösung sehr gering.
Die bessere Möglichkeit ist es, in die Abdeckung des Sensorgehäuses ein 5 mm großes Loch zu bohren. In das Loch wird dann ein kurzer Stift aus Acrylglas eingesetzt. Siehe Bild mit der Bohrvorlage. Achtung, das Loch ist in horizontaler Ausrichtung nicht genau mittig. Der Acrylstab hat nicht genau 5 mm Durchmesser. Es sind 5,2 mm. Man kann dennoch ein 5 mm Loch bohren. Das Einschieben des Stabes in das Loch geht dann allerdings ziemlich schwer. Vor dem Einschieben kann man den Acrylstab an der Innenseite noch leicht anfasen. Dann lässt er sich leichter in das Loch schieben. Die Länge des Acrylstabes Beträgt 17 mm.
Wo bekomme ich so einen Acrylstab her? Online??
Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk
Wo bekomme ich so einen Acrylstab her? Online??
Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk
Wo bekomme ich so einen Acrylstab her? Online??
Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk
Hallo,
also ich nutze für so etwas einen Schleuderstab aus Acryl. Nicht lachen, der heißt offiziell wirklich so. Das ist eine Stange, um die Gardine zur Seite zu schieben - gibt es in Baumärkten. Die haben zwar oft 6 oder 8 mm, das kann man aber auf 5 mm herunterfeilen damit es in den Deckel passt. Wie dick der unten ist, ist ja egal.
Gruß Christoph
Zitat von: Tobias am 01 September 2014, 19:08:05
Wo bekomme ich so einen Acrylstab her? Online??
Ja. Such mal bei "Ibäh" nach "Acrylglas / PLEXIGLAS® Rundstab"
Ansonsten packe ich bei allen Sensoren mit Helligkeitssensor und dem Innengehäuse einen mit dazu.
irgendwie gibt es einige Probleme mit dem einen Innensensor (den anderen habe ich noch nicht in Betrieb), seit heute Nacht zeigt er dieses
Alle Einträge aus dem Log.
2014-09-02_00:37:19 Temperatur_Wohnzimmer Activity: unknown
2014-09-02_00:36:05 Temperatur_Wohnzimmer Activity: dead
Nun habe ich mal die Batterien raus genommen und wieder eingesetzt, dann kommt folgendes:
2014-09-03_19:06:04 Temperatur_Wohnzimmer Activity: dead
hat der sich jetzt verabschiedet..?
letzte intakte Meldung war:
2014-09-02_00:22:10 Temperatur_Wohnzimmer T: 23.2 H: 56 L: 0.01 batVoltage: 3.01
Zitat von: moonsorrox am 03 September 2014, 19:13:08
Nun habe ich mal die Batterien raus genommen und wieder eingesetzt, dann kommt folgendes:
Blinkt die LED nach dem Batteriewechsel?
Wenn nicht: Batterie rausnehmen. Config-Taste drücken (damit sich die Kondensatoren entladen) , Batterie einsetzen.
Blinkte es dann? Und wie?
ja sie blinkt..! Neue Batterien aber keine Erregung, ich schaue mal die Blinkfolge..!
Also 3x kurz und kurze Pause und dann mehrmals hintereinander. Ich glaube 6x
Aber es kommt nichts an weder im Log noch im Eventmonitor noch in der Anzeige..!
Beim Starten des Sensors Blint die LED normalerweise so:
- 1 x kurz (bootloader)
- kuze pause
- 3 x kurz (Sendor ist gestartet)
Bei jeder Übertragung blinkt die LED einmal (anschließend noch einmal kurz wenn das Teil ein ACK bekommen hat. Ohne ACK blinkt die LED lang
Wird die übertragung bis zu 5 mal wiederholt wenn kein ACK empfangen wurde.
Das Senden findet ca. alle 2,5 - 3 Minuten statt.
Kannst das ja mal beobachten.
ja OK das erste mal kurz hatte ich übersehen
also
1x kurz Pause dann 3x ist richtig bei mir also
dann noch 6x
das senden ca. alle 3min kommt auch... da macht er dann kurz hintereinander 5x und noch 1x nach ganz kurzer Pause
Defekt ist er dann nicht...! Aber warum ging der jetzt 2, fast 3 Tage und nun nicht mehr..?
Zitatda macht er dann kurz hintereinander 5x und noch 1x nach ganz kurzer Pause
War der Sensor mit FHEM gepairt?
Ansonsten versuch das noch mal. Configtaste drücken. Dann müsste die LED auch schnell blinken.
Vorher das HM-Device in FHEM auf HMPairForSec <x> stellen.
ZitatAber warum ging der jetzt 2, fast 3 Tage und nun nicht mehr.?
Das ist eine gute Frage. Ich will aber nicht ausschließen das in der Firmware nicht noch ein Bug währ.
Zitat von: Dirk am 03 September 2014, 19:41:38
War der Sensor mit FHEM gepairt?
ja klar er lief ja auch und zeigte alles an, wunderte mich nur vorhin das er bei L: 0.01 angezeigt hat.
Zitat von: Dirk am 03 September 2014, 19:41:38
Ansonsten versuch das noch mal. Configtaste drücken. Dann müsste die LED auch schnell blinken.
Vorher das HM-Device in FHEM auf HMPairForSec <x> stellen.
Das ist eine gute Frage. Ich will aber nicht ausschließen das in der Firmware nicht noch ein Bug währ.
mache das mal... Ok das Teil blinkt 8)
Habe ihn jetzt nochmals wieder gepairt, aber wie auch schon vor einigen Tagen kommen nur zwei Zeilen...!
Aber den Rest hatte ich ja
Hier nun die Logauszüge aktuell: mal schauen wie lange der jetzt geht...!
2014-09-03_19:49:00 Temperatur_Wohnzimmer Activity: alive
2014-09-03_19:47:42 Temperatur_Wohnzimmer Activity: alive
2014-09-03_19:47:38 Temperatur_Wohnzimmer T: 25.0 H: 46 L: 7.97 batVoltage: 3.07
2014-09-03_19:47:38 Temperatur_Wohnzimmer batVoltage: 3.07
2014-09-03_19:47:38 Temperatur_Wohnzimmer luminosity: 7.97
2014-09-03_19:47:38 Temperatur_Wohnzimmer humidity: 46
2014-09-03_19:47:38 Temperatur_Wohnzimmer battery: ok
2014-09-03_19:47:38 Temperatur_Wohnzimmer temperature: 25.0
Ja, beobachte das mal.
Mir fällt aber grade nicht ein was das gewesen sein könnte.
Zitat von: Dirk am 03 September 2014, 19:58:07
Ja, beobachte das mal.
werde ich machen, morgen probiere ich mal den zweiten Innensensor mal schauen was der macht
Irgendwie ist das wie verhext, heute morgen nun steigt der Aussen Sensor aus und meldet sich nicht mehr. Was er meldet ist aber noch Activity...
Hier mal die letzten Logeinträge...
2014-09-04_14:28:55 Aussensensor_Terrasse Activity: unknown
2014-09-04_14:27:30 Aussensensor_Terrasse Activity: unknown
2014-09-04_14:11:10 Aussensensor_Terrasse Activity: unknown
2014-09-04_07:54:41 Aussensensor_Terrasse Activity: dead
2014-09-04_07:36:32 Aussensensor_Terrasse T: 13.4 L: 120 P: 1018 P-NN: 1046 batVoltage: 2.86
2014-09-04_07:36:32 Aussensensor_Terrasse batVoltage: 2.86
2014-09-04_07:36:32 Aussensensor_Terrasse pressure-nn: 1046
2014-09-04_07:36:32 Aussensensor_Terrasse pressure: 1018
2014-09-04_07:36:32 Aussensensor_Terrasse luminosity: 120
2014-09-04_07:36:32 Aussensensor_Terrasse battery: ok
Der Wohnzimmer Sensor von gestern der rumgezickt hat geht bisher, ist ja auch noch nicht so lange, dass letzte mal waren es 3 Tage...
Den zweiten Innensensor bekomme ich überhaupt nicht mehr dazu in Fhem zu pairen...! Es erscheint nichts an Code...
Welche Möglichkeit habe ich, diese noch einmal komplett aus Fhem raus zunehmen, ich meine jetzt nicht die define die kann ich ich raus löschen... Ich meine den Sensor abzulernen oder zurück zu setzen...
So das ich nochmal von Null anfange....?
Hallo,
beim pairen habe ich auch zwei Versuche gebraucht. Aber dann lief alles. Ein Reset der Sensoren sollte Homematic like gehen. Also in den Config Mode und während des blinkens lange drücken.
Ich habe eine Außensensor (eine Woche alt) und einen Innensensor (heute bekommen) - bis auf das Anlernen (das kannte ich ja schon vom erste) keine Probleme. Der Außensensor hat auch keinerlei Aussetzer - das würde ich im Log sehen und da ist nichts.
Welche RSSI Werte hast Du den zu den Sendern ?
Gruß Christoph
Zitat von: Bennemannc am 04 September 2014, 14:58:33
beim pairen habe ich auch zwei Versuche gebraucht. Aber dann lief alles. Ein Reset der Sensoren sollte Homematic like gehen. Also in den Config Mode und während des blinkens lange drücken.
das werde ich mal machen...
also ich habe da wirklich schon einige Zeit verbracht, oft kommt gar nichts beim pairen und wenn dann nur zwei Zeilen Code... Habe gerade wieder den zweiten Innensensor, nach dreimaligem anlernen dazu gebracht das er mir überhaupt Code bringt... Es kommen aber wieder nur zwei Zeilen und die Logzeilen...
Zitat von: Bennemannc am 04 September 2014, 14:58:33
Welche RSSI Werte hast Du den zu den Sendern ?
du meinst die Readings..? diese bekomme ich aber eben von heute morgen die letzten
Activity unknown 2014-09-04 14:54:37
batVoltage 2.86 2014-09-04 07:36:32
battery ok 2014-09-04 07:36:32
luminosity 120 2014-09-04 07:36:32
pressure 1018 2014-09-04 07:36:32
pressure-nn 1046 2014-09-04 07:36:32
state T: 13.4 L: 120 P: 1018 P-NN: 1046 batVoltage: 2.86 2014-09-04 07:36:32
temperature 13.4 2014-09-04 07:36:32
Hallo,
der RSSI Wert steht bei Internals - also darüber. Er sagt aus, wie gut das Signal bzw. die Verständigung ist. Er wird immer in -Werten angegeben, je kleiner desto besser.
Ich habe zwischendurch auch mit pairSerial - also über die Seriennummer gemacht. Einmal hat er das hinbekommen, beim Innensensor klappe danach das pairForSec sofort. Ich würde da mal abwechselnd testen.
Gruß Christoph
je größer um so besser :)
gruss
andre
Zitat von: moonsorrox am 04 September 2014, 14:46:10
Was er meldet ist aber noch Activity...
Die Activity-Meldungen kommen vom FHEM nicht vom Sensor.
ZitatDen zweiten Innensensor bekomme ich überhaupt nicht mehr dazu in Fhem zu pairen...! Es erscheint nichts an Code...
Die Led Blinkt aber wenn du die Config-Taste drückst?
ZitatWelche Möglichkeit habe ich, diese noch einmal komplett aus Fhem raus zunehmen
- Den Sensor in FHEM löschen.
- Den Sensor zurück setzen.
Dazu einmal die Config-Taste drücken. Dann sollte die Led blinken. Jetzt die Config-Taste so lange drücken bis die Led schnell blinkt, dann loslassen.
Während die Led schnell blinkt noch einmal die Config-Taste lange drücken bis die LED aus geht. Dann sollte der Sensor intern den EEprom zurück setzen.
Ich glaube aber das da noch irgendwo anders ein Problem ist. Was mich vor allem noch wundert, dass bei dir der Anlernvorgang nicht automatisch die richtigen Einstellungen anlegt.
Was für ein Interface benutzt du denn?
Zitat von: Bennemannc am 04 September 2014, 15:21:11
Ich habe zwischendurch auch mit pairSerial
Soweit ich mich erinnere habe ich pairSerial gar nicht im Sensor implementiert :)
Gruß
Dirk
Zitat von: Bennemannc am 04 September 2014, 15:21:11
der RSSI Wert steht bei Internals - also darüber. Er sagt aus, wie gut das Signal bzw. die Verständigung ist. Er wird immer in -Werten angegeben, je kleiner desto besser.
Ok das kannte ich noch nicht, Danke :)
Also der Aussensensor der jetzt ausgestiegen ist hat den Wert nicht, wohl weil er weg ist...
Im Vergleich dazu:
1. Innensensor: HMUSB_RSSI -57 (der ist ca. 3m vor dem Aussensensor positioniert, also näher am HMUSB)
Der andere den ich ich heute versucht hab vergebens anzulernen, bis dann doch zwei Zeilen kamen
2. Innensensor: HMUSB_RSSI -74 (den habe ich im ersten Stock liegen)
Der hat mir kein Seriennr. und kein Typ usw. geliefert beim pairen, das habe ich von Hand eingetragen und jetzt sendet er auch, aber es fehlt eben die Sr Nr. und die Firmware.
Deshalb wollte ich diese nochmal komplett ablernen.
Zitat von: Bennemannc am 04 September 2014, 15:21:11
Ich habe zwischendurch auch mit pairSerial - also über die Seriennummer gemacht. Einmal hat er das hinbekommen, beim Innensensor klappe danach das pairForSec sofort. Ich würde da mal abwechselnd testen.
tja das geht ja nicht ohne Seriennummer.. aber ich hole den mal rein, schraube ihn auf und paire ihn nochmal bleibt mir ja keine andere Möglichkeit
Zitat von: Dirk am 04 September 2014, 15:33:29
Die Activity-Meldungen kommen vom FHEM nicht vom Sensor.
das dachte ich mir... ;)
Zitat von: Dirk am 04 September 2014, 15:33:29
Die Led Blinkt aber wenn du die Config-Taste drückst?
ja geht alles er ist ja jetzt da und sendet auch, aber ich werde das nochmal machen weil ja nur 2 Zeilen Code kommen.
Zitat von: Dirk am 04 September 2014, 15:33:29
Was für ein Interface benutzt du denn?
USB Adapter...
Werde jetzt nochmals den zweiten Innensensor komplett zurück setzen und nochmal machen.. mal schauen ob er dann den kompletten Code bringt..!
Edit:// nach komplett Reset wieder nur zwei Zeilen Code einschl. Log.
Bin auch extra in die Nähe des USB Adapter gegangen zum anlernen. RSSI -66
Den Aussensensor werde ich erst einmal rein holen, denn den muss ich ja aufschrauben...! Der hat es also ca. 2 Tage gemacht und nun ausgestiegen...
Entfernung zum USB Adapter ist ca. 9m mit einer dicken Innen-Wand und eben die Außenwand/Terrassentür dazwischen, wenn der Sensor wieder meldet werde ich mal den RSSi wert beobachten, mal schauen wie schlecht der gegen meine anderen Werte ist, wenn das aussagekräftig ist..?
Zitat von: Dirk am 04 September 2014, 16:10:29
Was für einen, CUL oder HM-CFG-USB?
HM-CFG-USB
Daran liegt das wohl nicht, denn ich habe gerade den ganzen Anlernprozess an einem zweiten Cubietruck, ebenfalls mit einem HM-CFG-USB Adapter probiert... auch hier kommen nur 2 Zeilen plus Log
So, der Aussensensor geht wieder, ich habe den bisher nur reingeholt... Er sendet wieder...!
Hallo,
die RSSI Werte sind unkritisch - bei mir geht das bis ca. -80 / -90. Danach bekomme ich Ausfälle bzw. der Sensor Mus mehrmals senden, was die Batterie leersaugt.
Ich nutze derzeit einen HM-CFG-LAN. Mal sehen ob ich heute Abend dazu komme, das mal mit dem Raspi und dem USB zu testen.
Gruß Christoph
so da der Außensensor ohne mein zutun (nur rein geholt) wieder geht hier mal der RSSI Wert -77
Der zweite Sensor im Wohnzimmer der ca. 4m weiter Richtung USB Adapter liegt hat einen RSSI von -57
Beide trennen ca. 5-6 m
Der Sensor der sich nicht richtig pairen läßt liegt oben im 1. Stock und hat RSSI -68
Also alles vertreten und sollte ohne Probleme gehen, mal schauen was der Außensensor heute Abend macht wenn die Rollläden runter gehen, ob es schlechter wird..!
Aber sollte das alles so kritisch sein das die laufend aussteigen, gestern der Sensor im Wohnziemer heute der Außensensor..?
Tja und was ist mit dem pairen, das geht ja auch nicht und was soll ich machen..? Einige Fragen, hat denn niemand weiter diese Probleme mit der Entfernung..?
Hallo moonsorrox,
ich wollte gerade schreiben - geht mir auch so, da viel mir ein ....
Hast Du die Datei HMConfig_SenTHPL.pm heruntergeladen und nach ./fhem/FHEM/ kopiert ? Wenn diese "Erweiterungsdatei" nicht da ist, wird das Gerät nicht komplett angelegt.
Wenn nein - geh in diesem Tread mal ein paar Seiten zurück, da ist ein Link auf diese Datei.
Gruß Christoph
Ich habe das ganze mal mit einem HM-CFG-USB getestet.
Mit einem FHEM frisch aus dem SVN von vor ein paar minuten.
Ein Druck auf die Config-Taste vom Sensor ohne HMConfig_SenTHPL.pm liefert folgendes:
2014-09-04 20:37:22 CUL_HM CUL_HM_ID_F101_112233 D-firmware: 0.11
2014-09-04 20:37:22 CUL_HM CUL_HM_ID_F101_112233 D-serialNr: SEN0THPL03
@ moonsorrox: Sind das die 2 Zeilen von dem du schreibst?
Dann Autocreate mit der Datei HMConfig_SenTHPL.pm im FHEM-Ordner. Das sollte dann so aussehen:
2014-09-04 20:45:28 Global global UNDEFINED CUL_HM_HB_UW_Sen_THPL_I_112233 CUL_HM 112233
2014-09-04 20:45:28 Global global DEFINED CUL_HM_HB_UW_Sen_THPL_I_112233
2014-09-04 20:45:28 Global global DEFINED FileLog_CUL_HM_HB_UW_Sen_THPL_I_112233
2014-09-04 20:45:28 Global global SAVE
2014-09-04 20:45:28 CUL_HM ActionDetector status_CUL_HM_HB_UW_Sen_THPL_I_112233: alive
2014-09-04 20:45:28 CUL_HM CUL_HM_HB_UW_Sen_THPL_I_112233 D-firmware: 0.11
2014-09-04 20:45:28 CUL_HM CUL_HM_HB_UW_Sen_THPL_I_112233 D-serialNr: SEN0THPL03
2014-09-04 20:45:28 CUL_HM CUL_HM_HB_UW_Sen_THPL_I_112233 Activity: alive
2014-09-04 20:45:28 HMLAN HMLAN UNKNOWNCODE A0A2280021ACAE511223300::-48:HMLAN
Gruß
Dirk
Hallo Dirk,
genau das gleiche hatte ich auch gemacht .... und natürlich prompt die HM_Config Erweiteung vergessen. Könntest Du bitte an dem Ersten Tread einen Link zu dieser Datei und ggf. auch zu der aktuellen Firmware machen ? Dann kann man darauf verweisen.
Alternativ könnte man die Links auch im Wiki hinterlegen und im ersten Tread einen Verweis auf das Wiki machen. ich weiß nicht wasmbesser zu pflegen ist.
Gruß Christoph
Zitat von: Dirk am 04 September 2014, 20:51:34
@ moonsorrox: Sind das die 2 Zeilen von dem du schreibst?
Nein er legt mir nur diese beiden an...! Und eben noch das für die Logdatei
define CUL_HM_HB_UW_Sen_THPL_I_E742C9 CUL_HM E742C9
attr CUL_HM_HB_UW_Sen_THPL_I_E742C9 room CUL_HM
define FileLog_CUL_HM_HB_UW_Sen_THPL_I_E742C9 FileLog ./log/CUL_HM_HB_UW_Sen_THPL_I_E742C9-%Y.log CUL_HM_HB_UW_Sen_THPL_I_E742C9
attr FileLog_CUL_HM_HB_UW_Sen_THPL_I_E742C9 logtype text
attr FileLog_CUL_HM_HB_UW_Sen_THPL_I_E742C9 room CUL_HM
Über diese Datei haben wir schon gesprochen und ja diese habe ich nach fhem kopiert... Daran liegt das dann nicht
Poste bitte mal die Zeilen aus dem Event Monitor.
Zitat von: Bennemannc am 04 September 2014, 21:01:15
Könntest Du bitte an dem Ersten Tread einen Link zu dieser Datei und ggf. auch zu der aktuellen Firmware machen ?
Das soll alles noch ins Wiki rein.
Ich hänge mit der Dokumentation leider etwas hinterher
Zitat von: Dirk am 04 September 2014, 21:22:42
Poste bitte mal die Zeilen aus dem Event Monitor.
wenn du mich meinst...
Ich habe den Sensor schon umbenannt hier mal die Werte und wie gesagt ich habe die Readings model und subtype von Hand eingetragen da sie ja nicht gekommen sind...
2014-09-04 22:03:49 CUL_HM Temperatur_Wohnzimmer temperature: 23.8
2014-09-04 22:03:49 CUL_HM Temperatur_Wohnzimmer battery: ok
2014-09-04 22:03:49 CUL_HM Temperatur_Wohnzimmer humidity: 55
2014-09-04 22:03:49 CUL_HM Temperatur_Wohnzimmer luminosity: 0.06
2014-09-04 22:03:49 CUL_HM Temperatur_Wohnzimmer batVoltage: 3.03
2014-09-04 22:03:49 CUL_HM Temperatur_Wohnzimmer T: 23.8 H: 55 L: 0.06 batVoltage: 3.03achso, die Datei HMConfig_SenTHPL.pm ist bei mir noch vorhanden, hätte ja sein könne das die aufeinmal weg ist 8)
Nachtrag:
Und der Außensensor hat sich um 20.06 Uhr verabschiedet bei einer RSSI -78 also ist das nicth die Reichweite..?
Ich meine eigentlich die Zeilen aus dem Eventlog wenn er automatisch angelegt wird. Also wenn die manuell angelegten Daten fehlen.
Ich habe trotzdem keine Idee warum bei dir die Daten nicht alle automatisch angelegt werden. Auf alle Fälle ist das merkwürdig.
FHEM ist auch aktuell?
Zitat von: Dirk am 04 September 2014, 22:14:23
Ich meine eigentlich die Zeilen aus dem Eventlog wenn er automatisch angelegt wird. Also wenn die manuell angelegten Daten fehlen.
FHEM ist auch aktuell?
als ich den angelegt habe waren es ja nur diese beiden oben gezeigten Zeilen, dann kommt da gar nichts weil ja die Zeilen für model und subtype fehlen und in der Anzeige stehen Fragezeichen..
Fhem ist tagesaktuell, also heute früh das Update gemacht...
Wie bekomme ich jetzt im nach hinein noch die Firmware und die Serial Nr. dahin, die kann man sicher abfragen.
Entscheidend ist:
Ich meine momentan ist es mir egal, solange die beiden arbeiten, aber das ist ja das Problem der Außensensor ist schon wieder seit 20.06 Uhr weg da kommt nix mehr... ich werd noch doof ;)
Hallo,
also ich würde alles von vorne Machen. Das mit dem Fragezeichen hatte ich, als die Zusatzdatei fehlte. Gibt es eventuell Probleme mit Berechtigungen auf dieser Datei.
Wie gesagt Device löschen, save config, shutdown restart, Device reset und alles protokolliert nacheinander ausführen - ich fürchte sonst haben wir keine Chance der Sache auf die Spur zu kommen.
Gruß Christoph
ZitatWie bekomme ich jetzt im nach hinein noch die Firmware und die Serial Nr. dahin, die kann man sicher abfragen.
das kann eben nicht abgefragt werden, sondern wird vom sensor beim anlernvorgang gesendet. sobald du den sensor in den anlernmodus versetzt, schickt er eine message, in der diese daten enthalten sind.
du müsstest einmal diese messages aufzeichnen. setze bei deinem hmlan
attr <hmlan> logIDs <name_des sensors>dann bringst du den sensor in den anlernmodus. aber kein hmPairForSec machen. das machst du ein paar mal. anschliessend aus fhem.log den abschnitt posten.
gruss frank
Zitat von: Bennemannc am 04 September 2014, 22:37:14
also ich würde alles von vorne Machen. Das mit dem Fragezeichen hatte ich, als die Zusatzdatei fehlte.
das habe ich ja heute vormittag/mittag komplett mit dem 2. Innen-Sensor gemacht, deshalb hatte ich nach dem genauen Rüchsetzen des Sensors gefragt...
Ich denke aber heute nicht mehr, bin erst mal bedient ;)
Ok ich werde das dann morgen nochmals testen und mich wieder melden. 8)
Zitat von: Bennemannc am 04 September 2014, 22:37:14
Wie gesagt Device löschen, save config, shutdown restart, Device reset und alles protokolliert nacheinander ausführen
werde ich genau so machen
@frank
attr <hmlan> logIDs <name_des sensors>bei Name des Sensors, den jetzigen Namen oder meinst du diesen Original Namen, diesen hier "CUL_HM_ID_F101_8FB1E9 CUL_HM 8FB1E9"
ich habe das jetzt mal mit dem jetzigen Namen gemacht: folgende Zeilen gibt es
2014.09.04 22:52:42 0: HMLAN_Parse: HMUSB R:R4270CF21 stat:0001 t:212DEF96 d:FF r:FFC0 m:07 A010 8FB1E9 1EA121 0100000000
2014.09.04 22:52:42 0: HMLAN_Parse: HMUSB R:E8FB1E9 stat:0000 t:212DEF91 d:FF r:FFC0 m:07 A010 8FB1E9 1EA121 0100000000
2014.09.04 22:52:42 0: HMLAN_Send: HMUSB S:S4270CF21 stat: 00 t:00000000 d:01 r:4270CF21 m:07 A001 1EA121 8FB1E9 0103
2014.09.04 22:52:42 0: HMLAN_Send: HMUSB S:+8FB1E9,00,01,00
2014.09.04 22:52:41 0: HMLAN_Parse: HMUSB R:R4270CCBC stat:0001 t:212DEDF7 d:FF r:FFC0 m:06 A010 8FB1E9 1EA121 0201FF02010A1E0BA10C210000
2014.09.04 22:52:41 0: HMLAN_Parse: HMUSB R:E8FB1E9 stat:0000 t:212DEDF2 d:FF r:FFC0 m:06 A010 8FB1E9 1EA121 0201FF02010A1E0BA10C210000
2014.09.04 22:52:41 0: HMLAN_Send: HMUSB S:S4270CCBC stat: 00 t:00000000 d:01 r:4270CCBC m:06 A001 1EA121 8FB1E9 00040000000000
2014.09.04 22:52:41 0: HMLAN_Send: HMUSB S:+8FB1E9,00,01,00
da kann ich keine anlernmessage erkennen. die müsste an 000000 adressiert sein. ich glaube du bringst den sensor nicht in den anlernmodus.
er hat mir im Log des Sensors sogar jetzt die Firmware und die Serial Nr. gesendet..!
Anlernen ist doch kurz drauf drücken... da kann ich doch nichts falsch machen, oder doch...?
Ich mache das nochmal... und schreibe gleich
So sieht das aus:
2014.09.04 23:08:40 3: Device Temperatur_Bad added to ActionDetector with 000:10 time
2014.09.04 23:08:40 0: HMLAN_Parse: HMUSB R:E8FB1E9 stat:0000 t:213C8D78 d:FF r:FFB5 m:C1 A200 8FB1E9 1EA121 0BF1015557533830353934363570030100
2014.09.04 23:08:38 3: Device Temperatur_Bad added to ActionDetector with 000:10 time
2014.09.04 23:08:38 0: HMLAN_Parse: HMUSB R:E8FB1E9 stat:0000 t:213C87FC d:FF r:FFB6 m:C0 A200 8FB1E9 1EA121 0BF1015557533830353934363570030100
2014.09.04 23:07:55 3: Device Temperatur_Bad added to ActionDetector with 000:10 time
2014.09.04 23:07:55 0: HMLAN_Parse: HMUSB R:E8FB1E9 stat:0000 t:213BDFAC d:FF r:FFB4 m:BE A200 8FB1E9 1EA121 0BF1015557533830353934363570030100
na bitte. ;)
poste jetzt noch mal ein list vom device. vorher erst noch ein komplettes getconfig bis cmds_done. und save nicht vergessen. wenn du die rawmessages wieder los werden willst, lösche einfach das attribut logIDs.
gruss frank
Zitat von: frank am 04 September 2014, 23:20:00
vorher erst noch ein komplettes getconfig bis cmds_done.
das verstehe ich nicht...
Hier aber das list:
Internals:
CFGFN ./FHEM/Temperaturen.cfg
DEF 8FB1E9
HMUSB_MSGCNT 13
HMUSB_RAWMSG E8FB1E9,0000,2149377F,FF,FFBE,CAA2708FB1E91EA12100F2350000000003FA0B87
HMUSB_RSSI -66
HMUSB_TIME 2014-09-04 23:22:30
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 13
NAME Temperatur_Bad
NR 647
STATE T: 24.2 H: 53 L: 10.18 batVoltage: 2.95
TYPE CUL_HM
lastMsg No:CA - t:70 s:8FB1E9 d:1EA121 00F2350000000003FA0B87
protLastRcv 2014-09-04 23:22:30
protSnd 13 last_at:2014-09-04 23:22:30
protState CMDs_done
rssi_at_HMUSB avg:-67.15 min:-76 max:-51 lst:-66 cnt:13
Readings:
2014-09-04 23:14:22 Activity alive
2014-09-04 23:14:22 D-firmware 0.11
2014-09-04 23:14:22 D-serialNr UWS8059465
2014-09-04 22:52:41 PairedTo 0x1EA121
2014-09-04 22:52:41 R-burstRx undef lit:255
2014-09-04 22:52:41 R-pairCentral 0x1EA121
2014-09-04 22:52:41 RegL_00: 01:FF 02:01 0A:1E 0B:A1 0C:21 00:00
2014-09-04 23:22:30 batVoltage 2.95
2014-09-04 23:22:30 battery ok
2014-09-04 23:22:30 humidity 53
2014-09-04 23:22:30 luminosity 10.18
2014-09-04 23:22:30 state T: 24.2 H: 53 L: 10.18 batVoltage: 2.95
2014-09-04 23:22:30 temperature 24.2
Helper:
mId F101
rxType 132
Io:
newChn +8FB1E9,00,01,00
nextSend 1409865750.29747
prefIO
rxt 0
vccu
p:
8FB1E9
00
01
00
Mrssi:
mNo CA
Io:
HMUSB -64
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMUSB
flg A
ts 1409865750.20293
ack:
HASH(0x26104a0)
CA80021EA1218FB1E900
Rssi:
At_hmusb:
avg -67.1538461538462
cnt 13
lst -66
max -51
min -76
Attributes:
IODev HMUSB
actCycle 000:10
actStatus alive
alias Badezimmer
autoReadReg 4_reqStatus
expert 2_full
firmware 0.11
group Innen-Temperatur
model HB-UW-Sen-THPL-I
peerIDs 00000000,
room Temperaturen
serialNr UWS8059465
subType THPLSensor was konntest du denn sehen aus dem Messages..?
ich meine, das sieht soweit ok aus.
Zitatdas verstehe ich nicht...
set <dev> getConfig
danach warten bis unter internals beim sensor folgendes erscheint
ZitatprotState CMDs_done
gruss frank
OK, das hatte ich ja gemacht...
habe es jetzt noch mal kontrolliert ob das kommt und es wechselte von protState CMDs_pending nach protState CMDs_done
Dann werde ich das morgen mal mit dem ewig austeigenden Außensensor machen, denn der hat auch die Serial Nr. nicht drin, aber funktionierte und dann eben wieder nicht...! Aber das er aussteigt kann ja nicht an der nicht vorhandenen Serial Nr. liegen, oder doch..?
Es hat eigentlich nur einer meiner 3 Sensoren die Serial Nr., das model und subtype gebracht, daher wußte ich wie es aussehen muss. die anderen beiden waren beim anlernen nicht zu bewegen.... und wenn ich von anlernen spreche dann habe ich das bestimmt 10x probiert und nie kam mehr wie zwei Zeilen Code
Hallo,
geht doch :D. Wenn jetzt noch Aussetzer da sind, könnte man überlegen, ob man die Teile an ein virtuelles Device peert. Das hätte den Vorteil, das der Sensor auf eine "Bestätigung" von fhem wartet und ggf. noch einmal sendet. Das kann natürlich auf die Batterie gehen.
Im Moment senden die Sensoren ja an Broadcast - also an alle die es mitbekommen oder interessiert.
Gruß Christoph
OK nun zu dem Außensensor, der hat ja gestern abend um 20.06 Uhr aufgehört zu senden und seinen Dienst heute vormittag um 11.50 wieder aufgenommen... das hat er ja nun die letzten beiden Tage so gemacht.
Wie soll ich jetzt vorgehen, bevor ich ihn rein hole und drauf trete :P 8)
Das kann doch nicht an der fehlenden Serien Nr. liegen..!? Achso der RSSI ist momentan -76
Hier mal die Zeiten... zur Information
2014-09-05_11:50:42 Aussensensor_Terrasse T: 23.3 L: 524 P: 1010 P-NN: 1038 batVoltage: 2.82
2014-09-05_11:50:42 Aussensensor_Terrasse batVoltage: 2.82
2014-09-05_11:50:42 Aussensensor_Terrasse pressure-nn: 1038
2014-09-05_11:50:42 Aussensensor_Terrasse pressure: 1010
2014-09-05_11:50:42 Aussensensor_Terrasse luminosity: 524
2014-09-05_11:50:42 Aussensensor_Terrasse battery: ok
2014-09-05_11:50:42 Aussensensor_Terrasse temperature: 23.3
2014-09-04_23:50:56 Aussensensor_Terrasse Activity: unknown
2014-09-04_23:28:52 Aussensensor_Terrasse Activity: unknown
2014-09-04_23:06:11 Aussensensor_Terrasse Activity: unknown
2014-09-04_22:50:50 Aussensensor_Terrasse Activity: unknown
2014-09-04_22:28:21 Aussensensor_Terrasse Activity: unknown
2014-09-04_20:16:46 Aussensensor_Terrasse Activity: dead
2014-09-04_20:06:26 Aussensensor_Terrasse T: 22.5 L: 4.41 P: 1014 P-NN: 1042 batVoltage: 2.83
Zitat von: moonsorrox am 05 September 2014, 13:31:34
OK nun zu dem Außensensor, der hat ja gestern abend um 20.06 Uhr aufgehört zu senden und seinen Dienst heute vormittag um 11.50 wieder aufgenommen... das hat er ja nun die letzten beiden Tage so gemacht.
Hast du mal ein anderes Gerät, ggf. auch den Innensensor den du in die Nähe des Aussensensors legen kannst.
Ich würde gerne mal die RSSI-Werte vergleichen.
Oder kannst du mal generell die RSSI-Werte von anderen Geräten mit den Sensoren vergleichen?
Ich hatte vor einigen Wochen die Sendefrequenz der Sensoren geringfügig verändert. Damit war dann ein deutlich besseres Empfangsverhalten feststellbar. Vielleicht ist das bei dir ja umgekehrt. Ich würde dir heute abend einmal eine angepasste Firmewareversion zusenden dann kannst du schauen ob sich das verhalten bessert.
Gruß
Dirk
Zitat von: Dirk am 05 September 2014, 13:48:37
Hast du mal ein anderes Gerät, ggf. auch den Innensensor den du in die Nähe des Aussensensors legen kannst.
Ich würde gerne mal die RSSI-Werte vergleichen.
Oder kannst du mal generell die RSSI-Werte von anderen Geräten mit den Sensoren vergleichen?
ja geschrieben habe ich die schon irgendwo und auch die Entfernungen der einzelnen Sensoren zum HMUSB, aber alles kein Problem...!
Ich werde jetzt sofort den einen Innensensor zusammen mit dem Außensensor nebeneinander legen und dann mal die Werte schrieben...
Zitat von: Dirk am 05 September 2014, 13:48:37
Ich hatte vor einigen Wochen die Sendefrequenz der Sensoren geringfügig verändert. Damit war dann ein deutlich besseres Empfangsverhalten feststellbar. Vielleicht ist das bei dir ja umgekehrt.
Bei mir haben die Sensoren auch um 7-10dB schlechtere Werte als andere HM-Geräte. Ist bei mir nur nicht weiter schlimm, da die Entfernungen zur Zentrale bei mir nicht so groß sind. Aber wenn du Tester suchst, bin ich gerne behilflich. ;-)
also wie der Zufall es will aber der Außensensor sendet seit 8min. nichts mehr...! werde ihn gleich mal aufschrauben und diese Prozedur von gestern abend machen...!
Der Innensensor liegt daneben und hat jetzt einen RSSI -63 gegenüber des Außensensors als er noch funktionierte hatte er RSSI -77
Entfernung sage ich mal so um die 10m, grade Linie zum HMUSB durch eine Wand und ein Fenster/Terassentür wo Abends eben der Rollladen noch dazwischen ist
Aussensensor ist seit 13.52 Uhr weg
2014-09-05_13:52:08 Aussensensor_Terrasse T: 26.7 L: 968 P: 1010 P-NN: 1038 batVoltage: 2.83
jetzt hat er wieder eine Meldung bekommen
2014-09-05_14:09:15 Aussensensor_Terrasse R-burstRx: undef lit:255
2014-09-05_14:09:15 Aussensensor_Terrasse R-pairCentral: 0x1EA121
2014-09-05_14:09:15 Aussensensor_Terrasse T: 30.3 L: 81.4 P: 1009 P-NN: 1037 batVoltage: 2.82
2014-09-05_14:09:15 Aussensensor_Terrasse batVoltage: 2.82
2014-09-05_14:09:15 Aussensensor_Terrasse pressure-nn: 1037
2014-09-05_14:09:15 Aussensensor_Terrasse pressure: 1009
2014-09-05_14:09:15 Aussensensor_Terrasse luminosity: 81.4
2014-09-05_14:09:15 Aussensensor_Terrasse battery: ok
2014-09-05_14:09:15 Aussensensor_Terrasse temperature: 30.3
hat Angst bekommen weil ich ihn aufgeschraubt habe ;D
ausserdem gibt es immer auch 2 rssi-werte. einmal zum device (vom io) und einmel zum io (vom device). diese sind durch ein "at_" im namen zu unterscheiden. im idealfall sollten die ungefähr gleich sein. durch setzen von
attr <dev> rssiLog 1
im device, kannst du dir rssi-readings anlegen, die du dann bequem loggen/plotten kannst. dann kann man sehr schön beobachten, was alles einfluss auf die rssi werte hat. lage, position, ausrichtung der devices und io. störquellen wie wlan, dect, etc. auch offene/geschlossene fenster, türen, jalousien.
hier mal die Werte die ich gestern Abend auch geschrieben habe mit der getconfig über den HMUSB, evtl. bringen die was.
Habe also nur den Config Taster gedrückt...
2014.09.05 14:09:16 0: HMLAN_Parse: HMUSB R:R45B7F371 stat:0001 t:24751169 d:FF r:FFB9 m:09 A010 EAD5C7 1EA121 0100000000
2014.09.05 14:09:16 0: HMLAN_Parse: HMUSB R:EEAD5C7 stat:0000 t:24751164 d:FF r:FFB9 m:09 A010 EAD5C7 1EA121 0100000000
2014.09.05 14:09:16 0: HMLAN_Send: HMUSB S:S45B7F371 stat: 00 t:00000000 d:01 r:45B7F371 m:09 A001 1EA121 EAD5C7 0103
2014.09.05 14:09:16 0: HMLAN_Send: HMUSB S:+EAD5C7,00,01,00
2014.09.05 14:09:15 0: HMLAN_Parse: HMUSB R:R45B7F166 stat:0001 t:24750FCA d:FF r:FFBA m:08 A010 EAD5C7 1EA121 0201FF02010A1E0BA10C210000
2014.09.05 14:09:15 0: HMLAN_Parse: HMUSB R:EEAD5C7 stat:0000 t:24750FC5 d:FF r:FFBA m:08 A010 EAD5C7 1EA121 0201FF02010A1E0BA10C210000
2014.09.05 14:09:15 0: HMLAN_Send: HMUSB S:S45B7F166 stat: 00 t:00000000 d:01 r:45B7F166 m:08 A001 1EA121 EAD5C7 00040000000000
2014.09.05 14:09:15 0: HMLAN_Send: HMUSB S:+EAD5C7,00,01,00
2014.09.05 14:09:15 0: HMLAN_Parse: HMUSB R:EEAD5C7 stat:0000 t:24750E1E d:FF r:FFB8 m:F6 A270 EAD5C7 1EA121 012F0003F100001FCC0B07
So ich habe jetzt dem Außensensor nochmals neue Batterien spendiert wenn er schon offen ist also rein damit...
Der HMUSB_RSSI Wert ist nach wie vor -77 der direkt daneben (1cm) liegen Innensensor hat HMUSB_RSSI -63
Also schon ein Unterschied... was soll ich jetzt noch für Werte posten mal im Vergleich beide Sensoren hier:
Außensensor
2014-09-05_14:22:15 Aussensensor_Terrasse T: 30.7 L: 15285 P: 1009 P-NN: 1037 batVoltage: 3.07
2014-09-05_14:22:15 Aussensensor_Terrasse batVoltage: 3.07
2014-09-05_14:22:15 Aussensensor_Terrasse pressure-nn: 1037
2014-09-05_14:22:15 Aussensensor_Terrasse pressure: 1009
2014-09-05_14:22:15 Aussensensor_Terrasse luminosity: 15285
2014-09-05_14:22:15 Aussensensor_Terrasse battery: ok
2014-09-05_14:22:15 Aussensensor_Terrasse temperature: 30.7
Innensensor
2014-09-05_14:21:28 Temperatur_Bad T: 28.3 H: 51 L: 8837 batVoltage: 2.94
2014-09-05_14:21:28 Temperatur_Bad batVoltage: 2.94
2014-09-05_14:21:28 Temperatur_Bad luminosity: 8837
2014-09-05_14:21:28 Temperatur_Bad humidity: 51
2014-09-05_14:21:28 Temperatur_Bad battery: ok
2014-09-05_14:21:28 Temperatur_Bad temperature: 28.3
Zitatwerde ihn gleich mal aufschrauben und diese Prozedur von gestern abend machen...!
wenn du damit meinst, den sensor in den anlernmodus zu setzen, dann kann man das aber in deinem log nicht erkennen. hat dann wohl nicht funktioniert.
Zitat von: frank am 05 September 2014, 14:32:46
wenn du damit meinst, den sensor in den anlernmodus zu setzen
nein Anlernen meinte ich nicht nur das senden über den HMUSB mit der logID damit habe ich die Firmware und die Serien Nr. gestern bekommen und die Readings sind jetzt komplett ;) alles da was fehlte...!
Zitatnein Anlernen meinte ich nicht nur das senden über den HMUSB mit der logID damit habe ich die Firmware und die Serien Nr. gestern bekommen und die Readings sind jetzt komplett
das hast du völlig falsch verstanden.
mit dem attribut logIDs werden nur die vorhandenen funkmessages im log eingetragen, sonst nichts.
damit die seriennummer vom device gesendet wird, muss das device in den anlernmodus gesetzt werden. also auch nicht anlernen, sondern nur den modus einschalten. nur dann sendet das device die seriennummer.
wenn es also doch funktioniert hat, hast du den falschen logausschnitt gepostet, da dort nichts enthalten war.
OK, dass war gestern alles zuviel und verwirrend für mich, dass habe ich in der Tat dann falsch verstanden ;)
Aber jetzt läuft es ja alles und alle beiden Sensoren die nur diese beiden Zeilen Code gesendet hatten gehen ja jetzt und haben die Readings komplett mit allem drin... Damit sollte eine richtige Funktion gewährleistet sein. Wenn nicht bitte nochmal ein Hinweis was ich tun soll.
Die jetzige Frage ist eben nur warum steigt besonders der Außensensor immer aus, sicher ist es dem RSSI geschuldet der wohl so ganz knapp an der Grenze ist, denn der direkt daneben liegende Innensensor hat einen wesentlich besseren Wert.
ZitatDie jetzige Frage ist eben nur warum steigt besonders der Außensensor immer aus, sicher ist es dem RSSI geschuldet der wohl so ganz knapp an der Grenze ist, denn der direkt daneben liegende Innensensor hat einen wesentlich besseren Wert.
versuche doch mal den tipp mit den rssi-readings und plotte diese. ist ja schon komisch das du nur nachts keine verbindung hast.
Zitat von: frank am 05 September 2014, 15:09:05
versuche doch mal den tipp mit den rssi-readings und plotte diese. ist ja schon komisch das du nur nachts keine verbindung hast.
Ok werde ich machen... naja Nachts ist ja nicht so ganz richtig..! Heute morgen hat er den Dienst erst kurz nach 11 Uhr begonnen ;) und gestern gegen 20.06 Uhr war der Rollladen auch noch nicht unten, so das ihn der gestört haben könnte ;) vllt ist der ja sensibel sobald es leicht dämmert :D
Hallo,
@moonsorrox
wie ist den die Lage der Antennen - gibt es da einen Unterschied zwischen Innensensor und Außensensor ?
Sonst ändere die Anntennenlage am Außensensor mal z.B. von quer nach hochkant. Das kann schon einen Unterschied machen.
Ich hatte mal Probleme mit einem Sender im Keller der war jenseits der -95, teilweise bei -120. Nur zwei Meter weiter verrichtet er jetzt zuverlässig seinen Dienst mit -82. Wenn Du also nicht genau an diese Position gebunden bist - mal den Sensor versetzen.
Der nächste Punkt wäre das peering zur Zentrale mittels VCCU oder virtuellem Device. Wenn dann eine Meldung vom Sensor nicht bestätigt wird (von fhem), sollte der Sender es noch einmal versuchen. Wie schon erwähnt, geht das natürlich zu Lasten der Batterie.
Gruß Christoph
Zitat von: Bennemannc am 05 September 2014, 15:51:18
Der nächste Punkt wäre das peering zur Zentrale mittels VCCU oder virtuellem Device. Wenn dann eine Meldung vom Sensor nicht bestätigt wird (von fhem), sollte der Sender es noch einmal versuchen. Wie schon erwähnt, geht das natürlich zu Lasten der Batterie.
Es reicht schon den Sensor mit FHEM zu pairen. FHEM sendet dann ein ACK zum Sensor.
Das kann man auch schön am blinkverhalten der Status-LED sehen.
kurz Blinken heist "Nachricht wird gesendet"
ein weiteres kurz Blinken bedeutet ACK
ein langes Blinken bedeutet NACK. Das sollte aber erst nach dem 5. mal kurz Blinken kommen.
Der Sensor versucht aktuell bis zu 5 mal seine Nachricht zu versenden.
ZitatDer nächste Punkt wäre das peering zur Zentrale mittels VCCU oder virtuellem Device. Wenn dann eine Meldung vom Sensor nicht bestätigt wird (von fhem), sollte der Sender es noch einmal versuchen.
im moment kommt ja nichts an in fhem. das muss auch nicht bestätigt werden. ;)
zu der Antenne, naja das geht ja nur bedingt zu ändern, da der Außensensor zu ist da kannst du nicht viel verändern, der Innensensor ist noch offen, also das Gehäuse liegt nur drauf aber neben dem Helligkeitssensor so das beide die volle Sonne bekommen. Solange da noch nichts zuverlässig funktioniert mache ich den Innensensor noch nicht fertig, soll heißen das Loch für den Acrylstab, der Außensensor hat ja die Folie drin..
Ich habe mal ein Screenshot zu den rssi Werten dran gehangen, ich weiß jetzt nicht wie man manuell in der rechten Zeile die negativ Werte einträgt ich wollte die auf -81 stellen damit er nicht immer hoch bis an die Grenze geht... diese erstellt er ja automatisch, aber man kann sie ja ändern..
Hallo,
das wäre z.B. was zum testen. Ist der Empfang/Sendung besser, wenn die Antenne über der Folie ist, oder macht das keinen Unterschied.
Die Folie ist beschichtet - aber mit was ? Hält das auch Funkstrahle - also Elektromagnetische Wellen zurück ?
Man kann in dem Außengehäuse die Antenne durchaus quer unter der Platine verlegen, oder am Rand parallel zur Platine. Da das ein Rundstrahler ist, kann das durchaus Unterschiede machen.
Gruß Christoph
ich habe die Antenne seitlich an der Folie vorbei gelegt, so das sie dann oben unter dem durchsichtigen Deckel lang läuft, also gut sichtbar von draußen durch den Deckel... Ich arbeite viel mit Elektrotechnik Zeuchs ;) und kenne soetwas zur Genüge...
Das war also schon von Anfang an so, dass die Antenne oberhalb liegt das denke ich ist es nicht... wollte nur den Deckel in der Nacht nicht weglassen wegen der Feuchtigkeit die doch schon vorherrscht ;)
Also das ist wohl kein Kriterium für das sogenannte abkacken :D :P
der range für den plot muss zb "[-100:-60]" sein.
bei mir habe ich festgestellt, dass ich die besten rssi bekomme, wenn die drähte der antenne in einer geraden linie verlaufen. also weder gebogen, geknickt, noch sonstwie. und dann die spitzen der antennen beider partner aufeinander zu ausrichten, sodass sie dann quasi antiparallel verlaufen.
Zitat von: frank am 05 September 2014, 16:28:52
wenn die drähte der antenne in einer geraden linie verlaufen. also weder gebogen, geknickt, noch sonstwie.
das geht in dem Gehäuse aber nicht, da ja die Antenne länger ist, bei mir kommt sie an der kurzen Seite hoch und dann muss sie ja schon leicht gebogen werden um an der längeren Seite entlang zu laufen oberhalb der Folie..
Zitatdas geht in dem Gehäuse aber nicht, da ja die Antenne länger ist, bei mir kommt sie an der kurzen Seite hoch und dann muss sie ja schon leicht gebogen werden um an der längeren Seite entlang zu laufen oberhalb der Folie..
schon klar. nur grundsätzlich. bei meinem hmlan habe ich zb ein loch ins gehäuse gebohrt und den draht dann nach aussen geführt. bei einem weit entfernten hm-cc-vd ebenfalls. wenn ich dann die drähte an der stelle wo sie aus dem gehäuse kommen, jeweils in die richtung des anderen umbiege, erhalte ich bei dieser verbindung die besten ergebnisse. die antennenspitzen "zielen" dann auf den jeweils anderen.
manchmal reicht schon das gehäuse 90 grad drehen oder kippen. sodass beide antennen parallel oder antiparallel ausgerichtet sind.
Moin!
Heute habe ich mich etwas intensiver mit den neuen Sensoren beschäftigt.
Zuerst musste ich leider feststellen, dass diese noch nicht optimal mit dem FHEM liefen.
Die LED blinkt (bei allen) 5 Mal kurz und dann ein mal lang. Also kein ACK. Die Werte kommen aber an. Die Kommunikation ist also etwas "einseitig". Scheinbar hat das Pairen nicht geklappt. Wenn ich FHEM in Anlernmodus versetze (virtuelle ccu), dann wird das Gerät zwar angelegt, aber getConfig scheint nicht zu funktionieren. Nach einiger Zeit steht im State IOErr und wird nach der nächten Übertragung durch die Werte ersetzt. Bei nochmaligen kurzem Druck auf den Taster nach dem getConfig scheint dass dann zu klappen. In FHEM steht "PairedTo 0xFFFFFF". Aber auch dann blink Der Sensor 5x kurz + 1x lang.
Mein altes Sensor, noch mit Seriellen Bootloader und Firmware v0.10 blinkt dagegen 2 mal kurz.
Was läuft denn falsch?
Nach einigem Herumprobieren habe ich es hinbekommen. Vlt. hat jemand ein ähnliches Problem...
Ich habe FHEM Update gemacht und dann für jeden Sensor einzeln die virtuelle CCU in Pairing-Modus gebracht (set ccu hmPairForSec 600) und den Konfig-Taster gedruckt. Danach waren alles Sensoren glücklich.
EIne richtige Erklärung für dieses Verhalten habe ich nicht, abr es funktioniert jetzt.
Grüße,
Alexander
Ich habe bisher keine virtuelle ccu eingesetzt.
Ein normales Anlernen an FHEM nur durch drücken der Config-Taste legt das Device zwar in FHEM an, vorausgesetzt autocreate ist aktiv, aber erstellt kein Pairing. Daher wird FHEM hier auch noch kein ACK senden.
Zum Pairen muss man das CUL_HM erst in den Anlernmode bringen (hmPairForSec <sec>). Dann noch mal die Config-Taste drücken.
Erst dann wechselt "R-pairCentral 0xFFFFFF" auf einen anderen Wert.
Und erst dann wird der Sensor nach dem Senden von Nachrochten ein ACK bekommen.
Aha, also dieses zweite Drucken ist wichtig!
Die Original-HM-Geräte reagieren hier etwa anders, aber unwichtig, muss man nur wissen ;)
Danke!
Zitat von: hexenmeister am 05 September 2014, 22:08:55
Aha, also dieses zweite Drucken ist wichtig!
Man kann hmPairForSec auch zuerst eingeben. Dann reicht einmaliges drücken.
ZitatDie Original-HM-Geräte reagieren hier etwa anders, aber unwichtig, muss man nur wissen ;)
Echt? ich habe das bei meinen anderen devices auch nicht anders in Erinnerung.
Ich habe auch zuerst hmPairForSec eingegeben (mache ich immer so). Hat bei mir gestern nicht gereicht.
Komisch. Evtl. hatte es war mit dem Update zu tun...
Bei HM-Geräten hört das das Blinken auf, wenn der Anlernvorgang erfolgreich war. Diese Sensoren blinken weiter. Wirklich wichtig ist das aber natürlich nicht...
Zitat von: hexenmeister am 05 September 2014, 22:15:50
Bei HM-Geräten hört das das Blinken auf, wenn der Anlernvorgang erfolgreich war. Diese Sensoren blinken weiter. Wirklich wichtig ist das aber natürlich nicht...
Stimmt. da hast du recht.
Das könnte man in der Asksin-Lib mal ändern.
Hier sind mal die Firmware-Files die man per OTAU flashen kann mit 2 unterschiedlichen Frequenzen.
HB-UW-Sen-THPL-I-O_11_868.289551mhz ist aktuell auf den Sensoren.
Früher liefen die Sensoren mit 868.299866 Mhz. Nach der Änderung auf 868.289551Mhz gab es deutlich weniger Aussetzer.
@moonsorrox: Magst du die 868.299866 Mhz Version mal testen?
Zum Flashen mit HM-CFG-USB oder CUL braucht man hmland: https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb
Oder das Windows-Firmware-Update-Tool.
Gruß
Dirk
also ich kann da Hexenmeister folgen...
ZitatDie LED blinkt (bei allen) 5 Mal kurz und dann ein mal lang. Also kein ACK. Die Werte kommen aber an. Die Kommunikation ist also etwas "einseitig". Scheinbar hat das Pairen nicht geklappt.
gleiches Verhalten bei mir, er blinkt immer 5x und einmal lang
ZitatIch habe bisher keine virtuelle ccu eingesetzt.
weiß ich gar nicht was das zu bedeuten hat... werde mich mal mit beschäftigen evtl. löst das meine Reichweitenprobleme..?!
ZitatBei HM-Geräten hört das das Blinken auf, wenn der Anlernvorgang erfolgreich war. Diese Sensoren blinken weiter. Wirklich wichtig ist das aber natürlich nicht...
bei mir ebenfalls, habe ja genug geübt die Tage ;)
hier dann mal der Screen bis 0Uhr man kann gut sehen das er Ausreißer hat um 18 Uhr rum und dann sich wohl weghängt. Aus dem Log ist zu ersehen das er da längere Pausen gemacht hat, aber sich wohl wieder gefangen hat... Bis jetzt läuft er noch..
Zitat von: Dirk am 06 September 2014, 00:05:39
@moonsorrox: Magst du die 868.299866 Mhz Version mal testen?
Zum Flashen mit HM-CFG-USB oder CUL braucht man hmland: https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb
Oder das Windows-Firmware-Update-Tool.
ja ich bin gerne bereit etwas beizutragen wenn es was zu verbessern gibt, aber es muss mich jemand an die Hand nehmen, da ich überhaupt keine Ahnung habe was ich dazu tun muss... wenn es dann gemacht ist sicher kein Problem...
Mein Sender liegt ja draußen im Dunkeln, muss ich den dazu holen... Was brauche ich alles und wie geht man da vor..?
Ja. Aktuell kann man den Bootloader nur manuell starten.
Auf was für einem System willst du das machen? Linux oder Windows?
Zitat von: Dirk am 06 September 2014, 00:17:52
Ja. Aktuell kann man den Bootloader nur manuell starten.
Auf was für einem System willst du das machen? Linux oder Windows?
ich habe zwar ein Linux Mint Pc, aber arbeite lieber hier mit meiner Windows Kiste.. 8)
Mein HM-CFG-USB hat die Firmware 0.964
Ok, Dann brauchst du das Updatetool:
http://www.eq-3.de/Downloads/Software/Firmware%20Update%20Tool/HM-CFG-USB-2_FW-UpdateTool-Usersoftware_V1_1_eQ-3_140619.zip
Einmal installieren. Dann muss der USB-Stick an den Windows-PC
Im Update-Tool wählst du die FW-Datei aus und gibst die Seriennummer vom Sensor ein. Dann wartet das Tool das sich der Bootloader vom Sensor meldet.
Dann die Batetrie vom Sensor kurz raus nehmen. Die Config-Taste drücken und gedrückt halten. Batterie wieder einlegen, dabei die Taste noch ein paar Sekunden weiter gedrückt halten. Dan sollte die LED anfangen zu blinken und das Update starten.
Da das Update-Tool nur tgz-Files nimmt, hier die FW-Files noch als tgz.
gut dann kann es fast losgehen...!
Kann ich den HM-USB-CFG einfach so von meinem Cubietruck abziehen...?
Und welche Firmware soll ich zuerst auswählen..?
ZitatKann ich den HM-USB-CFG einfach so von meinem Cubietruck abziehen...?
Stoppe FHEM vorher. Dann kann der ab.
Die Version mit 868.289551mhz ist aktuell auf dem Sensor. Also dann die andere.
so fertig Neue Firmware ist drauf...!
Zitat von: moonsorrox am 06 September 2014, 00:50:38
so fertig Neue Firmware ist drauf...!
Na dann schau mal ob sich jetzt Änderungen am Empfangsverhalten ergeben. Ggf. auch vom RSSI.
Mit der anderen Firmware kannst du wieder auf den stand von vorhin zurück gehen.
muss er nicht neu angelernt werden..? sehe ich irgendwo die neue Firmware.?
Nein.
Bei diesem Update nicht. Der EEprom wird beim FW-Update nicht verändert.
Wenn die Updates umfangreicher werden, dann kann das vielleicht mal nötig sein.
OK, also er läuft wieder und hatte auch mal kurz RSSI bei unter -65. zu dem blinken er blinkt nur noch zweimal kurz, dass heißt er sendet wohl besser, oder braucht nicht solange, weil sonst würde er ja wie vorher 5x blinken...
Ich werde morgen den Plot rein stellen vom RSSI, dann können wir weiter schauen, ich bringe den Jungen mal wieder raus 8)
hier nun mal wie versprochen das Ergebnis bis heute, der kleine Ausritt an die -65 war wohl Zufall das war kurz nachdem ich ihn raus gebracht hatte.
Ich wollte mal dazu die Helligkeit plotten, aber ich bekomme das nicht rein in den Plot, was muss ich da denn im Ploteditor einstellen um das hinzukriegen..?
ZitatIch wollte mal dazu die Helligkeit plotten, aber ich bekomme das nicht rein in den Plot, was muss ich da denn im Ploteditor einstellen um das hinzukriegen..?
zähl doch die Felder, jedes Feld ist getrennt durch leerzeichen, also statt 6 eine 4
und stell mal bei rssi linientyp steps ein. dann kannst du bei langen waagerechten abschnitten von kommunikationsproblemen ausgehen.
Zitat von: fhem-hm-knecht am 06 September 2014, 13:20:05
zähl doch die Felder, jedes Feld ist getrennt durch leerzeichen, also statt 6 eine 4
das mit dem zählen weiß ich und dachte nee das kann es nicht sein hatte ich probiert da kommt nur Müll raus... da setzen die blauen Kurven genau auf dem RSSI auf und gehen extrem hoch da dachte mir ist falsch, aber Plot ist nicht so mein Ding damit komme ich nicht richtig klar ;) :-X
Zitat von: frank am 06 September 2014, 13:24:07
und stell mal bei rssi linientyp steps ein.
schau mal...!
y- Achse auf links auch anbinden :)
Zitat von: fhem-hm-knecht am 06 September 2014, 13:43:29
y- Achse auf links auch anbinden :)
oh ja ich habs geschnallt, Danke ;)
Sind das jetzt die Werte mit der 868.299866 FW?
Lass das doch mal so einen Tag laufen und dann lass den mal einen Tag zu Vergleich mit der 868.289551 FW laufen.
Hier scheint es immer mal wieder länger Pausen zu geben. genau das war das Problem mit der 868.299866er
Der Sensor sendet in der Regel alle 2-3 min. Also sollten pro Stunde ~ 24 Messages ankommen.
Hier ist übrigens der Beitrag wo ich die Änderung umgesetzt hatte:
http://forum.fhem.de/index.php/topic,20620.msg183523.html#msg183523
Und hier die Untersuchung von vbs dazu:
http://forum.fhem.de/index.php/topic,20620.msg181749.html#msg181749
Hallo Dirk,
ich habe nichts geändert - also habe ich wohl die "Low"-Frequenzversion drauf. In Zusammenarbeit mit dem HM-CFG-LAN habe ich keine Aussetzer und meine RSSI Werte sind mit -71 und -77 auch nicht super gut.
Es kann also auch an dem Zusammenspiel Sensor / Empfangsgerät liegen. Vielleicht ist der CFG-USB etwas anders abgestimmt ist. Wie ist das Zusammenspiel mit einem CUL ?
Gruß Christoph
hab meine beiden Sensoren mittlerweile auch am laufen, hab sie mit 2 verschiedenen FHEM Installationen gepairt, bin gerade am umziehen von RasPi auf Cubietruck, sie liefern in beiden korrekte Daten.
Andreas
Moin Dirk,
ich habe meine beiden Sensoren auch am laufen. :)
(nachdem ich dahintergekommen war, das die Datei HMConfig_SenTHPL.pm noch eingebunden werden musste ::) ).
Ein kleiner Hinweis im Universalsensor-Wiki wäre nicht schlecht. Zumal der Tröt hier doch schon sehr lang geworden ist.
Gruß
Klaus
Zitat von: dampf123 am 07 September 2014, 11:00:32
Ein kleiner Hinweis im Universalsensor-Wiki wäre nicht schlecht. Zumal der Tröt hier doch schon sehr lang geworden ist.
hat er schon geschrieben, wird wohl demnächst erledigt, denn darauf sind schon einige rein gefallen... ;)
ich gebe hier mal meinen Screenshot zum guten..! sind wohl einige Aussetzer, vllt sollte ich mal die Zeitachse etwas verändern um es besser zu sehen, ich weiß nur nicht wie ich "fixedrange" unter einem Tag verändern kann
Zitatich gebe hier mal meinen Screenshot zum guten..! sind wohl einige Aussetzer, vllt sollte ich mal die Zeitachse etwas verändern um es besser zu sehen, ich weiß nur nicht wie ich "fixedrange" unter einem Tag verändern kann
du brauchst doch eigentlich nur zoomen. also auf das grosse "+" überm plot klicken. schön finde ich auch das attribut endPlotNow=1 für das WEB-modul. dann wird immer der aktuelle zeitpunkt nach ganz rechts verschoben => plottet immer den grösst möglichen ausschnitt.
gruss frank
Zitat von: frank am 07 September 2014, 12:37:14
du brauchst doch eigentlich nur zoomen
oh ja :-[
echt doof manchmal... ;)
das Attribut ist aber nicht im Ploteditor zu finden, muss wohl manuell eingebunden werden..!?
Hallo,
mir ist gerade etwas sonderliches aufgefallen. Der Innensensor von Dirk macht meinen Differnzthemperatursensor von HM platt - aber so richtig.
Ich habe den in die Ecke gesetzt, an der im Keller einigermaßen Empfang ist. Der Abstand der Sensoren war ca. 10 cm. Seit der Installation des Innensensores kommen vom Differnzsensor keinenDaten mehr. Aber es kommt noch besser - der HM Sensor hängt sich auf ! Keine Reaktion bei Druck auf Taster - nur Spannung weg und wieder dran hilft.
Ich habe jetzt den Abstand mal vergrößert. Ich bin mal gespannt ob das reicht.
Gruß Christoph
Zitatdas Attribut ist aber nicht im Ploteditor zu finden, muss wohl manuell eingebunden werden..!?
Zitatfür das WEB-modul
attr myFHEMWEB endPlotNow 1
;) man achte auf die Feinheiten, Danke
übrigens habe ich mal geschaut, ich habe 20-30 minütige Aussetzer bei RSSI alles im die -80 rum
Zitatübrigens habe ich mal geschaut, ich habe 20-30 minütige Aussetzer bei RSSI alles im die -80 rum
du könntest den sensor immer weiter entfernen, um zu sehen, welche rssi überhaupt noch erkannt werden können.
gute Idee, mache ich gleich mal
Guten Abend!
Ich habe den Universalsensor nun seit zwei Wochen im Einsatz! Super Teil, muss ich wirklich sagen. Da bekommt man direkt Lust, mal selbst eine kleine Version zu bauen. Eine Frage hab ich noch: Sind eure Pressure-Werte momentan auch alle nur zwischen 995 und 1014? Die Range ist (eigentlich unabhängig von gutem oder schlechtem Wetter) doch relativ klein.
Danke & Gruß,
Markus
Hallo Markus,
bei mir liegen die Werte 1008 - 1023
Gruß
Klaus
Zitat von: Dirk am 27 August 2014, 12:19:30
Hab mal eine angegangen.
Die gilt für Model HB-UW-Sen-THPL-O und Model HB-UW-Sen-THPL-I. Also für den geasmmten Subtype THPLSensor
Hej Dirk,
also seit gestern ist dein Sensor auch für andFHEM verfügbar. Dürfte ich dich noch um einen kurzen Auszug aus dem FileLog von einem vollbestückten Sensor bitten, damit zukünftig auch die Graphen für den Sensor in andFHEM dargestellt werden können? :-)
Btw. wäre vielleicht eine gute Gelegenheit, die vor einigen Tagen besprochene Änderung für das State-Feld durchzuführen. Lokal hab ich die batVolt schon entfernt. Macht sich auf alle Fälle besser in der Anzeige. ;-)
Thx a lot!
so ich möchte nun mal meine Screenshots von gestern zeigen was RSSI und das senden betrifft.
Also erste Bild - ich habe wie ersichtlich den Sensor kurz nach 13 Uhr an eine andere etwas entferntere Stelle gelegt und wie zu sehen komplett weg über eine längere Zeit, dann kam mal wieder was, also diese Firmware bringt es nicht..!
Das zweite Bild, der Sensor liegt neben meinem Wohnzimmer Innensensor, selbst hier bei sehr gutem RSSI Wert steigt er sehr oft aus...!
Zitat von: moonsorrox am 08 September 2014, 12:01:14
Das zweite Bild, der Sensor liegt neben meinem Wohnzimmer Innensensor, selbst hier bei sehr gutem RSSI Wert steigt er sehr oft aus...!
Bist du dir sicher, dass er da aussteigt und nicht einfach den selben Wert über einen gewissen Zeitraum sendet?
Lade doch bitte mal das Logfile dazu hoch.
Thx a lot!
OK wird gemacht ;)
Zitat von: moonsorrox am 08 September 2014, 12:25:05
OK wird gemacht ;)
Wie ich es mir gedacht hab... Die Daten vom Innensensor werden zuverlässig empfangen. ;-)
Zitat von: Mr. P am 08 September 2014, 12:34:44
Wie ich es mir gedacht hab... Die Daten vom Innensensor werden zuverlässig empfangen. ;-)
ist der Außensensor, aber egal...
auch in der Zeit als ich ihn weiter weggelegt habe also gestern ca. 13 Uhr bis 21 Uhr
und was verursacht die langen Pausen.?
Zitat von: moonsorrox am 08 September 2014, 12:38:37
ist der Außensensor, aber egal...
auch in der Zeit als ich ihn weiter weggelegt habe also gestern ca. 13 Uhr bis 21 Uhr
und was verursacht die langen Pausen.?
Achso, entschuldige. Hatte vorhin den Text schlecht zitiert - dadurch kam das natürlich nicht so toll rüber, was ich eigentlich von dir wollte (nämlich das Log vom Innensensor).
Beim Außensensor hast du definitiv Verbindungsabbrüche. Bei einem Zeitraum von mehr als einer Stunde ist es äußerst unwahrscheinlich, dass sich keiner der Werte zwischendurch je geändert hat. Gestern sieht man gut, dass das letzte Mal um 13:17:22 Daten übermittelt wurden und dann erst wieder um 18:21:29. Aber die Übertragung ist ohnehin sehr unregelmäßig. Wenn du dir das Logfile ansiehst, dann sollte - über den Daumen - alle 2,5 Minuten eine Nachricht eintrudeln. Das kommt zwar auch immer wieder vor, aber -80dB scheinen bei dir das Limit zu sein und dadurch gehen immer wieder Nachrichten verloren.
Ich nehme an, du hast den Sensor gestern gegen 20:15 wieder herein geholt?
Mich würde interessieren, ob ein Muster zu erkennen ist, wenn der Sensor einmal 2-3 Tage an seinem Einsatzort steht.
Zitat von: Mr. P am 08 September 2014, 13:19:16
Achso, entschuldige. Hatte vorhin den Text schlecht zitiert - dadurch kam das natürlich nicht so toll rüber, was ich eigentlich von dir wollte (nämlich das Log vom Innensensor).
;) keen Problem...
Zitat von: Mr. P am 08 September 2014, 13:19:16
Beim Außensensor hast du definitiv Verbindungsabbrüche.
das meinte ich gut zu sehen im Plot
@frank
danke auch an dich, dadurch sehen wir es erst...
geht ja auch um mithilfe beim erkennen von Fehler...! weil ich ja die andere Firmware von Dirk extra mal auf den Sensor geladen habe um gerade dieses zu testen
Zitat von: Mr. P am 08 September 2014, 13:19:16
Ich nehme an, du hast den Sensor gestern gegen 20:15 wieder herein geholt?
Mich würde interessieren, ob ein Muster zu erkennen ist, wenn der Sensor einmal 2-3 Tage an seinem Einsatzort steht.
genau, da habe ich den "Jungen" rein geholt damit er nicht so da rum liegt und nichts tut ;)
tja ich hatte ihn ja ca. 6-7 m nach rechts gelegt und damit also noch weiter entfernt, dass wollten wir ja mal testen.. Test bestanden Ergebnis schlecht...
Ich werde die bisher allgemein letzte Firmware evtl. heute wieder drauf spielen und schauen wie es sich verhält...
Gemacht haben wir es ja, weil ich Verbindungsabbrüche habe/hatte...! ich finde die Entfernung (ca. 8m mit einer Wand dazwischen und der Terrassentür mit Rollladen) wo er eigentlich hin soll jetzt nicht so groß, aber es geht wohl nicht so recht..
Hallo zusammen,
ich habe mal eine Frage zu den Ausgabewerten vom Helligkeitssensor:
sehe ich das richtig, das Zahlenwerte von 0.01 - 65538 ausgegeben werden ?
von 0.01 - 99.99 mit zwei Stellen hinter dem Komma, danach ohne Nachkommastelle ?
und was ist der maximale ausgegebene Zahlenwert (65535) ?
Gruß
Klaus, der noch nen bischen auf dem Schlauch steht ....... ::)
Ohne in Quellen geschaut zu haben, würde ich sagen, das der Maximum der Helligkeit genau bei 65535 liegt. Das ist durchaus logisch, da die maximale 16Bit Value. Ich habe mit einer 3W LED versucht (direkte Bestralung damit überfordert jeden Sensor ;) ), es kommt genau das.
Hallo Klaus,
Der Helligkeitssensor liefert die Werte in Lux.
Das geht von 0.00 - ca. 38.000 Lux
Allerdings nur, wenn er direkt beleuchtet wird.
Wenn im Außensensor die Lichtfilterfolie benutzt wird, dann kommt nur noch ca. 26% licht zum Sensor durch. Daher muss man das dann entsprechend umrechnen.
Unter 100 gebe ich die Werte mit Kommastelle aus, da man dann auch sehr dunkle Beleuchtung bewerten kann.
Werte über 100 werden auf volle Dezimalzahlen gerundet.
Habe gerade wieder versucht. Es wird 65537 geliefert.
Ok,
ich danke euch für die schnellen Infos. :)
Hallo !
Ich bin neu hier und nicht gerade der FHEM Freak (evtl. leider ;-) ).
Ich betreibe einen Innensensor mit der vollen Bestückung.
Als Gerät können die Werte per ccu2 auch dargestellt werden. Temperatur, Luftfeuchtigkeit, Luftdruck, Lichtstärke und Batteryvoltage.
Beim Aufzeichnen per Diagramme werden leider nur die Temperatur und Luftfeuchtigkeit getrackt werden. Da würde ich gerne auch die übrigen Werte tracken.
Dazu erkennen leider meine Android Apps Home24 und Homedroid können leider mit dem Sensor gar nichts anfangen.
Könnt Ihr mir helfen auch per Android mit dem Sensor zu "arbeiten" und alle Werte zu tracken?
THX
_cv
Hi,
Damit die Android Apps neue Geräte erkennen müssen die Entwickler sie in Ihren Apps bekannt machen.
Schreib die am besten direkt an.
Gruss Alfred
Moin!
Meine Sensoren laufen perfekt.
Einen Wunsch hätte ich aber noch. Und zwar eine sofortige Übertragung, wenn sich die Helligkeit um einen bestimmten (am besten einstellbaren) Wert ändert. Damit will ich z. B. erkennen, ob im Zimmer Licht angemacht wurde. Dann kann ich ggf. Rolladen früher herunterfahren lassen.
Technisch muss das schon gehen. Wäre es möglich, dies für eine der nächsten Firmwareversionen einzuplanen?
Viele Grüße,
Alexander
Technisch geht das ganz bestimmt...
Aber dafür müsste der Sensor die ganze Zeit "lauschen", was er nicht macht, da die Batterie länger als ein Monat halten soll. :-)
Wenn du natürlich die Version mit externer Stromversorgung hast, sieht die Sache wieder ganz anders aus.
Hm... Ich glaube, es geht besser. Wenn mich nicht alles täuscht, kann der Sensorchip genau so eine Veränderung erkennen und einen Interupt auslösen. Aber auch wenn nicht, der µC muss je alle paar Sekunden aufwachen... Dabei könnte man eine grobe, schnelle Messung anstossen. Ist dann auch quasi sofort. Klar, kostet das etwas Batterie, ich denke jedoch, dies wäre noch im Rahmen. ;)
Grüße,
Alexander
Zitat von: hexenmeister am 09 September 2014, 17:02:14
Wenn mich nicht alles täuscht, kann der Sensorchip genau so eine Veränderung erkennen und einen Interupt auslösen.
Genau so ist es.
Und der Sensor ist auch schon so entsprechend an den AVR angeschlossen.
Das muss halt noch firmwareseitig implemenitert werden.
Aus dem Datenblatt:
ZitatThe TSL256x devices also support an interrupt feature that simplifies and improves system efficiency by eliminating the need to poll a sensor for a light intensity value. The primary purpose of the interrupt function is to detect a meaningful change in light intensity. The concept of a meaningful change can be defined by the user both in terms of light intensity and time, or persistence, of that change in intensity. The TSL256x devices have
the ability to define a threshold above and below the current light level. An interrupt is generated when the value of a conversion exceeds either of these limits.
Aber, dann ist der Sensor auch ständig aktiv. Er verbraucht dann ständig ca. 250µA.
Daher wird man dann mit einer kürzeren Batterielaufzeit rechnen müssen.
ZitatAber auch wenn nicht, der µC muss je alle paar Sekunden aufwachen... Dabei könnte man eine grobe, schnelle Messung anstossen.
Das wiederum dauert je bis zu 500ms. Was dann ganz schön lange währ bei jedem Aufwachen.
Gruß
Dirk
Jo, 500mS wäre viel zu lange. Dies wäre mit einer Batterie wohl eher nicht machbar. Aber der andere Weg klingt gut. Auch mit verbrauch von 250µA dürfte der Sensor lange genug durchhalten. Wenn man bei einer Batterie ca. 2000mAh annimmt, dürfte doch fast ein Jahr zusammenkommen, oder? ;)
Wäre schon ein cooles Feature :)
ist der schwellwert für die interrupt variante eigentlich fest oder von der aktuellen helligkeit abhängig?
beim Innenraum sensor musste ich den schwellwert für das sofort senden von der aktuellen helligkeit abhängig machen sonst wird entweder im hellen oder im dunklen nicht vernünftig erkannt.
gruss
andre
Zitat von: justme1968 am 09 September 2014, 19:45:57
ist der schwellwert für die interrupt variante eigentlich fest oder von der aktuellen helligkeit abhängig?
Schau mal ins Datenblatt. Aber es gibt 4 Threshold-Register THRESHLOWLOW, THRESHLOWHIGH, THRESHHIGHLOW, THRESHHIGHLOW.
Für Low- und High-Threshold gibt es je 2 Bytes. Hier kann man wohl eine Helligkeit programmieren bei deren Unter- Überschreitung der Sensor einen Interrupt auslöst.
Das Programmieren der Register muss man natürlich selber vornehmen.
Und je nachdem wie man das macht wird der Sensor dann auf absolute oder relative Helligkeitsänderungen auslösen.
Klingt ja echt gut ;)
Und zur Not könnte man ja bei jedem Sende-Akt auch gleich die Register an die aktuelle Verhältnisse anpassen. Wenn ich aber richtig verstanden habe, sind solche Kunstkniffe gar nicht erst nötig ;)
Zitat von: hexenmeister am 09 September 2014, 20:10:09
Und zur Not könnte man ja bei jedem Sende-Akt auch gleich die Register an die aktuelle Verhältnisse anpassen. Wenn ich aber richtig verstanden habe, sind solche Kunstkniffe gar nicht erst nötig ;)
Ich denke genau so muss man es machen.
So ist der Sensor am flexibelsten einsetzbar.
Wenn ich wieder etwas Luft habe dann werde ich mich damit beschäftigen. Das stand ohnehin auf der Ideen-liste.
Ansonsten ist natürlich jeder eingeladen hier mit zu machen :)
ich habe nun weitere Erkenntnisse zum RSSI Wert und irgendwie wird es absolut nur schlechter..
Ich habe seit gestern Nacht 1 Uhr wieder die aktuelle Firmware drauf, der Sensor lief eigentlich aber dann gab es keine Werte mehr, obwohl er nicht draußen lag an der Stelle wo er eigentlich liegen sollte. Ich hatte ihn im Zimmer gelassen und erst heute morgen raus gebracht... aber schau mal den Plot, der ist grottig..
Eigentlich sehen die RSSI-Werte gar nicht sooo schlecht aus.
Hast du die Möglichkeit testweise mal ein anderes Interface zu testen, CUL, HM-LAN o.ä?
welche RSSI-Werte haben denn deine anderen Geräte?
die anderen Werte sind alle wesentlich besser...
Der Innen Sensor von dir den ich im Wohnzimmer einsetze hat den RSSI -56 habe mal einen Plot eingerichtet und werde morgen mal schauen
Der andere Innen Sensor liegt im Bad im OG und hat den RSSI -68
Was mich an dem Plot stört ist die lange gerade Linie bedeutet ja das er nichts empfangen hat, oder ..?
Also wenn ich mir das log anschaue ist da zwischen 12.10 Uhr und 19.24 Uhr nichts, keine Messwerte. Das meinte ich
2014-09-09_19:24:37 Aussensensor_Terrasse pressure-nn: 1041
2014-09-09_19:24:37 Aussensensor_Terrasse pressure: 1013
2014-09-09_19:24:37 Aussensensor_Terrasse luminosity: 14.68
2014-09-09_19:24:37 Aussensensor_Terrasse battery: ok
2014-09-09_19:24:37 Aussensensor_Terrasse temperature: 18.7
2014-09-09_19:24:37 Aussensensor_Terrasse rssi_at_HMUSB: -80
2014-09-09_12:25:45 Aussensensor_Terrasse Activity: dead
2014-09-09_12:10:16 Aussensensor_Terrasse T: 21.0 L: 514 P: 1014 P-NN: 1042 batVoltage: 2.91
2014-09-09_12:10:16 Aussensensor_Terrasse batVoltage: 2.91
2014-09-09_12:10:16 Aussensensor_Terrasse pressure-nn: 1042
2014-09-09_12:10:16 Aussensensor_Terrasse pressure: 1014
2014-09-09_12:10:16 Aussensensor_Terrasse luminosity: 514
2014-09-09_12:10:16 Aussensensor_Terrasse battery: ok
Hallo,
schau doch einfach mal in den Log (Text). Dann kannst Du sehen ob Daten da sind. Der Plot ist ja nur eine Visualisierung der Logdaten.
Gruß Christoph
Das ist der Auszug aus dem log Text, deshalb habe ich ihn ja rein gesetzt. Es fehlen Messages in der von mir erwähnten Zeit, es gibt noch eine längere Pause, aber es reicht ja aus wenn ich hier einen kleinen Auszug darstelle...
Hallo,
Dirk super arbeit bei mir laufen die Sensoren soweit. Letzte Nacht hatte ich aber einen komischen Peek
3 Sensoren hatten zwischen 4:15-25 Uhr Helligkeitswerte über 6000 und Spannungen über 40V.
Das halte ich beides für Fehler.
Konnte das schon ein anderer beobachten?
Andere Sensoren laufen am gleichen IO-Device ohne Auffälligkeit. (BTW wie kann ich sehen über welches Device die Nachricht kam?) Die Frage kommt wg ccu mit 2 Devices CUL_HM und HM-USB via HMLAND
Aktuell sollen alle via hmlan reinkommen.
BTW. Jetzt habe ich auch endlich den einen Sensor frei zum Testen mit dem Bewegungsmelder. Zur Verbrauchsanalyse läuft der ja schon länger mit (ja, ich weiss mit Programm wird das kürzer wg Verbrauch durch CPU) Aber irgendwie komme ich Verständnis mässig da nicht rein mal sehen wenn etwas Luft ist.
Nico
Hallo,
Peaks bei der Helligkeit hatte ich auch schon zweimal. Einmal mitten in der Nacht (10:00) nach oben und einmal Mittags nach unten.
Wenn das pro Woche einmal auftritt, kann ich das verschmerzen.
Gruß Christoph
PS seitdem der Innensensor weiter von dem Differenz-Temperatursensor weg liegt, gibt es keine Störungen oder Ausfälle mehr.
Zitat von: moonsorrox am 09 September 2014, 23:33:30
die anderen Werte sind alle wesentlich besser...
Hm, ich hatte bisher angenommen dass du mit allen Sensoren die Probleme hast.
Also wenn nur dieser eine Sensor hier so ein ungewöhliches Verhalten zeigt, dann könnte hier tatsächlich ein Problem am Funkmodul vorliegen.
Zitat von: santalaus am 10 September 2014, 10:15:56
Letzte Nacht hatte ich aber einen komischen Peek 3 Sensoren hatten zwischen 4:15-25 Uhr Helligkeitswerte über 6000 und Spannungen über 40V.
Das halte ich beides für Fehler.
Mit Sicherheit. Wie waren diese Fehler zeitlich verteilt?
ZitatBTW wie kann ich sehen über welches Device die Nachricht kam?
Es sollte ein Reading "LASTInputDev" geben.
Zitat von: Bennemannc am 10 September 2014, 10:24:16
Peaks bei der Helligkeit hatte ich auch schon zweimal. Einmal mitten in der Nacht (10:00) nach oben und einmal Mittags nach unten.
Hm, das müsste man mal weiter untersuchen.
Hat diese Peaks noch jemand?
Ich bekomme die Werte meiner in Produktion befindlichen Sensoren über XML-RPC von einer CCU1 in FHEM eingeliefert.
Hier hatte ich das Verhalten noch nicht. Ich werde mal sehen dass ich diese mal noch parallel über den CUL oder HM-LAN empfange.
Zitat von: Dirk am 10 September 2014, 11:31:58
Hat diese Peaks noch jemand?
Hej Dirk,
hab gerade die Plots der letzten sieben Tage meiner drei "produktiv" laufenden Sensoren angesehen:
Kein einziger Ausreißer zu finden. ;-)
Zitat von: Dirk am 10 September 2014, 11:31:58
Hm, ich hatte bisher angenommen dass du mit allen Sensoren die Probleme hast.
Also wenn nur dieser eine Sensor hier so ein ungewöhliches Verhalten zeigt, dann könnte hier tatsächlich ein Problem am Funkmodul vorliegen.
Hallo Dirk, nein es geht
einzig und allein um den Außensensor, die anderen funktionieren, ich hänge dir mal im Vergleich zwei Plots ran einmal der Innensensor der in etwa in der gleichen Entfernung (ca.2m kürzer) arbeitet wie der Außensensor, aber tadellos funktioniert.
Deshalb habe ich ja das wechseln mit der Firmware veranstaltet um es zu testen, aber es ist wie du siehst eher schlechter geworden... wobei es vorher auch nicht viel besser war.
Also um es kurz zu machen, der Außensensor hat sich gestern kurz vor 23 Uhr komplett verabschiedet und hat sie wie im Plot zusehen heute gegen 10.15 Uhr wieder gemeldet...
Batterien waren extra erneuert vor dem letzten Firmwarewechsel.
Zitat von: Dirk am 10 September 2014, 11:31:58
Mit Sicherheit. Wie waren diese Fehler zeitlich verteilt?
Es sollte ein Reading "LASTInputDev" geben.
Hm, das müsste man mal weiter untersuchen.
Hat diese Peaks noch jemand?
Ich bekomme die Werte meiner in Produktion befindlichen Sensoren über XML-RPC von einer CCU1 in FHEM eingeliefert.
Hier hatte ich das Verhalten noch nicht. Ich werde mal sehen dass ich diese mal noch parallel über den CUL oder HM-LAN empfange.
S1-BatVoltage 4:18 35V
S2-BatVoltage 4:20:40 32V
S3-BatVoltage 4:19 42V
S1-luminosity 4:18 ca 6500
S2-luminosity 4:21+4:23:30 ca 6500
S3-luminosity 4:19+4:21 ca6500
Bei der Helligkeit siehts nach einem Überlauf aus.
[Nachtrag]: heute einer der Sensoren wieder. Bat + Helligkeit Der steht aber etwas anders und hat frisch geladene Akkus gestern Abend bekommen (die alten waren bei 2,3V nicht dramatisch, aber es waren keine eneloops) Leider kann ich das LastDev nciht sagen da ich ja erst nach entlichen übertragungen später mitbekome, das etwas passiert.
Oder könnte ein FHEM Update der letzten Tage verantwortlich sein?
[/]
Nico
Ich muss jetzt doch mal was schreiben. Ich schaue immer wieder mal in den Thread in der Hoffnung durchzublicken. Und dann denk ich mir puh ok die 60 Seiten muss ich irgendwann mal in Ruhe durchackern. Im FHEMwiki steht auch einiges. Aber es gibt so ein paar Informationen die mir total fehlen und auch im Wiki nicht zu finden sind. Natürlich kann ich mir auch nur wünschen das jemand der mehr im Thema ist das noch etwas ausführlicher beschreibt.
Mir stellen sich folgende Fragen (vielleicht ist das auch erst "Final" Geplant:
- Wird es noch mal Platinen zu bestellen geben, oder gibt es diese sogar?
- Gibt es eine fertig kompilierte Firmware?
- Gibt es irgendwo ein Howto zum zusammenbauen, kompilieren, aufspielen der Firmware
- Was für Bauteile sind schon auf der Platine und was muss ich selber besorgen drauf löten
- Gibt es vielleicht sogar eine grobe Kostenaufstellung von jemandem?
- Welche Größe haben die passenden Gehäuse
Danke :-)
ich antworte dir mal muss das nur alles mal kurz zusammen suchen
Zitat von: strauch am 11 September 2014, 15:21:06
Mir stellen sich folgende Fragen (vielleicht ist das auch erst "Final" Geplant:
- Wird es noch mal Platinen zu bestellen geben, oder gibt es diese sogar?
- Gibt es eine fertig kompilierte Firmware?
- Gibt es irgendwo ein Howto zum zusammenbauen, kompilieren, aufspielen der Firmware
- Was für Bauteile sind schon auf der Platine und was muss ich selber besorgen drauf löten
- Gibt es vielleicht sogar eine grobe Kostenaufstellung von jemandem?
- Welche Größe haben die passenden Gehäuse
zu 1. das kann nur Dirk sagen
zu 2. die ändert sich evtl. noch aber es ist ja eine drauf die funktioniert
zu 3. siehe unten die Liste, evtl. wird das Wiki erweitert, eine kleine Anleitung gibt es in Beitrag #930
zu 4. siehe unten die Liste
zu 5. siehe unten die Liste
zu 6. ich messe mal...! warte
Innengehäuse L70 x B70 x H25
Aussengehäuse L65 x B55 x H35
Zitat von: strauch am 11 September 2014, 15:21:06
das hier ist die AUfstellung von Dirk:
ZitatHallo alle zusammen,
In dieser Liste findest du die Grundpreise für die bestückten Platinen, aller bisherigen Erweiterungsmöglichkeiten und weitere Informationen.
ie Bestückungsvarianten kannst du dir selber zusammenstellen. Weiter unten habe ich ein paar fertige Bestückungsbeispiele incl. der Preise aufgelistet.
Grundplatinen (ohne Gehäuse, MAX und Sensoren):
18,00 € Innensensor mit Funkmodul, Batterie
21,50 € Innensensor mit Funkmodul, externer Spannungsversorgung 7 - 24V (kein Batteriehalter)
18,50 € Innensensor mit RS485-Tranceiver und externer Spannungsversorgung 7 - 24V (kein Batteriehalter)
17,00 € Außensensor mit Funkmodul und Batteriehalter
Gehäuse:
2,50 € Innen weiß (Elfenbein 2,70 € oder schwarz 2,50 € sind auch möglich)
4,00 € Außen grau mit transparenter Deckel, wasserdicht / luftdicht
Sensoren und Max1724:
4,40 € Max1724, Spule usw.
7,50 € SHT10 (Temperatur / Feuchte)
9,50 € SHT10 (Temperatur / Feuchte) mit Breakout-Board (z.B. für den Außensensor)
5,00 € BMP180 (Luftdruck / Temperatur)
3,50 € TSL2561 (Helligkeit)
Zubehör:
5,00 € USB-Serial-Adapter mit Kabel (wird für das serielle Flashen benötigt)
0,30 € 14-Polige Pinleiste (kann man wie benötigt kürzen)
Beispiele für Sensorvarianten
Hier sind ein Paar Beispiele für verschiedene Ausstattungen / Bestückungsvarianten.
01. 20,50 € Funk-Innensensor, Batterie ohne Sensoren, ohne MAX1724, mit Gehäuse weiß
02. 32,00 € Funk-Innensensor, Batterie mit Temperatur / Feuchte, MAX1724, Gehäuse weiß
03. 35,50 € Funk-Innensensor, Batterie mit Temperatur / Feuchte, Helligkeit, MAX1724, Gehäuse weiß
04. 33,00 € Funk-Innensensor, Batterie mit Temperatur / Feuchte, Luftdruck, Gehäuse weiß
05. 37,00 € Funk-Innensensor, Batterie mit Temperatur / Feuchte, Luftdruck, MAX1724, Gehäuse weiß
06. 40,50 € Funk-Innensensor, Batterie mit Temperatur / Feuchte, Luftdruck, Helligkeit, MAX1724, Gehäuse weiß
11. 24,00 € Funk-Innensensor, externer Spannungsversorgung ohne Sensoren, mit Gehäuse weiß
12. 31,50 € Funk-Innensensor, externer Spannungsversorgung mit Temperatur / Feuchte, Gehäuse weiß
13. 35,00 € Funk-Innensensor, externer Spannungsversorgung mit Temperatur / Feuchte, Helligkeit, Gehäuse weiß
14. 36,50 € Funk-Innensensor, externer Spannungsversorgung mit Temperatur / Feuchte, Luftdruck, Gehäuse weiß
15. 40,00 € Funk-Innensensor, externer Spannungsversorgung mit Temperatur / Feuchte, Luftdruck, Helligkeit, Gehäuse weiß
21. 21,00 € Funk-Außensensor, Batterie ohne Sensoren, ohne MAX1724, Gehäuse grau
22. 28,50 € Funk-Außensensor, Batterie mit Helligkeit, MAX1724, Gehäuse grau
23. 26,00 € Funk-Außensensor, Batterie mit Temperatur / Luftdruck, MAX1724, Gehäuse grau
24. 30,00 € Funk-Außensensor, Batterie mit Temperatur / Luftdruck, MAX1724, Gehäuse grau
25. 33,50 € Funk-Außensensor, Batterie mit Temperatur / Luftdruck, Helligkeit, MAX1724, Gehäuse grau
31. 21,00 € RS485-Innensensor ohne Sensoren, mit Gehäuse weiß
32. 28,50 € RS485-Innensensor mit Temperatur / Feuchte, Gehäuse weiß
33. 33,50 € RS485-Innensensor mit Temperatur / Feuchte, Luftdruck, Gehäuse weiß
34. 32,00 € RS485-Innensensor mit Temperatur / Feuchte, Helligkeit, Gehäuse weiß
35. 37,00 € RS485-Innensensor mit Temperatur / Feuchte, Luftdruck, Licht, Gehäuse weiß
Die Versandkosten liegen dann bei 2,90 (Maxibrief), 4,50 (Päckchen) oder 5,50 € Packet)
In den Maxibrief passen nur wenige Innensensoren. Das Gehäuse für den Außensensor ist für den Maxibrief zu hoch.
Bei der Lieferung des Sensors mit Helligkeitssensors ist bei beim Innensensor jeweils ein Acrylstab dabei, bei den Außensensoren jeweils eine Filterfolie.
Der Bootloader:
Ich habe es die letzten Tage geschafft für das Board den OTAU-Bootloder zu portieren. Ich werde die Boards mit Funk-Modul daher vermutlich schon mit dem OTAU-Bootloader versenden. Der Firmwareupdate per Funk funktioniert meines Wissens nach aber nicht mit dem "alten" HM-LAN Adapter. Dazu braucht man entweder einen CUL oder einen HM-CFG-USB Adapter. Mit einer CCU2 sollte das dann auch funktionieren. Hier steht aber noch der Test aus.
Ich kann auf Wunsch dir aber auch den seriellen Bootloader flashen. Dann ist eine Firmwareupdate immer über den USB-Serial-Adapter möglich.
Bei der RS485-Version wird derzeit der serielle Bootloader installiert sein. Der Bootloader um über den Wired-Bus zu Updaten ist nämlich noch nicht fertig.
Ein späteres Update des Bootloaders ist über die ISP-Pins möglich. Entweder über einen ISP-Prorammieradapter oder auch mit dem Raspberry Pi und ein paar Kabeln. Das werde ich im Wiki noch beschreiben.
Die Firmware:
Die Firmware für den Funksensor ist bereits fertig und funktionsfähig.
Die Firmware für die RS485-Version ist noch experimentell und in Entwicklung.
Bestellung:
Für eine Verbindliche Bestellung brauche ich von dir:
Die "Bestellnummer" aus den Beispielen oben oder falls die gewünschte Variante nicht dabei ist eine Auflistung der gewünschten Platinenversion und ggf. der zu bestückenden Sensoren
evtl. das Zubehör wenn benötigt
der gewünschte Bootloader für die Funk-Version (OTAU oder Seriell). Standardmäßig werde ich die Sensoren mit dem OTAU
Die gewünschte Gehäusefarbe für den Innensensor. Standartmäßig werde ich das Weiße Gehäuse versenden.
Die gewünschte Zahlungsart.
Und natürlich eure Lieferadresse.
Lieferzeit:
Ich versuche die Platinen nach euren Wünschen entsprechend schnell zu bestücken und zu liefern. Da ich das ganze aber nebenbei als Hobby mache, kann es ggf. eine Weile dauern. Ich werde die Bestellungen der Reihe nach abarbeiten. Falls es längere Verzögerungen geben sollte, sage ich auf alle Fälle bescheid.
Zitat von: strauch am 11 September 2014, 15:21:06
- Wird es noch mal Platinen zu bestellen geben, oder gibt es diese sogar?
- Gibt es eine fertig kompilierte Firmware?
Ja und Ja
Zitat- Gibt es irgendwo ein Howto zum zusammenbauen, kompilieren, aufspielen der Firmware
Noch nicht komplett. Ist aber in Arbeit. In der Regel ist die FW aber schon drauf.
Zitat- Was für Bauteile sind schon auf der Platine und was muss ich selber besorgen drauf löten
Alles wichtige ist schon bestückt. Es sei denn du orderst einen Komplettbausatz. Aber auch hier kann man einen Vorbestückungsgrad vorab besprechen.
Zitat- Gibt es vielleicht sogar eine grobe Kostenaufstellung von jemandem?
Je nach Ausstattung der Sensoren liegen die Kosten um die 20-40 €
Zitat- Welche Größe haben die passenden Gehäuse
Innengehäuse: 67mm x 67mm x 23mm
Außengehäuse: 58mm x 64mm x 35mm
Vielen Dank für die ausführlichen Antworten, das macht vieles klarer. Ein bisschen was hab ich mir zwar auch schon mit Arduinos gebastelt, ich brauch aber immer einen LAN Anschluss. Über Homematic ist einfach interessant. Dann werde ich jetzt mal aufpassen und beim nächsten mal einen Außensensor mitbestellen ist einfach ein tolles Projekt.
Irgendwann ist im github die Beschreibung der Sensorplatinen (Schema) verschwunden.
https://github.com/kc-GitHub/Wettersensor/raw/master/Schematic/Universalsensor-CC1101-Schematic.pdf
Und so sieht es aus, wenn dem Sensor der Saft ausgeht...
(http://up.picr.de/19501064ll.png)
Zitat von: betateilchen am 12 September 2014, 22:29:26
Irgendwann ist im github die Beschreibung der Sensorplatinen (Schema) verschwunden.
Da hab ich wohl den Link nicht aktualisiert:
https://github.com/kc-GitHub/Wettersensor/raw/master/Schematic/Schematic-RF.pdf
Hallo Dirk,
dieses Schema hatte ich schon gefunden, das ist aber nicht die Platine, die ich hier habe und für die ich heute die Anschlußbelegung gesucht habe.
Da fehlte die zweite Seite.
Ich habe die Datei aktualisiert.
Danke.
Irgendwie gibts im Wiki inzwischen mehrere Seiten zu dem Sensor...
http://www.fhemwiki.de/wiki/Universalsensor
http://www.fhemwiki.de/wiki/Universalsensor-THPL
http://www.fhemwiki.de/wiki/HB-UW-Sen-THPL
Seid heute den THP Sensor in Betrieb :)
Kleiner, huebscher als der HMS, mehr Informationen noch dazu. Was will man mehr? =)
Habe heute einen kleinen Vergleich der Lichtempfindlichkit der Innen- und Außen-Version angestellt.
Zwei Sensoren nebeneinander und ein wenig loggen...
Aussen Innen Faktor
36,8 61,5 0,598
37,8 63,8 0,592
28,9 54,7 0,528
37,8 67,3 0,562
37,0 66,7 0,555
36,8 67,8 0,543
09,8 18,9 0,519
03,6 06,7 0,537
04,0 07,2 0,556
04,8 08,6 0,558
Min 0,5185185185
Max 0,5983739837
DSchn 0,5547873585
Ist natürlich recht grob, aber erlaubt eine Abschätzung für einen Korrekturfaktor...
attr CUL_HM_HB_UW_Sen_THPL_O_XXXXXX userReadings normalizedLuminosity {my $t=ReadingsVal($name,"luminosity",-0.55)/0.55;;int($t*100+0.5)/100;;}
Damit laufen meine zunächst 'synchron'...
@Dirk: Sind noch Außensensoren verfügbar?
Zitat von: Spezialtrick am 13 September 2014, 22:06:16
@Dirk: Sind noch Außensensoren verfügbar?
Ja.
Ich muss aktuell aus Zeitlichen Gründen aber 1-2 Wochen pause machen.
Daher verzögert sich der weitere Versand.
Kannst du mir die Preisliste schon mal zukommen lassen?
Ja, schick ich dir.
Ich habe gestern noch einen Bug gefunden, als ich einen Sensor die Temperatur im Gefrierschrank messen lassen wollte.
Die aktuelle FW kann leider keine Temperaturen < 0 °C übermitteln.
Im Git habe ich das schon gefixt.
Ich würde gern noch ein paar andere Sachen mit erledigen dann würde ich ein neues Release zur Verfügung stellen.
Bis es draußen unter 0 grad wird, habe ich ja noch ein paar Tage zeit :)
Gruß
Dirk
ZitatBis es draußen unter 0 grad wird, habe ich ja noch ein paar Tage zeit
Sage das nicht so laut. Du kennst doch deutsches Wetter ;D
@Dirk wenn du noch Platinen für Außensensoren hast würde ich auch eine nehmen. Auch erst in 2 Wochen, hat keine Eile.
Hi strauch,
ja, hab dir ne PM geschickt.
Meine beiden Sensoren (I und O) sind seit gestern erfolgreich aktiv. Super Arbeit!
Eine Frage hat sich ergeben: Warum wird beim Luftdruck die Auflösung verringert, also nur ganze hPa?
Liegt es an der verwendeten Methode HM::sendPeerWEATHER(), die nur uint16_t dafür vorsieht?
Der Sensor kann deutlich mehr.
Meine Sourcenanalyse dazu ergab:
- AskSin / Sensor_SHT10_BMP085_TSL2561.cpp
62 tPres = (uint16_t)(bm180->readPressure() / 100); => Verringerung der Auflösung
- AskSin / AskSinMain.h
class HM {
...
172 void sendPeerWEATHER(uint8_t cnl, uint16_t temp, uint8_t hum, uint16_t pres, uint32_t lux); => uint16_t für Druck
Gruß
Thomas
So ich bin mal wieder mit nervigen Fragen dabei. Wie muss ich mir das Breakoutmodul für den Außensensor vorstellen? Ich würde gerne die Außensensor in Vollbestückung nehmen. Das einzige was ich gefunden habe ist, dass jemand Löcher in das Gehäuse gebohrt hat und mit Funktionstextilen zugeklebt hat um die Luftfeuchtigkeit durchzulassen. Und jetzt überlege ob ich das auch so mache oder das Breakoutmodul nehme. Hat jemand ein Bild davon?!
@strauch: habe gerade kein Bild, aber das ist einfach eine kleine Platine (ca. 1,5x2 cm) mit dem aufgelöteten Sensor. Da der Sensor selbst SMD ist, brauchst du schon irgendein Breakoutboard.
Ok, also ist es dann so gedacht: Ich führe die Platine nach draußen über ein Kabel und dort in ein Nicht IP65 Gehäuse oder wie ist die Idee dahinter?
Ah im Wiki ist doch ein Bild:
http://www.fhemwiki.de/wiki/Datei:Universalsensor-CC1101-Aussen_platine.jpg
Ich frag mich ob der Sensor überhaupt IP65 geschützt sein muss, oder ob da nicht einfach mit einem Netz verschlossen Löcher in einem doppelten Gehäuse reichen. Z.B. Die Unterseite in eine Art Wanne zu stellen.
Zitat von: Polyboy am 16 September 2014, 13:14:15
Eine Frage hat sich ergeben: Warum wird beim Luftdruck die Auflösung verringert, also nur ganze hPa?
Ich glaube das liegt daran dass meine bisherige Luftdruckanzeige auch nur volle hPa anzeigt.
Ich denke das könnte ich in einem späteren FW-Update mal erweitern.
Zitat von: strauch am 16 September 2014, 15:22:25
Ich frag mich ob der Sensor überhaupt IP65 geschützt sein muss, oder ob da nicht einfach mit einem Netz verschlossen Löcher in einem doppelten Gehäuse reichen. Z.B. Die Unterseite in eine Art Wanne zu stellen.
Mann kann auch einen Innensensor raus stellen, wenn er Regengeschützt angebracht wird.
Viele Grüße
Dirk
jet, das ist das richtige Bild.
Das Problem ist jedoch ein ganz anderes. Das dichte Gehäuse ist noch lösbar, aber Du willst damit doch auch Lichtintensität messen? Also muss da in die Sonne. Damit würde sich der Sensor auheiten und die Werte für T und H sind Mist.
Zitat von: Dirk am 16 September 2014, 15:32:11
Mann kann auch einen Innensensor raus stellen, wenn er Regengeschützt angebracht wird.
Also bislang kann ich das nur unterschreiben. Klappt super. :-)
Volle hPa halte ist fürs ausreichend. WOzu noch höhere Genauigkeit? Anwendungszweck? Außerdem würden die Werte zu sehr 'flattern', wenn man die volle genauigkeit nimmt. Das müllt den Log nur voll.
Zitat von: Dirk am 16 September 2014, 15:32:11
Mann kann auch einen Innensensor raus stellen, wenn er Regengeschützt angebracht wird.
Danke für die Info. Der würde bei mir unter einen Dachvorsprung kommen auf die Nordseite des Hauses, von der Regenseite her auch noch von der Dachrinne geschützt. Wie sind denn die Erfahrungen mit dem Helligkeitssensor? Ich möchte quasi das Sonnenlicht indirekt messen, klappt das oder muss er dafür voll in der Sonne stehen?
Klappt schon, Du kannst aber nicht so gut einfach einen hellen von einem SuperSonnigen Tag unterscheiden ;)
Da geht wohl auch probieren über studieren. Danke für die Rückmeldungen hat mir sehr geholfen, dann werde ich mal meine Bestellung..... ähh aufgeben. Aufgeben will ich eigtl. nicht ;-).
@Hexenmeister
ggf kann er das schon wenn er die Temperatur mit einbezieht ;)
@santalaus wenn man mit einer Schätzung zufrieden ist, dann braucht man doch gar kein Messgerät. Das WetterModul reicht. Spart viel Geld ;)
Zitat von: hexenmeister am 16 September 2014, 15:37:46
Volle hPa halte ist fürs ausreichend. WOzu noch höhere Genauigkeit? Anwendungszweck? Außerdem würden die Werte zu sehr 'flattern', wenn man die volle genauigkeit nimmt. Das müllt den Log nur voll.
Ich habe zwei Anwendungsfälle:
1. Drucktendenzen kurzfristig erkennen, also für eine sehr einfache Wettervorhersage nur über die Geschwindigkeit der Druckänderung.
2. Mein Haus hat eine zentrale Lüftungsanlage mit Wärmetauscher. Durch geschicktes Positionieren von zwei Drucksensoren in den Zuluft- und Abluftkanälen kann man durch Messung von Druckunterschieden feststellen, ob die Luftfilter gereinigt werden müssen. Meine Tests haben dazu ergeben, dass dafür eine Auflösung von 0,1 hPa benötigt wird. Der verwendete Sensor hat nach Datenblatt in dem verwendeten Mode (ultra high resolution mode) eine Auflösung von 0,02 hPa (RMS noise expressed in pressure).
Die Argumentation mit dem Flattern und Zumüllen des Logs würde doch für alle Sensoren gelten, insbesondere für die Helligkeit.
Ich meine, es sollte die Auflösung der verwendeten Sensoren übertragen werden, um nicht Anwendungsfälle einzuschränken.
Gruß
Thomas
@Dirk bis wann möchtest du denn eine Rückmeldung zur Bestellung? Ich würde gerne das Wochenende noch gedanklich nutzen.
Zitat von: Polyboy am 18 September 2014, 07:37:42
Die Argumentation mit dem Flattern und Zumüllen des Logs würde doch für alle Sensoren gelten, insbesondere für die Helligkeit.
Ich meine, es sollte die Auflösung der verwendeten Sensoren übertragen werden, um nicht Anwendungsfälle einzuschränken.
Schon recht, daher sind diese auch nicht in voller Auflösung übertragen. Die letzten Stellen haben einfach keinen SInn, da die Genauigkeit reicht einfach nicht mehr aus. Wozu das Rauschen übertragen. Ich habe mal mit BMP085 und BMP180 getestet, weiß aber nicht mehr, wo die Ssinnvolle Grenze lag, ich meine mich zu erinnern, dass bei 0,1 hPa nichts mehr stabil war. Daher wird Deine Messung nicht funktionieren. Ich daneke auch nicht, dass 2 Solche Sensoren genug nah an einander justiert sind, um 0,1 hPa Unterschied sicher zu erkennen.
Wie gesagt, alle HM-Sensoren übertragen Werte, die 'geglättet' und in ihrer Genauigkeit auf sinnvolle Maße reduziert sind.
Zitat von: hexenmeister am 18 September 2014, 11:28:28
Wie gesagt, alle HM-Sensoren übertragen Werte, die 'geglättet' und in ihrer Genauigkeit auf sinnvolle Maße reduziert sind.
Ich bin auf dieses Projekt gekommen, weil eine kommerzielle Lösung für das Erkennen der Filterreinigung diese Luftdrucksensoren verwendet.
Im Rauschen von Sensoren verstecken sich noch Daten, die man z.B. durch einen Tiefpassfilter herausbekommt. Dafür braucht man aber die volle Auflösung. Der Tiefpassfilter kann in der Firmware oder in der Applikation (z.B. im Modul HMConfig_SenTHPL.pm) implementiert werden. Vermutlich wird zusätzlich eine Kalibrierung der Sensoren für mein Vorhaben notwendig sein.
Ich würde vorschlagen, dass die Firmware die volle Auflösung überträgt und die Applikation (z.B. im Modul HMConfig_SenTHPL.pm) glättet, einfach durch Runden mit Auflösungsverlust oder durch einen Tiefpassfilter mit Auflösungsgewinn.
Falls die Rundung in der Firmware so bleibt, ist ja das Schöne an diesem Projekt, dass man selbst die Firmware seinen Wünschen anpassen kann.
Gruß
Thomas
Geringere Auflösung spart etwas Übertragungsvolumen. Bei Shared Medim Luft nicht ganz unwichtig.
Ich würde sagen, für dein (sehr speziellen) Einsatzzweck brauchst du extra Firmware.
Zitat von: strauch am 18 September 2014, 10:44:10
@Dirk bis wann möchtest du denn eine Rückmeldung zur Bestellung? Ich würde gerne das Wochenende noch gedanklich nutzen.
Da ich wohl erst ab nächstes Wochenende wieder neue Sensoren baue, hast du noch Zeit.
Zitat von: hexenmeister am 18 September 2014, 11:28:28
Schon recht, daher sind diese auch nicht in voller Auflösung übertragen. Die letzten Stellen haben einfach keinen SInn, da die Genauigkeit reicht einfach nicht mehr aus. Wozu das Rauschen übertragen. Ich habe mal mit BMP085 und BMP180 getestet, weiß aber nicht mehr, wo die Ssinnvolle Grenze lag, ich meine mich zu erinnern, dass bei 0,1 hPa nichts mehr stabil war. Daher wird Deine Messung nicht funktionieren. Ich daneke auch nicht, dass 2 Solche Sensoren genug nah an einander justiert sind, um 0,1 hPa Unterschied sicher zu erkennen.
Ich werde die Firmware so erweitern, dass der Druck mit 0.1 hPa Genauigkeit gesendet wird.
Die Daten werde ich in FHEM aber so wie bisher in vollen hPa ausgeben. Durch ein Attribute kann man das dann auf 0.1 hPa umschalten. Somit sollten alle glücklich sein :)
Viele Grüße
Dirk
Hallo Dirk,
kommende Woche ist bei uns Bodenfrost angesagt. Gibts schon eine Minusgradtaugliche Firmware? =)
Gruesse,
Markus
Zitat von: micomat am 19 September 2014, 10:47:34
kommende Woche ist bei uns Bodenfrost angesagt. Gibts schon eine Minusgradtaugliche Firmware? =)
Im Git ist die Änderung schon drinn.
Wenn ich es schaffe gibt es am Sonntag ein fertiges Release.
Folgende Sachen habe ich im Git noch geändert.
- Die Auflösung des Luftdrucks beträgt jetzt eine Nachkommastelle. Dazu müssen auch nicht mehr Bytes gesendet werden, da der Luftdruckwert bisher schon in 2 Bytes gesendet wurde. HMConfig_SenTHPL.pm ist hier auch schon angepasst. Die Auflösung lässt sich aber noch nicht per Attribut verringern. Auch das Addon für die CCU habe ich entsprechend geändert.
- Außerdem habe ich den Energieverbrauch noch etwas gesenkt. Bisher ist der Sensor noch bis zu eine Sekunde nach dem Senden einer Nachricht "wach". Dadurch war der Sensor pro Stunde etwa 40 Sekunden aktiv, der Rest im Standby. Nach der Änderung beträgt die Aktivzeit in einer Stunde nur noch ca. 20 Sekunden.
Hej Dirk,
gerade im Git gesehen, das der batVoltage immer noch im State-Register drinnen ist.
Hab ich das falsch in Erinnerung, oder sollte die nicht von dort raus fliegen? :-)
Zitat von: Mr. P am 20 September 2014, 02:30:49
Hab ich das falsch in Erinnerung, oder sollte die nicht von dort raus fliegen? :-)
Da hast du recht. Das kommt auch im kommenden Release.
Ich habe im Github dazu jetzt auch mal Isues angelegt, damit ich das im Auge behalte.
Hej Dirk,
weil es mir noch eingefallen ist, ich aber jetzt nicht eigenmächtig einen neuen Issue anlegen wollte, da ich nicht weiß, ob du das nicht vielleicht schon eingebaut hast: Aber wie sieht es denn mit der Möglichkeit aus, das Aufleuchten der LED während der Übertragungen konfigurierbar (aus/ein) zu machen?
Thx a lot! :-)
@Dirk: kannst Du mir bitte auch Infos zur Sammelbestellung/Beschaffung senden? Vielen Dank!
Zitat von: Mr. P am 21 September 2014, 02:22:41
weil es mir noch eingefallen ist, ich aber jetzt nicht eigenmächtig einen neuen Issue anlegen wollte, da ich nicht weiß, ob du das nicht vielleicht schon eingebaut hast:
Das kannst du gerne anlegen.
Zitat von: anli am 21 September 2014, 22:52:38
kannst Du mir bitte auch Infos zur Sammelbestellung/Beschaffung senden? Vielen Dank!
Du bekommst eine PM
Es gibt jetzt eine neue Firmware-Version 0.12
https://github.com/kc-GitHub/Wettersensor/releases/tag/v0.12
Changelog:Bugfix
- Negative Temperaturen werden jetzt korrekt gesendet
- Wenn der Sensor nicht gepairt ist, dann sendet er jetzt an Broadcast
- Nachrichten an Broadcast werden jetzt nicht mehr wiederholt und es wird auch nicht auf ein ACK gewartet.
Wenn der Sensor z.B. mit einer Zentrale (FHEM) gepairt ist, dann versucht er wie bisher bis zu 5 mal die Nachricht zu versenden.
- Die Batteriespannung wird nun nicht mehr automatisch in den State geschrieben
Verbesserungen
- Der Luftdruck hat jetzt eine Nachkommastelle.
- Der Lichtsensor arbeitet jetzt Interruptbassiert. Dadurch gibt es keine langen sleeps mehr im Code. Was auch der Batterielaufzeit zu gute kommt.
- Generell habe ich einige Optimierungen am Powermanagement vorgenommen.
Der Sensor misst und sendet etwa alle 2-3 Minuten Daten. Dafür wacht er aus dem Standby auf und bleibt dann für eine Zeit aktiv. Die Aktiv-Zeit konnte ich von ca. 1,6 Sekunden auf ca. 0,4 Sekunden verringern. Das sollte für eine ordentliche Steigerung der Batterielaufzeit sorgen.
- noch ein paar kleinere Änderungen
Bitte testet diese Version einmal.
Vor allem das zusammenspiel mit dem RT kann ich leider nicht testen.
Alle mit OTAU-Bootloader können für das Update dieses File benutzen:
HB-UW-Sen-THPL_update_V0_12_001_140922.eq3
Das File ist sowohl für den Innen- als auch für den Außensensor benutzbar
Für das Update über den dem seriellen Bootloader muss man diese Hexfiles benutzen:
Innensensor: HB-UW-Sen-THPL-I_update_V0_12_001_140922.hex
Außensensor: HB-UW-Sen-THPL-O_update_V0_12_001_140922.hex
Bitte nicht vergessen das neue
HMConfig_SenTHPL.pm - File ins FHEM-Verzeichniss zu kopieren.
Aber wenn die neue Firmware auf dem Sensor läuft.
Zitat von: martinp876 am 30 August 2014, 19:38:47
- batVoltage sollte m.E. nicht im State sein - ok, kann man einstellen... aber in state ist per default der "main-state" des device - das ist nicht Batterie
Das hab ich damit also wieder ausgebaut. Dadurch lässt sich die Batteriespannung aber nicht mehr so einfach loggen.
Hast du hier noch einen Vorschlag?
Zitat- das device ist demnach als conditionalBurst konzipiert. Demnach sollte man auch das Kommando burstXmit zulassen.
Konzipiert ist etwas "übertrieben". Da ich das aber ggf. unterstützen möchte, habe ich das noch nicht ausgebaut.
Zitat- register burstRx hat den Wert "255" (der 0xff). Wenn es eingeschaltet ist sollte es 0x01 sein - so ist es "üblich"
Daher ist das Burst-Zeugs noch nicht vollständig implementiert.
Zitat- der channelstate sollte (default) das gleiche beinhalten, wie der device state, daher erst am Ende schreiben
Das habe ich nicht verstanden.
Viele Grüße
Dirk
Hallo Dirk,
danke fuer die neue FW. Nur wie bekomme ich die OTA auf den Sensor? Irgendwie steh ich grad aufm Schlauch...
Gruß
Markus
Zitat von: micomat am 22 September 2014, 06:20:06
Nur wie bekomme ich die OTA auf den Sensor? Irgendwie steh ich grad aufm Schlauch...
Hier gibt es eine Anleitung für das Update:
http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update
Der Bootloader vom Sensor wird so gestartet:
- Batterie raus nehmen
- Config-Taste drücken und halten
- Batterie einlegen
- LED blinkt ein mal kurz.
- Config-Taste noch kurz gedrückt halten bis die LED fortlaufend blinkt. Das Blinken zeigt den Empfang eines Firmware-Paketes während des den Update-Prozesses an.
Zitat von: _cv am 08 September 2014, 23:44:31
...
Als Gerät können die Werte per ccu2 auch dargestellt werden. Temperatur, Luftfeuchtigkeit, Luftdruck, Lichtstärke und Batteryvoltage.
Beim Aufzeichnen per Diagramme werden leider nur die Temperatur und Luftfeuchtigkeit getrackt werden. Da würde ich gerne auch die übrigen Werte tracken.
...
Wenn Du eine CCU benutzt, dann könnte Dir CCU.IO http://ccu.io/addons.html#highcharts (http://ccu.io/addons.html#highcharts) helfen.
Zitat von: Dirk am 20 August 2014, 00:01:40
...
Man muss auch beachten das der OTA-Update aktuell nur mit HM-USB-CFG oder einem CUxx mit serieller Schnittstelle wie CUL oder CSM funktioniert. Mit der CCU2 sollte es später auch gehen, aber wohl nicht in Verbindung mit dem "alten" (runden) HM-LAN Adapter. Es sei denn der bekommt das nötige FW-Update.
...
Viele Grüße
Dirk
Zitat von: Dirk am 21 August 2014, 09:31:07
Vielleicht in 1, 2 oder 3 Wochen. Kann ich noch nicht genau sagen. Das muss ich noch testen. Ggf. brauche ich dazu Unterstützung da ich keine CCU2 habe.
Darf ich noch hoffen, das Update mittels CCU testen zu können ?
Zitat von: Dirk am 22 September 2014, 02:49:49
Vor allem das zusammenspiel mit dem RT kann ich leider nicht testen.
Das kann ich heute Abend gerne übernehmen. ;-)
Zitat von: Dirk am 22 September 2014, 02:49:49
Das hab ich damit also wieder ausgebaut. Dadurch lässt sich die Batteriespannung aber nicht mehr so einfach loggen.
Hast du hier noch einen Vorschlag?
Da bin ich auch drüber gestolpert. Problem ist aber nur, dass etwas Sparsam mit dem Zeilenumbruch umgegangen wurde und zwei Codezeilen in eine verfrachtet wurden:
- $stateMsg .= ' batVoltage: ' . $batVoltage; push (@events, [$shash, 1, 'batVoltage:' . $batVoltage]);
+ push (@events, [$shash, 1, 'batVoltage:' . $batVoltage]);Und schon passt es mit der Battery wieder. ;-)
Hallo Zusammen,
als Einsteiger ist es schwierig, eine Übersicht über den Stand der Entwicklung zu bekommen. Gibt es eine aktuelle Zusammenfassung / Wiki-Artikel hierzu?
Viele Grüße
Frank
Zitat von: cactus-online am 22 September 2014, 10:44:06
Darf ich noch hoffen, das Update mittels CCU testen zu können ?
Ich habe hier schon ein paar Sachen probiert.
Aktuell schein es so, dass die CCU2 nicht mit Geräten zurecht kommt bei denen man den Bootloader manuell starten muß.
Oder ich bekomme das aktuell nicht hin.
Ich teste hier aber noch weiter.
Zitat von: Mr. P am 22 September 2014, 10:45:31
Und schon passt es mit der Battery wieder. ;-)
Die Zeilen stammen aber aus der HMConfig_SenTHPL.pm vor dem Update.
in der aktuellen Version gibt es batVoltage nicht mehr im State.
Daher landet das dann so auch erstmal nicht im Logfile.
Oder habe ich dich da grade falsch verstanden?
Zitat von: Bastel-Frank am 22 September 2014, 10:59:37
als Einsteiger ist es schwierig, eine Übersicht über den Stand der Entwicklung zu bekommen. Gibt es eine aktuelle Zusammenfassung / Wiki-Artikel hierzu?
Ja. Aber der ist noch nicht ganz vollständig:
http://www.fhemwiki.de/wiki/Universalsensor
Zitat von: Dirk am 22 September 2014, 11:00:57
Die Zeilen stammen aber aus der HMConfig_SenTHPL.pm vor dem Update.
in der aktuellen Version gibt es batVoltage nicht mehr im State.
Daher landet das dann so auch erstmal nicht im Logfile.
Oder habe ich dich da grade falsch verstanden?
*argl* - Sorry. Sollte nicht Dinge zum Besten geben, solange ich nicht meinen ersten Kaffee getrunken habe. :-/
Hab zwar noch die alte Firmware drauf, aber schon mal das neue HMConfig-File eingespielt und da passt im Logfile noch alles:
2014-09-22_11:34:12 ws_01 temperature: 24.2
2014-09-22_11:34:12 ws_01 battery: ok
2014-09-22_11:34:12 ws_01 humidity: 56
2014-09-22_11:34:12 ws_01 luminosity: 20.01
2014-09-22_11:34:12 ws_01 batVoltage: 2.54
2014-09-22_11:34:12 ws_01 T: 24.2 H: 56 L: 20.01Hast du bei der Übertragung etwas geändert, dass bei der neuen Version die batVoltage verloren geht?
Zitat von: Mr. P am 22 September 2014, 12:09:32
Hast du bei der Übertragung etwas geändert, dass bei der neuen Version die batVoltage verloren geht?
Ok, ich habe mich etwas unverständlich ausgedrückt.
Das Logging funktioniert natürlich. Ich habe bei mir aus Platzgründen aber immer nur den State geloggt. da gibt es natürlich kein batVoltage mehr.
Wenn man die Einzelnen Readings auch mit loggt, so wie es die meisten wohl machen, dann ist alles ok.
Zitat von: Dirk am 22 September 2014, 12:39:07
Ok, ich habe mich etwas unverständlich ausgedrückt.
Das Logging funktioniert natürlich. Ich habe bei mir aus Platzgründen aber immer nur den State geloggt. da gibt es natürlich kein batVoltage mehr.
Wenn man die Einzelnen Readings auch mit loggt, so wie es die meisten wohl machen, dann ist alles ok.
Achso, ja. Das stimmt natürlich. Mach ich aus Platz- und Performancegründen (Plots werden plötzlich sehr performant, wenn nur noch State-Zeilen vorhanden sind) auch so. ;-)
Aber wenn man nicht gerade kontrollieren möchte, wie schnell die Akkus leer werden, finde ich, ist ein Logging der Voltage auch nicht zwingend notwendig.
Und im schlimmsten Fall könnte man einfach ein zweites FileLog erstellen, welches nur die batVoltage mitloggt. :-)
Zitat von: Dirk am 22 September 2014, 11:00:57
Ich habe hier schon ein paar Sachen probiert.
Aktuell schein es so, dass die CCU2 nicht mit Geräten zurecht kommt bei denen man den Bootloader manuell starten muß.
Oder ich bekomme das aktuell nicht hin.
Ich teste hier aber noch weiter.
Kann ich denn das Flash-Tool-Linux_RaspberryPi.tgz mit CUL auf einer CCU2 benutzen ?
Zitat von: cactus-online am 22 September 2014, 16:47:44
Kann ich denn das Flash-Tool-Linux_RaspberryPi.tgz mit CUL auf einer CCU2 benutzen ?
Also du hast einen CUL für CUXd an deiner CCU2?
Theoretisch sollte das funktionieren. Es könnte sogar sein, dass die Binaries vom Raspberry Pi so auf der CCU2 direkt laufen.
Du müsstest halt den CUXd vorher stoppen damit der CUL frei ist.
Hallo,
bin ich Blind oder ist es ein Fehler bei mir, das ich fwUpdate nicht als Option bei set auswählen kann?
Nico
Zitat von: santalaus am 22 September 2014, 18:33:46
bin ich Blind oder ist es ein Fehler bei mir, das ich fwUpdate nicht als Option bei set auswählen kann?
Ich vermute ich habe hier noch eine Magische Einstellung vergessen.
Ich schau mir das noch mal an.
Bis dahin könntest du das Update über das OTA-Tool durchführen.
was läuft falsch ?
FHEM ist gestoppt. diese Meldungen bekomme ich:
root@cubie:/opt/hmcfgusb# ./flash-ota -f HB-UW-Sen-THPL_update_V0_12_001_140922.eq3 -s UWS9333135
HomeMatic OTA flasher version 0.097-git
Reading firmware from HB-UW-Sen-THPL_update_V0_12_001_140922.eq3...
Firmware with 225 blocks successfully read.
Rebooting HM-CFG-USB to avoid running out of credits
HM-CFG-USB not in bootloader mode, entering bootloader.
Waiting for device to reappear...
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB in bootloader mode, rebooting
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB opened
HM-CFG-USB firmware too low: 964 < 967
Gruß Andreas
Update: HM-CFG-USB braucht ein FW Update ... mal sehen
Update 2: alles gut, nach FW Update des HM-CFG-USB auf 967 hat alles geklappt
Hallo Dirk,
kannst Du mir bitte auch Infos zur Sammelbestellung/Beschaffung senden? Vielen Dank!
Mfg
Thomas
Mir auch bitte
OTA Update ist ja cool 8)
6 Sensoren OTA upgedated und einen 'per wire'. Alles läuft. Ich werde bei Gelegenheit auch den mit Seriel-Bootloader mit dem OTAU versorgen ;)
Zitat von: santalaus am 22 September 2014, 18:33:46
bin ich Blind oder ist es ein Fehler bei mir, das ich fwUpdate nicht als Option bei set auswählen kann?
Ich habe im Github-Release das .pm-File angepasst.
fwUpdate und getSerial sind im Modul nun verfügbar.
ABER:
Leider klappt das OTA-Update nicht per FHEM. Mit dem flash-ota aud dem hmcfgusb Paket klappt es hingegen ausgezeichnet.
Hier mal ein Auschnitt aus dem Log vom Update-Versuch über FHEM. Vielleicht hat ja jemand eine Idee:
2014.09.22 21:28:33.509 2: CUL_HM fwUpdate CUL_HM_HB_UW_Sen_THPL_I_112233 entered mode. IO-speed: fast
2014.09.22 21:28:33.610 4: CUL_send: CULAs 0F 0B 00CB 1ACAE5 112233 105B11F81547
2014.09.22 21:28:33.681 4: CUL_send: CULAR
2014.09.22 21:28:33.764 4: CUL_send: CULAs 27 0D 00CA 1ACAE5 112233 00800C948A000C94A42D0C94D12D0C9456100C9431100C940C100C948414
2014.09.22 21:28:33.783 4: CUL_send: CULAs 27 0E 00CA 1ACAE5 112233 0C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94
2014.09.22 21:28:33.806 4: CUL_send: CULAs 27 0F 00CA 1ACAE5 112233 B2000C94B2000C94142E0C94B2000C94BB2B0C94092C0C94B2000C94B200
2014.09.22 21:28:33.817 4: CUL_send: CULAs 27 10 00CA 1ACAE5 112233 0C94B2000C94B2000C9420030C94B2000000000005000000009801010406
2014.09.22 21:28:33.827 4: CUL_send: CULAs 13 11 20CA 1ACAE5 112233 0501050000009D010063
2014.09.22 21:28:33.838 4: CUL_Parse: CUL A 0A 0D 8002 112233 1ACAE5 8040 -42
2014.09.22 21:28:33.838 4: CUL_Parse: CUL A 0A 0E 8002 112233 1ACAE5 8040 -42
2014.09.22 21:28:33.857 4: CUL_Parse: CUL A 0A 0F 8002 112233 1ACAE5 8041 -41.5
2014.09.22 21:28:33.861 4: CUL_Parse: CUL A 0A 11 8002 112233 1ACAE5 8041 -41.5
Use of uninitialized value $mNo in sprintf at /opt/FHEM/fhem.dev/FHEM/10_CUL_HM.pm line 5331.
2014.09.22 21:28:38.843 4: CUL_send: CULAs 27 01 00CA 1ACAE5 112233 00800C948A000C94A42D0C94D12D0C9456100C9431100C940C100C948414
2014.09.22 21:28:38.856 4: CUL_send: CULAs 27 02 00CA 1ACAE5 112233 0C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94
2014.09.22 21:28:38.872 4: CUL_send: CULAs 27 03 00CA 1ACAE5 112233 B2000C94B2000C94142E0C94B2000C94BB2B0C94092C0C94B2000C94B200
2014.09.22 21:28:38.890 4: CUL_send: CULAs 27 04 00CA 1ACAE5 112233 0C94B2000C94B2000C9420030C94B2000000000005000000009801010406
2014.09.22 21:28:38.902 4: CUL_send: CULAs 13 05 20CA 1ACAE5 112233 0501050000009D010063
2014.09.22 21:28:38.949 4: CUL_Parse: CUL A 0A 05 8002 112233 1ACAE5 8051 -33.5
Use of uninitialized value $mNo in sprintf at /opt/FHEM/fhem.dev/FHEM/10_CUL_HM.pm line 5331.
2014.09.22 21:28:43.946 4: CUL_send: CULAs 27 01 00CA 1ACAE5 112233 00800C948A000C94A42D0C94D12D0C9456100C9431100C940C100C948414
2014.09.22 21:28:43.965 4: CUL_send: CULAs 27 02 00CA 1ACAE5 112233 0C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94
2014.09.22 21:28:43.980 4: CUL_send: CULAs 27 03 00CA 1ACAE5 112233 B2000C94B2000C94142E0C94B2000C94BB2B0C94092C0C94B2000C94B200
2014.09.22 21:28:43.995 4: CUL_send: CULAs 27 04 00CA 1ACAE5 112233 0C94B2000C94B2000C9420030C94B2000000000005000000009801010406
2014.09.22 21:28:44.012 4: CUL_send: CULAs 13 05 20CA 1ACAE5 112233 0501050000009D010063
Use of uninitialized value $mNo in sprintf at /opt/FHEM/fhem.dev/FHEM/10_CUL_HM.pm line 5331.
2014.09.22 21:28:49.028 4: CUL_send: CULAs 27 01 00CA 1ACAE5 112233 00800C948A000C94A42D0C94D12D0C9456100C9431100C940C100C948414
2014.09.22 21:28:49.070 4: CUL_send: CULAs 27 02 00CA 1ACAE5 112233 0C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94
2014.09.22 21:28:49.083 4: CUL_send: CULAs 27 03 00CA 1ACAE5 112233 B2000C94B2000C94142E0C94B2000C94BB2B0C94092C0C94B2000C94B200
2014.09.22 21:28:49.101 4: CUL_send: CULAs 27 04 00CA 1ACAE5 112233 0C94B2000C94B2000C9420030C94B2000000000005000000009801010406
2014.09.22 21:28:49.112 4: CUL_send: CULAs 13 05 20CA 1ACAE5 112233 0501050000009D010063
2014.09.22 21:28:54.129 4: eventTypes: CUL_HM CUL_HM_HB_UW_Sen_THPL_I_112233 fwUpdate: fail:Block1 -> fwUpdate: fail:Block1
@BigMac und Markus, ich habe euch die Infos geschickt.
Gruß
Dirk
Zitat von: Dirk am 22 September 2014, 21:57:29
ABER:
Leider klappt das OTA-Update nicht per FHEM. Mit dem flash-ota aud dem hmcfgusb Paket klappt es hingegen ausgezeichnet.
Hier mal ein Auschnitt aus dem Log vom Update-Versuch über FHEM. Vielleicht hat ja jemand eine Idee:
Kann aber hoffentlich Martin demnächst etwas dazu sagen, woran es womöglich scheitert. :-)
An der Stelle jetzt aber auch von mir ein großes Danke für das Update! *thumbsUp*
Habe meine Sensoren jetzt alle geflasht und werde den weiteren Batterieverlauf im Auge behalten. Mal sehen, wie sie sich jetzt nach dem Update tun. ;-)
Eine Frage noch: besteht die Möglichkeit eine Funktion in die Firmware der Sensoren einzubauen, dass sie sich - analog zu den RTs - automatisch zu Flashbeginn neu starten und in den Bootloader begeben?
Nochmals vielen Dank für deine Bemühungen! :-)
Zitat von: Dirk am 22 September 2014, 17:30:42
Also du hast einen CUL für CUXd an deiner CCU2?
Theoretisch sollte das funktionieren. Es könnte sogar sein, dass die Binaries vom Raspberry Pi so auf der CCU2 direkt laufen.
Du müsstest halt den CUXd vorher stoppen damit der CUL frei ist.
OK, ich check' das mal und berichte dann.
Hallo,
ich verzweifle hier noch...
Hab jetzt endlich mein selbst zusammengebauten Wettersensor mit Firmware "bestücken" wollen.
Nach ettlichen Versuchen bin ich jetzt soweit, dass der Wettersensor.ino - Sketch mit folgender Fehlermeldung abbricht:
WetterSensor.cpp.o: In function `__static_initialization_and_destruction_0':
D:\download-nicht sync\fhem\arduino-1.0.5-r2full2\arduino-1.0.5-r2/WetterSensor.ino:61: undefined reference to `TSL2561::TSL2561()'
AskSin\Sensor_SHT10_BMP085_TSL2561.cpp.o: In function `Sensors_SHT10_BMP085_TSL2561::poll_measure()':
D:\download-nicht sync\fhem\arduino-1.0.5-r2full2\arduino-1.0.5-r2\libraries\AskSin/Sensor_SHT10_BMP085_TSL2561.cpp:48: undefined reference to `Sensirion::meas(unsigned char, unsigned int*, bool)'
D:\download-nicht sync\fhem\arduino-1.0.5-r2full2\arduino-1.0.5-r2\libraries\AskSin/Sensor_SHT10_BMP085_TSL2561.cpp:54: undefined reference to `Sensirion::meas(unsigned char, unsigned int*, bool)'
D:\download-nicht sync\fhem\arduino-1.0.5-r2full2\arduino-1.0.5-r2\libraries\AskSin/Sensor_SHT10_BMP085_TSL2561.cpp:61: undefined reference to `BMP085::begin(unsigned char)'
D:\download-nicht sync\fhem\arduino-1.0.5-r2full2\arduino-1.0.5-r2\libraries\AskSin/Sensor_SHT10_BMP085_TSL2561.cpp:62: undefined reference to `BMP085::readPressure()' usw....
Kann mir jemand sagen, was ich hier falsch mache?
Ich habe die Libraries in den libraries-Ordner kopiert. Als Arduino IDE setze ich die Version 1.0.5r2 ein.
Alternativ wollte ich die .hex-Dateien von Dirk's Tools/Firmware-Verzeichnis flashen - aber das sind ja nur die Updates!?! Gibt es da auch vollständige Firmware-HEX-Dateien??
Danke schonmal für eure Hilfe!!!!
Zitat von: thunder1902 am 23 September 2014, 10:26:08
Nach ettlichen Versuchen bin ich jetzt soweit, dass der Wettersensor.ino - Sketch mit folgender Fehlermeldung abbricht:
Ehrlich gesagt habe ich die letzten Versionen nicht mehr mit der Arduino-IDE kompiliert. Daher will ich hier Fehler nicht ausschließen.
Magst du das mal mit Eclipse probieren und dem Arduino - Plugin? Da die Arduino-IDE nur eine Krücke ist, kann ich das nur empfehlen.
ZitatAlternativ wollte ich die .hex-Dateien von Dirk's Tools/Firmware-Verzeichnis flashen - aber das sind ja nur die Updates!?! Gibt es da auch vollständige Firmware-HEX-Dateien??
Die Hex-Files sind komplett. Die kannst du also direkt flashen. Es wird dann die da eingebaute Default-Seriennummer benutzt. Alternativ flashst du mit dem Flash-Tool und über den seriellen Bootloader, dann kannst du HM-ID und Seriennummer beim Flashen mit angeben.
Zitat von: Mr. P am 23 September 2014, 01:12:15
Habe meine Sensoren jetzt alle geflasht und werde den weiteren Batterieverlauf im Auge behalten.
Hast du hier Vergleichswerte von vor dem Update?
Die Sensoren mit den AA-Batterien verhalten sich noch recht unauffällig. Lediglich bei Versorgung mit AAA-Zellen (Aussensensor) sind diese mit der alten FW nach etwa 6-8 Wochen erschöpft.
Bei meinem Außensensor ist das bald wieder so weit, dann bekommt der auch die neue FW. Dann kann ich das direkt vergleichen.
Zitatbesteht die Möglichkeit eine Funktion in die Firmware der Sensoren einzubauen, dass sie sich - analog zu den RTs - automatisch zu Flashbeginn neu starten und in den Bootloader begeben?
Das hatte ich auch noch vor. Allerdings muss man auch dann innerhalb von 10 Sekunden oder so, die Config-Taste drücken.
Da wir hier noch kein AES benutzen können, hatten wir den Bootloader so gebaut dass man diesen zwar per Funk aktivieren kann, man dann aber in einem Zeitfenster trotzdem einmal die Config-Taste drücken muss damit das Flashen startet. Damit soll verhindert werden, dass jemand unbefugtes die Devices "zerflashen" kann.
Zitat von: Dirk am 23 September 2014, 10:51:10
Hast du hier Vergleichswerte von vor dem Update?
Die Sensoren mit den AA-Batterien verhalten sich noch recht unauffällig. Lediglich bei Versorgung mit AAA-Zellen (Aussensensor) sind diese mit der alten FW nach etwa 6-8 Wochen erschöpft.
Bei meinem Außensensor ist das bald wieder so weit, dann bekommt der auch die neue FW. Dann kann ich das direkt vergleichen.
Das hatte ich auch noch vor. Allerdings muss man auch dann innerhalb von 10 Sekunden oder so, die Config-Taste drücken.
Habe leider nur die Innensensoren. Aber zumindest für die hab ich Vergleichswerte, ja. ;-)
Zitat von: Dirk am 23 September 2014, 10:51:10
Da wir hier noch kein AES benutzen können, hatten wir den Bootloader so gebaut dass man diesen zwar per Funk aktivieren kann, man dann aber in einem Zeitfenster trotzdem einmal die Config-Taste drücken muss damit das Flashen startet. Damit soll verhindert werden, dass jemand unbefugtes die Devices "zerflashen" kann.
Achso, ist so beabsichtigt. Gut, dann macht es zumindest für Devices, die man öffnen muss, um an den Config-Button zu kommen, ohnehin wenig Sinn. :-)
Zitat von: Mr. P am 23 September 2014, 11:13:58
Achso, ist so beabsichtigt. Gut, dann macht es zumindest für Devices, die man öffnen muss, um an den Config-Button zu kommen, ohnehin wenig Sinn. :-)
Na im Moment muss man ja noch die Batterie kurz rausnehmen um den Bootloader zu starten. Bei Netzbetriebenen Geräten Wie dem HM_LC_Sw1PBU_FM ist das aber unpraktisch. Da kann dann der Bootloader per Funk gestartet werden. Zum Bestätigen muss dann die Config-Taste gedrückt werden.
Bei Devices die man öffnen muss habe ich zur Config-Taste einen Reedkontakt Parallel geschaltet.
Dann kann man das auch mit einem Magneten starten.
Zitat von: Dirk am 23 September 2014, 11:21:11
Bei Devices die man öffnen muss habe ich zur Config-Taste einen Reedkontakt Parallel geschaltet.
Dann kann man das auch mit einem Magneten starten.
Das macht die Sache schon wieder ein ganz schönes Stück attraktiver!
Musst mir bei Gelegenheit mal näher erklären! :-)
Hallo Dirk,
Danke für den Tip!
Arduino-IDE: Ok, ich probier das mal mit Eclipse und dem Arduino-Modul...
ZitatDie Hex-Files sind komplett. Die kannst du also direkt flashen. Es wird dann die da eingebaute Default-Seriennummer benutzt. Alternativ flashst du mit dem Flash-Tool und über den seriellen Bootloader, dann kannst du HM-ID und Seriennummer beim Flashen mit angeben.
Ich hab jetzt mal das Hex-File geflasht. Im Serial-Monitor seh ich in periodischen Abständen immer ein paar Kauderwelsch-Buchstaben.
Kann es sein, dass man den Quarz beim Arduino Mini Pro noch mittels den Fuses abschalten muss??
Zitat von: thunder1902 am 23 September 2014, 13:56:34
Kann es sein, dass man den Quarz beim Arduino Mini Pro noch mittels den Fuses abschalten muss??
Was für einen Quarz hast du da denn?
Die Hexfiles sind für 8 Mhz gebaut.
Wenn du eine 16 Mhz-Version vom Arduino hast, dann stimmt das Timing Definitiv nicht.
Dann stelle die Fuses für den AVR mal auf internen Oszilator und 8 Mhz. Den Quarz brauchst du nicht.
Vergiss dann aber nicht einen für 8 Mhz passenden Bootloader zu flashen.
Hallo Dirk,
ich habe ein Arduino Mini Pro 3,3V, 8MHZ.
Hab den seriellen Bootloader geflasht, und danach das Firmware-Hex-File drauf.
Habs mal mit einfacher serieller Ausgabe probiert (serial.begin, serial.print...). Funktioniert. Es muss also irgendein Timing-Problem sein.
Für welchen Arduino hast du das Hex-File konzipiert?
Die Fuses hab ich jetzt nach diesem Forums-Eintrag geflasht: http://forum.fhem.de/index.php/topic,20620.msg193823.html#msg193823
Trotzdem krieg' ich nur Kauderwelsch auf die serielle Konsole....
Zitat von: thunder1902 am 23 September 2014, 14:29:05
ich habe ein Arduino Mini Pro 3,3V, 8MHZ.
Für welchen Arduino hast du das Hex-File konzipiert?
Auf den Sensoren ist ein Atmega328p. Auf dem Arduino Mini Pro auch. also sollte das passen.
Der bei einem neuen Atmega328p ist allerdings die Fuese CKDIV8 gesetzt. Somit taktet der nur mit 1 Mhz.
ZitatDie Fuses hab ich jetzt nach diesem Forums-Eintrag geflasht: http://forum.fhem.de/index.php/topic,20620.msg193823.html#msg193823
Dann aber sollte es passen.
ZitatTrotzdem krieg' ich nur Kauderwelsch auf die serielle Konsole....
Dein Terminalprogram ist auch auf 57600,8,N,1 eingestellt?
Hallo Dirk!
Es läuft!!
Ich habe nocheinmal die Fuses gesetzt, danach die Firmware geflasht, und auf einmal begann die LED zu blinken!
Riesen RESPEKT vor Deiner grandiosen Arbeit!!
Ein Problem habe ich aber noch: Die Batteriespannung wird immer 0,6Volt zu gering angezeigt.. Meine Vermutung war zuerst, dass ich den RAW + Eingang des Arduino-Mini-Pro benutzt habe. Dem ist aber nicht so. Die Dauer-LED habe ich schon "eliminiert".
Hast du eine Idee was das noch sein könnte??
Hm... jemand in Suedbayern in der Naehe, der meinen updaten koennte? :D
Bin mit meinem HMLAN sehr zufrieden und moechte eigentlich ungern auf den HM-CFG-USB(2) umsteigen...
Ansonsten muss ich ihn wohl zum Service einschicken ;)
Zitat von: thunder1902 am 24 September 2014, 12:10:47
Ein Problem habe ich aber noch: Die Batteriespannung wird immer 0,6Volt zu gering angezeigt.
Wo misst du denn die Spannung?
Ansonsten ist die Auswahl des Spannungsteilers der entscheidende Punkt. Ich benutze dafür Widerstände mit 1% Toleranz.
Du kannst die gemessene Spannung aber im Quellcode abgleichen: in Wettersensor.h -> BATTERY_MEASSUREMENT_FACTOR
Dazu einfach die Widerstände des Spannungsteilers ausmessen und den Faktor anpassen.
Zitat von: micomat am 24 September 2014, 13:29:04
Ansonsten muss ich ihn wohl zum Service einschicken ;)
Da es mit Sicherheit noch weitere Firmware Versionen geben wird könntet du dir noch einen HM-CFG-USB zulegen, oder die günstigste Variante den USB-UART-Adapter und den Sensor auf den Seriellen Bootloader umstellen.
Wenn du einen Raspberry Pi da hast kannst du dir auch den USB-UART sparen und den Bootloader und auch spätere Updates mit dem Raspberry Pi einspielen.
Gruß
Dirk
und die chance, dass das eines schoenen tages mit dem hm-cfg-lan geht ist nicht gegeben? =(
dann muss ich mit den dreissiger wohl doch goennen. ich hab zwar auch zwei RPi aber ich glaube das ist mir zu umstaendlich ;)
gruesse,
markus
hallo,
ich wollte gerade mal ein update auf v0.12 machen, habe aber probleme. mit fhem geht es auch bei mir nicht, wie schon berichtet. dann habe ich es mit dem eq3-updatetool versucht. auch hier leider kein erfolg. sowohl mit eq3-file, als auch mit tar.gz-file bricht das update kurz vor ende ab. ist es überhaupt möglich mit dem windows-update zu flashen?
gruss frank
Zitat von: frank am 24 September 2014, 16:58:14
auch hier leider kein erfolg. sowohl mit eq3-file, als auch mit tar.gz-file bricht das update kurz vor ende ab. ist es überhaupt möglich mit dem windows-update zu flashen?
Ja, ist es. Bricht der immer an der selben Stelle ab?
Welche Version vom Bootloader ist bei dir drauf? Das sollte auf dem Aufkleber mit der Seriennumer stehen.
Ansonsten probier mal den Abstand vom USB-Stick zum Sensor zu vergrößern. Bei einem Abstand < 50cm hatte ich hier schon mal Probleme.
Zitat von: Dirk am 22 September 2014, 17:30:42
Also du hast einen CUL für CUXd an deiner CCU2?
Theoretisch sollte das funktionieren. Es könnte sogar sein, dass die Binaries vom Raspberry Pi so auf der CCU2 direkt laufen.
Du müsstest halt den CUXd vorher stoppen damit der CUL frei ist.
Funktioniert leider nicht. Die CCU hat kein Perl und die Libs gegen die das Binary gelinkt ist, existieren auch nicht. Schade.
@micomat: falls du nach Augsburg kommst, kannst zu mir zum updaten kommen!
ZitatBricht der immer an der selben Stelle ab?
nach fortschrittsanzeige der software etwa die selbe stelle.
ZitatWelche Version vom Bootloader ist bei dir drauf? Das sollte auf dem Aufkleber mit der Seriennumer stehen.
leider nur die seriennummer.
ich probiere mal weiter.
gruss frank
Zitat von: frank am 24 September 2014, 19:36:45
leider nur die seriennummer.
Dann hast du leider noch den "alten" Bootloader mit dem Bug wo es immer an der selben Stelle abbricht.
Der Bug betrifft nur das Windows-Tool. Mit dem Linux-Tool funktioniert das Update.
Wenn du einen Raspberry Pi da hast, kannst du aber auch den Bootloader auf den aktuellen Stand bringen.
das ist ja mist. ich habe nur noch fritzbox und arduino. da muss dann wohl der lötkolben rann.
gruss frank
Zitat von: thunder1902 am 24 September 2014, 17:57:19
@micomat: falls du nach Augsburg kommst, kannst zu mir zum updaten kommen!
danke :) werd ich im Hinterkopf behalten.
Zitat von: Dirk am 22 September 2014, 11:00:57
Ich habe hier schon ein paar Sachen probiert.
Aktuell schein es so, dass die CCU2 nicht mit Geräten zurecht kommt bei denen man den Bootloader manuell starten muß.
Oder ich bekomme das aktuell nicht hin.
Ich teste hier aber noch weiter.
...
http://www.fhemwiki.de/wiki/Universalsensor
Ich habe mal analog zum http://www.eq-3.de/Downloads/Software/Firmware/HM-LC-Bl1PBU-FM_update_V2_3_0002_131204.tgz versucht ein Update-File für die CCU2 zusammenzutaren. Hochladen hat geklappt. Der Versuch mittels http://ip-of-ccu2/tools/devconfig.cgi ein Firmwareupdate anzustossen scheitert aber:
An internal error was detected in the service software. The diagnostics are being emailed to the service system administrator (root).Das Log gibt auch nicht wirklich etwas her:
Sep 24 20:08:08 homematic-ccu2 user.debug rfd: GetAvailableFirmware for HB-UW-Sen-THPL-I
Sep 24 20:08:11 homematic-ccu2 user.err rfd: Firmware update faild! Unable to load updatefileDie Struktur unter
/usr/local/etc/config/firmwareist für die Referenz (106) und meinen Versuch (999) genau gleich
# ls -la 106
drwxr-xr-x 2 root root 400 Sep 24 19:46 .
drwxr-xr-x 4 root root 288 Sep 24 19:46 ..
-rw-r--r-- 1 root root 73808 Sep 24 19:46 HM-LC-Bl1PBU-FM_update_V2_3_0002_131204.eq3
-rw-r--r-- 1 root root 1738 Sep 24 19:46 changelog.txt
-rw-r--r-- 1 root root 84 Sep 24 19:46 info# ls -la 999
drwxr-xr-x 2 root root 480 Sep 24 19:58 .
drwxr-xr-x 4 root root 288 Sep 24 19:46 ..
-rw-r--r-- 1 root root 58500 Sep 24 19:55 HB-UW-Sen-THPL-I_update_V0_12_001_140922.eq3
-rw-r--r-- 1 root root 1092 Sep 24 19:46 changelog.txt
-rw-r--r-- 1 root root 84 Sep 24 19:46 infoIch habe keine Idee, was wirklich schief laufen könnte. Leider ist das Lgging ja nicht besonders aussagekräftig ... .
Hat jemand eine Idee, wo ich ansetzen könnte.
Zitat von: Dirk am 22 September 2014, 21:57:29
Ich habe im Github-Release das .pm-File angepasst.
fwUpdate und getSerial sind im Modul nun verfügbar.
Hallo Dirk,
dazu habe ich eine Frage:
ich habe das aktualisierte HMConfig_SenTHPL.pm File gegen das alte ausgetauchst. Aber fwUpdate und setSerial ist bei meinen Sensoren noch nicht verfügbar. Muss ich die Devices dazu neu pairen ?
get Sensor_innen cmdList bringt folgendes:
Gets ------
cmdList
param <param>
reg <addr> ... <list> <peer>
regList
regVal <addr> ... <list> <peer>
saveConfig <filename> ...
Sets ------
clear [readings|trigger|register|rssi|msgEvents|all]
getConfig
getRegRaw [List0|List1|List2|List3|List4|List5|List6] ... [<PeerChannel>]
peerBulk <peer1,peer2,...> [set|unset]
peerChan 0 <actChn> ... single [set|unset] [actor|remote|both]
raw data ...
regBulk <list>:<peer> <addr1:data1> <addr2:data2> ...
regSet [prep|exec] <regName> <value> ... [<peerChannel>]
reset
sign [on|off]
unpair Gruß
Klaus
Hej Klaus,
nein... du musst nur FHEM neu starten.
Hallo Mr. P
das hatte ich schon versucht ......
ich habe gerade mal das File HMConfig_SenTHPL.pm komplett gelöscht ..... das gleiche Ergebnis. ???
das verstehe ich nun überhaupt nicht mehr :-\
Gruß Klaus
Hallo zusammen,
mein Problem ist gelöst. :)
Ich habe FHEM noch einmal neu gstartet und nun gehts .... ???
Gruß
Klaus
Hallo Dirk,
ich habe heute auch mal versucht bei meinem Innensensor die Firmware auf den neuesten Stand zu bringen.
Leider auch kein Erfolg :-\ Fehlermeldung wie du sie schon nanntest:
fwUpdate: fail:Block1
Gruß
Klaus
Der Sensor ist jetzt von HomeDroid (Android) unterstützt.
Eine kurze Anfrage und Infos haben gereicht und die Unterstützung wurde eingerichtet.
Gruß
_cv
;-) sag ich doch, eine tolle APP mit super Support durch den Entwickler.
Dann ist meine Umgebung für die Sensoren bereit
Gruss
Alfred
hallo Dirk,
mal eine (dumme ?) Frage:
kann ich bei meinem Sensor auf dem der OTAU Bootloader 0.6.1 drauf ist, trotzdem noch per USB /seriell die neue Firmware flashen ?
Gruß
Klaus
Der Bootloader unterstützt nur ein Übertragungsmedium.
Zum seriellen Update müsste also wieder der serielle Bootloader aufgespielt werden.
Gruß
Dirk
Hallo Dirk,
danke für die Info.
Habe "gerade" die Firmware erfolgreich mit dem flash-ota aus dem hmcfgusb Paket geupdatet.
Gruß
Klaus
Hallo,
hat jemand schonmal den Innensensor mit HM-DN-RT-CC_Weather gepeert? Der RT bringt hier eine Kommunikationsfehlermeldung und das Antennensymbol blinkt. Woran könnte das liegen?
Gruß
Andreas
Hej Andreas,
funktioniert bei mir seit Anfang an ohne Probleme.
Wie hast du denn versucht, die beiden Geräte zu peeren?
set THL peerChan 0 RT_WZ_1_Weather single
allerdings habe ich mit 3 Thermostaten gepeert
Andreas
Zitat von: knochenmuehle am 27 September 2014, 19:02:39
set THL peerChan 0 RT_WZ_1_Weather single
allerdings habe ich mit 3 Thermostaten gepeert
Ja, eben so, wie es sein soll.
Ich habe nur einen RT mit dem Sensor gepeert, kann schon sein, dass es bei der Anzahl zu einem Timing-Problem kommt.
Aber mach am besten einmal ein Listing von deinem Sensor und den Weather_Channel deines/deiner Problem RT(s). Vielleicht sieht man da schon was.
Andernfalls werden wir uns die Raw-Msgs zwischen den Devices einmal näher ansehen müssen.
Aktuelle Versionen hast du auf den beiden Geräten drauf, oder? Also RT mit v1.3 und THPL mit v0.12?
hallo dirk,
ich habe gerade versucht mir einen neuen ota-bootloader zu bauen. make bricht aber immer mit folgender fehlermeldung ab:
D:\Dokumente und Einstellungen\frank\Eigene Dateien\FHEM\thpl_0.12\Asksin_OTA_Bo
otloader-master>make clean HB_UW_Sen_THPL
rm -rf *.o *.elf *.lst *.map *.sym *.lss *.eep *.srec *.bin *.hex \
uart/*.o uart/*.elf uart/*.lst uart/*.map uart/*.sym uart/*.lss uart/*.e
ep uart/*.srec uart/*.bin uart/*.hex
make -C ./uart/ MCU=atmega328p
make[1]: Entering directory `D:/Dokumente und Einstellungen/frank/Eigene Dateien
/FHEM/thpl_0.12/Asksin_OTA_Bootloader-master/uart'
-------- begin --------
avr-gcc (WinAVR 20081205) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiling: test_uart.c
avr-gcc -c -mmcu=atmega328p -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-ch
ar -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -W
a,-adhlns=test_uart.lst -std=gnu99 -MD -MP -MF .dep/test_uart.o.d test_uart.c -
o test_uart.o
Compiling: uart.c
avr-gcc -c -mmcu=atmega328p -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-ch
ar -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -W
a,-adhlns=uart.lst -std=gnu99 -MD -MP -MF .dep/uart.o.d uart.c -o uart.o
Linking: test_uart.elf
avr-gcc -mmcu=atmega328p -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-
adhlns=test_uart.o -std=gnu99 -MD -MP -MF .dep/test_uart.elf.d test_uart.o uart
.o --output test_uart.elf -Wl,-Map=test_uart.map,--cref -lm
Creating load file for Flash: test_uart.hex
avr-objcopy -O ihex -R .eeprom test_uart.elf test_uart.hex
Creating load file for EEPROM: test_uart.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex test_uart.elf test_uart.eep
e:\programme\Arduino\hardware\tools\avr\bin\avr-objcopy.exe: --change-section-lm
a .eeprom=0x00000000 never used
Creating Extended Listing: test_uart.lss
avr-objdump -h -S test_uart.elf > test_uart.lss
Creating Symbol Table: test_uart.sym
avr-nm -n test_uart.elf > test_uart.sym
-------- end --------
make[1]: Leaving directory `D:/Dokumente und Einstellungen/frank/Eigene Dateien/
FHEM/thpl_0.12/Asksin_OTA_Bootloader-master/uart'
avr-gcc -Wall -c -std=c99 -mmcu=atmega328p -Wl,--section-start=.text=0x7000,--se
ction-start=.addressDataType=0x7FF0,--section-start=.addressDataSerial=0x7FF2,--
section-start=.addressDataId=0x7FFC -DF_CPU=8000000 -DHB_UW_Sen_THPL -Os cc.c -o
cc.o
avr-gcc -Wall -std=c99 -mmcu=atmega328p -Wl,--section-start=.text=0x7000,--se
ction-start=.addressDataType=0x7FF0,--section-start=.addressDataSerial=0x7FF2,--
section-start=.addressDataId=0x7FFC -DF_CPU=8000000 -DHB_UW_Sen_THPL -DCODE_LEN=
0x6FFE -Os bootloader.c cc.o uart/uart.o -o Bootloader-AskSin-OTA-HB_UW_Sen_THPL
.elf
e:/programme/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr
/bin/ld.exe: section .addressDataType [00007ff0 -> 00007ff1] overlaps section .t
ext [00007000 -> 0000819d]
make: *** [hex] Error 1
was kann ich tun?
gruss frank
Zitat von: frank am 27 September 2014, 19:13:19
overlaps section .text [00007000 -> 0000819d]
Das bedeuted dass das Kompilat des Bootloaders zu groß ist, und in die Section für den Adressbereich hinein recht bzw. auch weiter.
Hast du noch Änderungen am Code vorgenommen.
Du kannst auch den fertig kompilierten Bootloader benutzen. Ich kann dir das Flash-Tool schicken mit dem du während des Flashens die Seriennummer, HM-ID usw. ändern kannst.
Zitat von: Mr. P am 27 September 2014, 18:53:00
funktioniert bei mir seit Anfang an ohne Probleme.
Klaüpt mit v0.12 die Kommunikation hier auch noch reibungslos?
Zitat von: Dirk am 27 September 2014, 19:22:05
Klaüpt mit v0.12 die Kommunikation hier auch noch reibungslos?
War mir jetzt auch nicht sicher... aber gerade nachgesehen und ja, auch seit dem Update gibt es keinen einzigen Ausreißer bei den Logdaten vom RT. :-)
Edit: Batterie logge ich seit dem Update auch in einigen Varianten (v0.11 ohne Peering, v0.12 ohne Peering, v0.12 mit Peering) mit und da zeichnet sich auch schon ein klarer Trend zum geringeren Stromverbrauch ab. Will es aber noch ein paar Tage laufen lassen, bevor ich die Zahlen veröffentliche. ;-)
ZitatHast du noch Änderungen am Code vorgenommen.
ich habe nur die "HB-UW-Sen-THPL.h" angepasst:
// The model type
//#define HM_TYPE 0xF1, 0x01 // DIY (HB-UW-Sen-THPL-I) // stored at 0x7FF0
#define HM_TYPE 0xF1, 0x01 // stored at 0x7FF0
// 10 bytes serial number. Must be unique for each device
#define HM_SERIAL 'U','W','S','4','2','0','2','9','0','3' // stored at 0x7FF2
// 3 bytes The device address (hm_id)
#define HM_ID 0x83, 0x76, 0x5A // stored at 0x7FFC
zuerst hatte ich den fertigen bootloader geflasht. da beim anschliessenden ota-update mit eq3-sw am ende ein problem war, hatte ich gedacht, dass es an den default einstellungen gelegen hätte. deswegen der eigenbau.
ZitatDu kannst auch den fertig kompilierten Bootloader benutzen. Ich kann dir das Flash-Tool schicken mit dem du während des Flashens die Seriennummer, HM-ID usw. ändern kannst.
das wäre natürlich auch prima.
gruss frank
Zitat von: frank am 27 September 2014, 19:38:38
ich habe nur die "HB-UW-Sen-THPL.h" angepasst:
Ich vermute dass deine Version vom Compiler etwas größeren Code erzeugt.
Was für eine Version benutzt du denn?
Anbei mal das Flash-Tool.
Allerdings aktuell nur für Windows. Eine Portierung auf Linux kommt noch.
Aufgerufen wird das ganze so:
Zitat
flash.cmd <programmer> <hexfile> [<HM-TYPE> <HM-ID> <Serial>]
Beispiel:
flash.cmd usbasp WetterSensor+AskSinBootloader_HB-UW-Sen-THPL.hex F1:01 AB:CD:EF UWS1234567
Mit dem Tool kann man aktuell den Bootloader nicht alleine flashen. Das liegt an der Art wie ich die Adressdaten im Hex-File ersetze.
Aktuell braucht man ein Kombiniertes Hex-File. Also Programmcode+Bootloader. Daher ist das Teil auch nicht nicht im Github.
Im Zip ist je ein Hex-File für den AskSin Bootloader Version 0.6.1 und für den seriellen Bootloader.
Beide Bootloader unterstützen die Ablage der Adressdaten im Bootloaderbreich.
Wie gesagt, bestehen die Hexfile aus dem Bootloader und der Firmware. Allerdings noch in einer älteren Version. Und einer Version in dem der Sensor alle 10 Sekunden sendet. Das benutze ich zum Testen der sensoren. Nach dem Flashen muss also noch einmal die gewünschte Firmware dann über OTAU oder den Seriellen Weg eingespielt werden.
ACHTUNG:Das Tool setzt auch gleich die Fuse-Bits für den Atmega328p. Das könnte man im cmd-file aber ändern.
Das Tool also bitte erstmal nicht für einen anderen AVRs benutzen. Ansonsten kann es sein, dass man sich die Fuses verstellt.
Gruß
Dirk
ZitatIch vermute dass deine Version vom Compiler etwas größeren Code erzeugt.
Was für eine Version benutzt du denn?
alles was arduino 1.05 mit sich bringt. in der fehlermeldung von vorhin steht:
avr-gcc (WinAVR 20081205) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.das flashtool werde ich dann mal probieren. vielen dank bis dahin.
gruss frank
Zitat von: frank am 27 September 2014, 20:24:27
avr-gcc (WinAVR 20081205) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
Das könnte für den größeren Code verantortlich sein. Ich habe hier:
avr-gcc (WinAVR 20100110) 4.3.3
hallo dirk,
kurze frage. mein programmer ist ein arduino mega 2560 den ich folgendermassen mit avrdude aufrufe:
avrdude -p m328p -P \\.\com62 -b 19200 -c avrisp -V -U flash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hexwas genau muss ich in diesem fall für <programmer> im aufruf von flash.cmd eingeben? nur avrisp?
edit:
wie schon vermutet, erwartet flash.cmd den programmer an com1.
gruss frank
Mist es gibt je noch ein paar Programmer die noch Parameter brauchen. Das muss ich später noch anpassen.
Versuch es mal so:
flash.cmd "avrisp" WetterSensor+AskSinBootloader_HB-UW-Sen-THPL.hex F1:01 AB:CD:EF UWS1234567
Vorher bitte noch die CFG-Datei anpassen:
bin/avrdude.conf
Zeile 318:
default_serial = "com62";
Hinter Zeile 434 noch diesen Eintrag anhängen (im Abschnitt programmer - id "avrisp"):
baudrate = 19200
Dann sollte es klappen
jetzt hat alles bestens funktioniert. danke
v0.12 konnte ich jetzt mit eq3-sw updaten. luftdruck hat jetzt eine nachkommastelle.
wer es nachmachen möchte, sollte noch ein semicolon spendieren. also in avrdude.conf folgendes einfügen:
baudrate = 19200;
meinen arduino habe ich an die markierten pins aus dem angehängten bild angeschlossen. und zwar folgendermassen:
sensor arduinomega (pin)
GND GND
RESET (53)
VCC 3,3V
SCK (52)
MISO (50)
MOSI (51)
gruss frank
Dies könnte ins Wiki.
Hier gleich auch die Pins für UNO:
ISP | Arduino Mega | Arduino UNO |
RST | 53 | 10 |
MOSI | 51 | 11 |
MISO | 50 | 12 |
SCK | 52 | 13 |
Hallo zusammen,
nach dem Firmwareupdate auf 0.12 zeigt mein Innensensor keine Helligkeit mehr an. Der Außensensor schon ......
Hat jemand eine Idee woran das liegen könnte ?
Gruß
Klaus
hallo klaus,
hast du auch die neue fhem datei "HMConfig_SenTHPL.pm" installiert. kopieren und reload/restart.
gruss frank
Hallo Frank,
Zitat von: frank am 28 September 2014, 12:42:13
hast du auch die neue fhem datei "HMConfig_SenTHPL.pm" installiert. kopieren und reload/restart.
jep, das hatte ich gemacht. Der "Außen-Sensor" macht das ja auch brav .....
Gruß
Klaus
Zitat von: frank am 28 September 2014, 12:42:13
hast du auch die neue fhem datei "HMConfig_SenTHPL.pm" installiert.
und die alte Datei HMConfig_THPL.pm
gelöscht?
Zitat von: betateilchen am 28 September 2014, 14:06:13
und die alte Datei HMConfig_THPL.pm gelöscht?
Ja, das hatte ich gemacht.
Der Außensensor benimmt sich ja auch brav .....
2014-09-28_15:01:14 Sensor_aussen temperature: 22.3
2014-09-28_15:01:14 Sensor_aussen battery: ok
2014-09-28_15:01:14 Sensor_aussen batVoltage: 2.77
2014-09-28_15:01:14 Sensor_aussen humidity: 71
2014-09-28_15:01:14 Sensor_aussen luminosity: 2963
2014-09-28_15:01:14 Sensor_aussen pressure: 1011.5
2014-09-28_15:01:14 Sensor_aussen T: 22.3 H: 71 L: 2963 P: 1011.5
2014-09-28_15:04:26 Sensor_aussen temperature: 22.4
2014-09-28_15:04:26 Sensor_aussen battery: ok
2014-09-28_15:04:26 Sensor_aussen batVoltage: 2.79
2014-09-28_15:04:26 Sensor_aussen humidity: 70
2014-09-28_15:04:26 Sensor_aussen luminosity: 2895
2014-09-28_15:04:26 Sensor_aussen pressure: 1011.5
2014-09-28_15:04:26 Sensor_aussen T: 22.4 H: 70 L: 2895 P: 1011.5
2014-09-28_15:07:22 Sensor_aussen temperature: 22.5
2014-09-28_15:07:22 Sensor_aussen battery: ok
2014-09-28_15:07:22 Sensor_aussen batVoltage: 2.76
2014-09-28_15:07:22 Sensor_aussen humidity: 70
2014-09-28_15:07:22 Sensor_aussen luminosity: 2858
2014-09-28_15:07:22 Sensor_aussen pressure: 1011.6
2014-09-28_15:07:22 Sensor_aussen T: 22.5 H: 70 L: 2858 P: 1011.6Der Innensensor dagegen "spinnt" ......
2014-09-28_15:03:03 Sensor_innen temperature: 24.2
2014-09-28_15:03:03 Sensor_innen battery: ok
2014-09-28_15:03:03 Sensor_innen batVoltage: 2.83
2014-09-28_15:03:03 Sensor_innen humidity: 60
2014-09-28_15:03:03 Sensor_innen luminosity: 0
2014-09-28_15:03:03 Sensor_innen T: 24.2 H: 60 L: 0
2014-09-28_15:05:34 Sensor_innen temperature: 23.6
2014-09-28_15:05:34 Sensor_innen battery: ok
2014-09-28_15:05:34 Sensor_innen batVoltage: 2.83
2014-09-28_15:05:34 Sensor_innen humidity: 62
2014-09-28_15:05:34 Sensor_innen luminosity: 0
2014-09-28_15:05:34 Sensor_innen T: 23.6 H: 62 L: 0
2014-09-28_15:09:00 Sensor_innen temperature: 23.3
2014-09-28_15:09:00 Sensor_innen battery: ok
2014-09-28_15:09:00 Sensor_innen batVoltage: 2.86
2014-09-28_15:09:00 Sensor_innen humidity: 63
2014-09-28_15:09:00 Sensor_innen luminosity: 0
2014-09-28_15:09:00 Sensor_innen T: 23.3 H: 63 L: 0Vorhin hatte der Sensor sich komplett "tot" gestellt, nichts gesendet und auch nicht auf den Config-Tastendruck reagiert. :-\
Gruß
Klaus
Lustig... ich habe gestern meinen Sensor von 0.10 auf 0.12 geändert und seither steigt die Spannungsanzeige kontinuierlich (wenn auch sehr langsam) an...
Zitatund seither steigt die Spannungsanzeige kontinuierlich (wenn auch sehr langsam) an...
Perpetuum mobile? Ich würde das Teil dann gleich zum Akkus laden benutzen. ;D
Hallo,
ich habe alle Sensoren ota geupdatet. Leider musste ich dazu die Sensoren in die Nähe des USB Sticks legen. Ansonsten hatte ich immer Abbrüche wg fehlerhaften Blöcken.
Dirk zur Info auch mit der neuen Firmware hatte ich wieder Messwertausrutscher.
Nico
Zitat von: betateilchen am 28 September 2014, 16:05:55
Lustig... ich habe gestern meinen Sensor von 0.10 auf 0.12 geändert und seither steigt die Spannungsanzeige kontinuierlich (wenn auch sehr langsam) an...
Ja, den selben Effekt konnte ich von 0.11 auf 0.12 auch bemerken. Ist um ca. 0,05V wieder angestiegen. :-)
Zitat von: dampf123 am 28 September 2014, 12:09:33
Hat jemand eine Idee woran das liegen könnte ?
In der neuen Firmware wird die Helligkeit interruptgesteuert gemessen.
Wenn der Sensor nun eine Macke hat, und den Interrupt nicht generiert, kann es sein dass dann kein Ergebniss kommt.
Aber eigentlich dürfte der Sensor dann gar nichts weiter messen, weil beim Ausbleiben des Interrupts die Daten der anderen Sensoren auch nicht erfasst werden. Eigentlich würde der Sensor dann ewig auf den Interrupt warten und daher "hängen bleiben"
Ich muss mal überlegen was das noch sein könnte.
ZitatVorhin hatte der Sensor sich komplett "tot" gestellt, nichts gesendet und auch nicht auf den Config-Tastendruck reagiert. :-\
Das würde allerdings die obige Annahme bestätigen.
Zitat von: santalaus am 28 September 2014, 19:14:30
ich habe alle Sensoren ota geupdatet. Leider musste ich dazu die Sensoren in die Nähe des USB Sticks legen. Ansonsten hatte ich immer Abbrüche wg fehlerhaften Blöcken.
Mit welcher Software hattest du das gemacht?
ZitatDirk zur Info auch mit der neuen Firmware hatte ich wieder Messwertausrutscher.
Wie oft kommt das etwa vor? Bei allen Messwerten oder nur einzelnen?
Kannst du mir dazu mal ein paar Logs schicken.
Tach Dirk,
Zitat von: Dirk am 28 September 2014, 21:47:49
In der neuen Firmware wird die Helligkeit interruptgesteuert gemessen.
Wenn der Sensor nun eine Macke hat, und den Interrupt nicht generiert, kann es sein dass dann kein Ergebniss kommt.
Aber eigentlich dürfte der Sensor dann gar nichts weiter messen, weil beim Ausbleiben des Interrupts die Daten der anderen Sensoren auch nicht erfasst werden. Eigentlich würde der Sensor dann ewig auf den Interrupt warten und daher "hängen bleiben"
also momentan sendet der "Innen-Sensor" brav alle 2-3 min Messwerte.
Siehe Logauszug:
2014-09-28_22:01:59 Sensor_innen T: 21.5 H: 70 L: 0
2014-09-28_22:04:43 Sensor_innen temperature: 21.6
2014-09-28_22:04:43 Sensor_innen battery: ok
2014-09-28_22:04:43 Sensor_innen batVoltage: 2.84
2014-09-28_22:04:43 Sensor_innen humidity: 70
2014-09-28_22:04:43 Sensor_innen luminosity: 0
2014-09-28_22:04:43 Sensor_innen T: 21.6 H: 70 L: 0
2014-09-28_22:07:12 Sensor_innen temperature: 21.6
2014-09-28_22:07:12 Sensor_innen battery: ok
2014-09-28_22:07:12 Sensor_innen batVoltage: 2.83
2014-09-28_22:07:12 Sensor_innen humidity: 70
2014-09-28_22:07:12 Sensor_innen luminosity: 0
2014-09-28_22:07:12 Sensor_innen T: 21.6 H: 70 L: 0
2014-09-28_22:10:36 Sensor_innen temperature: 21.6
2014-09-28_22:10:36 Sensor_innen battery: ok
2014-09-28_22:10:36 Sensor_innen batVoltage: 2.82
2014-09-28_22:10:36 Sensor_innen humidity: 70
2014-09-28_22:10:36 Sensor_innen luminosity: 0
2014-09-28_22:10:36 Sensor_innen T: 21.6 H: 70 L: 0
2014-09-28_22:13:44 Sensor_innen temperature: 21.8
2014-09-28_22:13:44 Sensor_innen battery: ok
2014-09-28_22:13:44 Sensor_innen batVoltage: 2.82
2014-09-28_22:13:44 Sensor_innen humidity: 69
2014-09-28_22:13:44 Sensor_innen luminosity: 0
2014-09-28_22:13:44 Sensor_innen T: 21.8 H: 69 L: 0Luminosity ist immer 0 :-\
Ich könnte ja noch mal den Versuch starten, die Firmware auf die vorherige Version zu flashen (0.11) und schauen ob der Sensor dann wieder "normal" rennt. dann bräuchte ich von dir nur mal ein XXX.eq3 File mit der "alten" Firmware.
Gruß
Klaus
Zitat von: dampf123 am 28 September 2014, 22:28:30
Ich könnte ja noch mal den Versuch starten, die Firmware auf die vorherige Version zu flashen (0.11) und schauen ob der Sensor dann wieder "normal" rennt. dann bräuchte ich von dir nur mal ein XXX.eq3 File mit der "alten" Firmware.
Hier: http://forum.fhem.de/index.php/topic,20620.msg197670.html#msg197670
nimm diese Version: HB-UW-Sen-THPL-I-O_11_868.299866mhz.eq3
Zitat von: Dirk am 28 September 2014, 22:57:01
Hier: http://forum.fhem.de/index.php/topic,20620.msg197670.html#msg197670
nimm diese Version: HB-UW-Sen-THPL-I-O_11_868.299866mhz.eq3
habe ich geflasht, Ergebnis:
2014-09-28_23:34:57 Sensor_innen T: 21.4 H: 69 L: 0
2014-09-28_23:48:34 Sensor_innen Activity: unknown
2014-09-28_23:49:41 Sensor_innen D-firmware: 0.11
2014-09-28_23:49:41 Sensor_innen D-serialNr: UWS6391411
2014-09-28_23:49:41 Sensor_innen Activity: alive
2014-09-28_23:49:42 Sensor_innen R-pairCentral: 0x4BD3E1
2014-09-28_23:49:42 Sensor_innen R-burstRx: undef lit:255
2014-09-28_23:50:30 Sensor_innen temperature: 23.6
2014-09-28_23:50:30 Sensor_innen battery: ok
2014-09-28_23:50:30 Sensor_innen batVoltage: 2.83
2014-09-28_23:50:30 Sensor_innen humidity: 61
2014-09-28_23:50:30 Sensor_innen luminosity: 226
2014-09-28_23:50:30 Sensor_innen T: 23.6 H: 61 L: 226
2014-09-28_23:53:01 Sensor_innen temperature: 22.6
2014-09-28_23:53:01 Sensor_innen battery: ok
2014-09-28_23:53:01 Sensor_innen batVoltage: 2.82
2014-09-28_23:53:01 Sensor_innen humidity: 65
2014-09-28_23:53:01 Sensor_innen luminosity: 226
2014-09-28_23:53:01 Sensor_innen T: 22.6 H: 65 L: 226
2014-09-28_23:56:25 Sensor_innen temperature: 22.3
2014-09-28_23:56:25 Sensor_innen battery: ok
2014-09-28_23:56:25 Sensor_innen batVoltage: 2.82
2014-09-28_23:56:25 Sensor_innen humidity: 67
2014-09-28_23:56:25 Sensor_innen luminosity: 474
2014-09-28_23:56:25 Sensor_innen T: 22.3 H: 67 L: 474luminosity is wieder da ........
Hm, evtl. hilft dir das ja weiter Dirk.
Zumindest scheint ja die Hardware als solche noch IO zu sein. Da hatte ich schon meine Befürchtungen.
Mich wundert es nur, das sich der Außensensor anders verhält.
Gruß
Klaus
Zitat von: dampf123 am 29 September 2014, 00:04:38
Zumindest scheint ja die Hardware als solche noch IO zu sein.
Das ist in diesem Fall leider nicht 100 %ig gesagt, Da mit der neuen Firmware zum Abschluss der Helligkeitsmessung wie gesagt ein Interrupt vom Helligkeitssensor erforderlich ist. Und dieser könnte fehlen.
Hallo Dirk,
ota updates habe ich mit flash-ota direkt vom cubietruck aus via hm-usb gemacht.
Ich habe es schnell aufgegeben und einfach nicht alle Sensoren am original Platz probiert, da bei den ersten 2 schon die Übertragungsprobleme auftraten. Ist IMHO auch nicht so schlimm, ich wollte das nur als Rückmeldung geben.
Zuden Messwerten: Muss ich raussuchen. Es fällt mir bei den Plots halt auf.
Was brauchst Du den da? Die Fehlerhaften Werte? +- Werte darum?
Es tritt so alle 1-2 Tage bei 1-3 Sensoren auf.
Zitat von: santalaus am 29 September 2014, 11:00:53
ota updates habe ich mit flash-ota direkt vom cubietruck aus via hm-usb gemacht.
Ich meine flash-ota hat intern keine "Kanal-Frei-Erkennung" daher könnte es sein, dass die Übertragung durch "dazwischenfunkende" Geräte gestört wird. Daher muss man dann ggf. näher an das Gerät ran.
ZitatZuden Messwerten: Muss ich raussuchen. Es fällt mir bei den Plots halt auf.
Was brauchst Du den da? Die Fehlerhaften Werte? +- Werte darum?
Ja, ein Abschnitt aus dem Log mit korrekten Werten drum herum währ gut.
Zitat von: Dirk am 27 September 2014, 20:27:25
Das könnte für den größeren Code verantortlich sein. Ich habe hier:
avr-gcc (WinAVR 20100110) 4.3.3
nach der installation von WinAVR-20100110 von hier http://sourceforge.net/projects/winavr/ (http://sourceforge.net/projects/winavr/) klappt es auch mit dem bauen des bootloaders.
gruss frank
Juchhu geschafft!
Man oh man, 76 Seiten sind echt kein Pappenstiel! Ich willl auch solche Teile haben! Dirk schickst Du mir eine Preisliste, bitte!?
@Mr.P. und betateilchen: Das mit der steigenden Spannung wundert mich nicht! Wenn die Akkus/Batterien weniger belastet werden (Strom), dann steigt die Zellenspannung logischerweise etwas an. Aber das war Euch klar denke ich! Andererseits zeigt es, dass Dirks Stromsparansaetze greifen!
Gruss Christoph
Zitat von: pc1246 am 29 September 2014, 13:41:10
@Mr.P. und betateilchen: Das mit der steigenden Spannung wundert mich nicht! Wenn die Akkus/Batterien weniger belastet werden (Strom), dann steigt die Zellenspannung logischerweise etwas an. Aber das war Euch klar denke ich! Andererseits zeigt es, dass Dirks Stromsparansaetze greifen!
Jo... War betateilchen und mir schon klar, dass wir nicht plötzlich ein Perpetuum mobile in unseren Händen halten. ;-)
Das Dirks Ansätze greifen, sehe ich auch bereits recht gut in meinen div. Spannungsaufzeichnungen, die ich bei mir laufen habe. Mal sehen, wie diese sich in den nächsten Tagen noch weiter entwickeln. ;-)
Hallo zusammen,
mir geht's so wie pc1246.
Irgendwie habe ich wohl auf den 76 Seiten inzwischen den Überblick verloren. ;)
Ist schon echt klasse, was hier entwickelt wurde.
Gerne würde ich einen Sensor für Temperatur/Helligkeit für draußen haben.
Später dann ggf. auch noch den ein und anderen Sensor für innen.
Wenn ein solches noch mehr kann... umso besser.
Stellt sich mir die Frage:
Was kostet ein Sensor für außen, der mind. Temperatur und Helligkeit feststellt?
Am besten als Komplettsensor, also auspacken, einschalten, anlernen und fertig. 8)
Löten geht bei mir zwar, aber keine SMD Technologie.
Es wäre super, wenn ich nehme mal an Dirk mir Infos zusenden könnte.
Gerne auch als PM.
Gruß
Max
Hallo maxritti
Mir ging es genau so wie Dir. Ich habe von Dirk letzte Woche einen Innensensor erhalten und der funkioniert perfekt. Das Einzige was ich selber machen musste war ein Loch in das Gehäuse über dem Helligkeitssensor zu bohren und den beiligenden durchsichtigen Stab in diesem Loch zu fixieren. An dieser Stelle vielen Dank an Dirk für die tolle Arbeit.
http://forum.fhem.de/index.php/topic,20620.msg199288.html#msg199288 (http://forum.fhem.de/index.php/topic,20620.msg199288.html#msg199288) Hier ist eine Preiliste von Dirk, ich hoffe sie ist noch aktuell.
lg Harald
Hi Harald,
danke Dir dafür.
Ich habe auch gerade Post von Dirk bekommen. :)
Es geht nun per PM weiter denke ich.
Gruß
Max
Ich habe mal eine neue Firmware-Version ins Git gestellt. v0.13.
Dies ist aber eine Beta-Version. Wenn sich dafür ein paar Tester finden, währe es schön.
Es gibt jetzt einstellbare Register:
- transmitTryMax: Damit kann eingestellt werden wie oft der Sensor daten an z.B. eine gepairte Zentrale sendet falls kein ACK empfangen wird (1-6)
- lowBatLimit: Damit kann die Battery-Low schwelle eingestellt werden. (1,5 V - 5,0 V)
- ledMode: Hiermit kann das Leuchten der LED im normalen Betrieb abgeschaltet werden. Die LED leuchtet dann nur noch im Config-Mode und kurz beim Starten.
- altitude: Speziell für die CCU-Only User. Damit kann die Sensorhöhe in Metern eingestellt werden. Der Sensor gibt dann dann den Luftdruck bezogen auf Meehreshöhe aus.
FHEM-Benutzer brauchen dieses Register eigentlich nicht setzen. Da FHEM diese Berechnung selber vornimmt.
Viele Grüße
Dirk
V0.13 habe ich gerade geflasht. Neu gepairt und getConfig. Neue HMConfig_SenTHPL.pm installiert.
Grundfunktion - keine Änderung bemerkt.
Die zusätzliche Register sehe ich auch.
Ich habe versucht, die lowBatLimit auf 1.0 zu setzen. Mit dem Max sehe ich das als ein akzeptabler Wert, geht jedoch nicht:
value:1.0 out of range 1.5 to 5 for Reg "lowBatLimitTHPL"
Ist das nicht etwas zu restriktiv?
ledMode funktioniert.
Ich habe auch mit dem Burst experimentiert: burstAccess auf auto und burstRx auf on. Ich merke hier keine Änderung. getConfig wird erst beim Betätigen der Taste oder erst bei der nächsten Übertragung beantwortet. set burtsXmit bringt auch nichts. Habe ich etwas übersehen?
Hej Dirk,
habe jetzt auch auf einen meiner Sensoren die 0.13er Version drauf und bin schon gespannt, wie sie sich schlägt.
Also ledMode ist schon mal toll. Bin schon gespannt, wie sehr sich das auf den Energieverbrauch auswirkt. Und außerdem ist der WAF jetzt hoch genug, damit einer der Sensoren wieder ins Schlafzimmer zurück kann. ;-)
Habe zwar keinen Luftdruckmesser, aber bei dem Altitude-Register wäre es wohl interessant, dass dann letztendlich sowohl der gemessene Wert als auch der errechnete übertragen wird. Finde den Weg, dass FHEM sich selbst darum kümmert und die CCU das übergeben benötigt, weniger elegant. Einheitlich beide Werte immer vom Sensor kommen zu lassen wäre mE besser.
Und was mir vorhin noch aufgefallen ist (war aber auch schon bei v0.12 so)... Ich kann die Register nur setzen, wenn ich auf die Config-Taste drücke.
Wenn ich versuche, die Daten als Antwort an die Werte zu senden, beginnt zwar laut FHEM die Verarbeitung, aber der Sensor kann diese nicht verarbeiten.
Vielen Dank fürs Update! :-)
Mein Sensor läuft soweit :)
Interessante Beobachtung: die ohnehin schwache Batterie wurde beim Update endgültig geplättet. Das hat paar sonderbare Messergebnisse gebracht:
2014-10-05_00:01:24 EG_WZ_KS01 temperature: 24.8
2014-10-05_00:01:24 EG_WZ_KS01 batVoltage: 0.65
2014-10-05_00:01:24 EG_WZ_KS01 humidity: 53
2014-10-05_00:01:24 EG_WZ_KS01 luminosity: 43.54
2014-10-05_00:01:30 EG_WZ_KS01 temperature: 24.9
2014-10-05_00:01:30 EG_WZ_KS01 batVoltage: 0.66
2014-10-05_00:01:30 EG_WZ_KS01 luminosity: 43.74
2014-10-05_00:01:34 EG_WZ_KS01 temperature: 124.1
2014-10-05_00:01:34 EG_WZ_KS01 batVoltage: 0.64
2014-10-05_00:01:34 EG_WZ_KS01 luminosity: 43.59
2014-10-05_00:01:38 EG_WZ_KS01 temperature: -37.7
2014-10-05_00:01:38 EG_WZ_KS01 batVoltage: 0.63
2014-10-05_00:01:38 EG_WZ_KS01 humidity: 37
2014-10-05_00:01:38 EG_WZ_KS01 luminosity: 43.86
2014-10-05_00:01:42 EG_WZ_KS01 temperature: -39.7
2014-10-05_00:01:42 EG_WZ_KS01 batVoltage: 0.61
2014-10-05_00:01:42 EG_WZ_KS01 humidity: 34
2014-10-05_00:01:42 EG_WZ_KS01 luminosity: 44.53
Cool... innderhalb von 4 Sekunden von 124.1 auf -37.7 Grad C.
Auf welchem Planeten wohnst Du den :D
Grüsse Martin
Zitat von: hexenmeister am 05 Oktober 2014, 10:43:11
Interessante Beobachtung: die ohnehin schwache Batterie wurde beim Update endgültig geplättet.
Wenn du dir deine Logfiles so durch siehst... Bis zu welcher Spannung würdest du denn behaupten, dass der Sensor zuverlässige Daten geliefert hat? :-)
Der letzte sinnvolle Wert war bei 0,66V geliefert. Da der Max-Chip aber (wenn ich mich recht erinere) ab 0,8V garantiert anläuft, würde diesen Wert als noch 'zuverlässig' betrachten.
Die Dateien sehe ich aber nur dann so genau durch, wenn die Plots auffällig aussehen ;)
Zitat von: hexenmeister am 05 Oktober 2014, 00:47:50
Ich habe versucht, die lowBatLimit auf 1.0 zu setzen. Mit dem Max sehe ich das als ein akzeptabler Wert, geht jedoch nicht:
value:1.0 out of range 1.5 to 5 for Reg "lowBatLimitTHPL"
Ist das nicht etwas zu restriktiv?
Ich hab das dann mal auf 1 gestellt. Das Update im Github kommt dann vermutlich im Laufe des Tages.
ZitatIch habe auch mit dem Burst experimentiert: burstAccess auf auto und burstRx auf on. Ich merke hier keine Änderung. getConfig wird erst beim Betätigen der Taste oder erst bei der nächsten Übertragung beantwortet. set burtsXmit bringt auch nichts.
Burst und "Lazy Config" funktionieren noch nicht.
Zitat von: Mr. P am 05 Oktober 2014, 03:05:46
Also ledMode ist schon mal toll. Bin schon gespannt, wie sehr sich das auf den Energieverbrauch auswirkt.
Ich schätze das wird gesehen auf die Gesamtlaufzeit nur ca. einen Tag ausmachen.
ZitatHabe zwar keinen Luftdruckmesser, aber bei dem Altitude-Register wäre es wohl interessant, dass dann letztendlich sowohl der gemessene Wert als auch der errechnete übertragen wird. Finde den Weg, dass FHEM sich selbst darum kümmert und die CCU das übergeben benötigt, weniger elegant.
In FHEM kann man ggf. komplexere Berechnungen durchführen. Außerdem braucht man dann wieder zwei zusätzliches Bytes in der Nachricht.
Daher soll das aktuell nur eine Hilfe für CCU-Benutzer sein.
ZitatUnd was mir vorhin noch aufgefallen ist (war aber auch schon bei v0.12 so)... Ich kann die Register nur setzen, wenn ich auf die Config-Taste drücke.
Siehe oben. Lazy-Config funktioniert noch nicht.
Zitat von: hexenmeister am 05 Oktober 2014, 10:43:11
Das hat paar sonderbare Messergebnisse gebracht:
Kannst du mal messen was bei 0,6V Batteriespannung noch aus dem Max rauskommt. Das liegt gestimmt deutlich unter 2,5V. Und dann misst der SHT schon mal Mist.
Vielleicht sollte ich den AVR veranlassen unter 0,8V Batteriespannung keine Daten mehr zu senden?
Zitat von: Dirk am 05 Oktober 2014, 12:03:40
Ich schätze das wird gesehen auf die Gesamtlaufzeit nur ca. einen Tag ausmachen.
Die Hauptsache war aber auch, dass sich niemand mehr an dem blinkenden LED stört... Danke dafür. :-)
Zitat von: Dirk am 05 Oktober 2014, 12:03:40
In FHEM kann man ggf. komplexere Berechnungen durchführen. Außerdem braucht man dann wieder zwei zusätzliches Bytes in der Nachricht.
Daher soll das aktuell nur eine Hilfe für CCU-Benutzer sein.
Ist zwar nur Kosmetik, aber dann würde ich den Register vielleicht auch CCUaltitude nennen oder zumindest in der Registerbeschreibung erläutern.
Zitat von: Dirk am 05 Oktober 2014, 12:03:40
Siehe oben. Lazy-Config funktioniert noch nicht.
Ok, passt. :-)
Zitat von: Dirk am 05 Oktober 2014, 12:03:40
Vielleicht sollte ich den AVR veranlassen unter 0,8V Batteriespannung keine Daten mehr zu senden?
Also wenn hexenmeister die 0,8V richtig im Kopf hat, würde das Sinn machen. Und wenn ich auch nicht betroffen bin, aber wie sieht es dann bei den Max-losen Boards aus? Kann man die auch berücksichtigen bzw. den Grenzwert wieder konfigurierbar machen?
Zitat von: mmatt am 05 Oktober 2014, 10:54:57
Cool... innderhalb von 4 Sekunden von 124.1 auf -37.7 Grad C.
Ja, und ich habe mich schon gefragt... es war gerade noch so schön mollig warm und dann plötzlich die Eisspitzen auf en Wänden... Ich denke, ich muss die neue Heizungsteuerungsroutine überprüfen ;D
Zitat von: Mr. P am 05 Oktober 2014, 12:17:56
Also wenn hexenmeister die 0,8V richtig im Kopf hat, würde das Sinn machen.
Die 0,8 V passen schon. Es wundert mich, dass der MAX bei 0,6V hier noch eine nutzbare Ausgangsspannung erzeugt. Obwohl es sich auch um einen Messfehler im Spannungsteiler handeln kann. Der Spannungsteiler benutzt zwar 1% Widerstände. Aber eine sehr große Genauigkeit kann man von dem nicht erwarten.
Ich werde das aber nochmal mit dem Labornetzteil nachmessen.
Zitataber wie sieht es dann bei den Max-losen Boards aus?
Der SHT10 ist min min. 2,4 V spezifiziert. Darunter werden keine verlässlichen Werte mehr ausgegeben. Der BMP180 ist mit Umin 1,8V und der TLS251 mit Umin 2,7 V angegeben. Den BrownOut vom AVR habe ich auf 1,8V gesetzt. Daher läuft der Sensor darunter eh nicht mehr.
ZitatKann man die auch berücksichtigen bzw. den Grenzwert wieder konfigurierbar machen?
Vielleicht reicht es auch bei BattMin-Offset das Senden einzustellen.
Zitat von: Dirk am 05 Oktober 2014, 12:03:40
Kannst du mal messen was bei 0,6V Batteriespannung noch aus dem Max rauskommt. Das liegt gestimmt deutlich unter 2,5V. Und dann misst der SHT schon mal Mist.
Vielleicht sollte ich den AVR veranlassen unter 0,8V Batteriespannung keine Daten mehr zu senden?
Eine genaue Messung hat sich als schwierig erwiesen. Ich habe gerade keine stabile 0,6V-Quelle zur Hand, evtl. bastle ich mir noch eine. Aber auch mit den alten Batterien (trotz sehr schnell fallender Spannung) konnte ich gut sehen, dass die Spannung nach dem Max sehr schnell unter 2V einbricht (und auch stark schwankt), wenn die Eingangsspannung stark abfällt.
Was mir noch aufgefallen ist: die Spannung wird scheinbar etwas zu tief gemessen. Mein Messgerät (Mastech MS8229; 40-Euro-Klasse) sagt gerade 3,098V und der Sensor sendete 2,87. Da passt auch zu den Daten aus dem Datenblatt:
- 0.8V to 5.5V Input Voltage Range
- 0.91V Guaranteed Startup (MAX1722/MAX1724)
Mit 0,6 dürfte Der Max gar nicht laufen.
Ich denke, das Senden bei Unterspannung zu unterlassen, ist eine gute Idee. Davor sollten wir aber noch die Spannungsmessung prüfen/einstellen.
Viele Grüße,
Alexander
Edit: typo
Zitat von: hexenmeister am 05 Oktober 2014, 13:26:56
Was mir noch aufgefallen ist: die Spannung wird scheinbar etwas zu tief gemessen. Mein Messgerät (Mastech MS8229; 40-Euro-Klasse) sagt gerade 3,098V und der Sensor sendete 2,87.
Stimmt, hab ich auch grade gemessen. Ich werde den Faktor da noch mal anpassen. Und wenn ich den nächsten Schwung Sensoren baue mal eine Serienmessung und ein Vergleich machen.
hallo,
ich habe auch mal v0.13 mit dem eq3-file aus dem git auf einem innensensor am laufen. dort stelle ich ungereimtheiten mit dem pairen fest.
nach meinem verständnis sollte ein ungepairtes device (pairCentral 0x0 und 0A:00 0B:00 0C:00) von einer beliebigen zentrale aus nicht konfigurierbar sein. ich kann aber alle register nach belieben setzen. sogar wenn ich über
set sensor regSet pairCentral AAAAAA
eine andere zentrale setze, kann ich weiterhin über fhem (1ACE1F) die register verändern. somit kann ja jeder nach belieben das device konfigurieren. mit der alternativen firmware für den sw1pbu stelle ich ein ähnliches verhalten fest. daher vermute ich den ursprung in der asksinlib.
beim zusammenspiel von fhem-altitude und dem register altitude des sensors ergibt das fhem reading pressure-nn nun natürlich falsche werte. könnte man diesen umstand eventuell umgehen, indem man das reading pressure des sensors bei verwendung des registers altitude!=0 umbenennt?
gruss frank
Zitat von: frank am 05 Oktober 2014, 15:13:00
ich habe auch mal v0.13 mit dem eq3-file aus dem git auf einem innensensor am laufen. dort stelle ich ungereimtheiten mit dem pairen fest.
...
ich kann aber alle register nach belieben setzen. sogar wenn ich über eine andere zentrale setze, kann ich weiterhin über fhem (1ACE1F) die register verändern.
Das stimmt. Das muss ich mir mal in der Lib ansehen. Ich benutze das aktuell sogar als Feature. Da ich hin und wieder keine Lust habe nach einem Reset das device neu zu Pairen :)
Zitatbeim zusammenspiel von fhem-altitude und dem register altitude des sensors ergibt das fhem reading pressure-nn nun natürlich falsche werte. könnte man diesen umstand eventuell umgehen, indem man das reading pressure des sensors bei verwendung des registers altitude!=0 umbenennt?
Eigentlich sollte das pressure-nn-Reading gar nicht mehr aktualsiert werden wenn R-altitude != 0 ist.
Ich schaue mir das aber noch mal an.
ZitatEigentlich sollte das pressure-nn-Reading gar nicht mehr aktualsiert werden wenn R-altitude != 0 ist.
Ich schaue mir das aber noch mal an.
das geschieht wohl nur, wenn man zuvor ein set clear reading gemacht hat und fhem keine ahnung vom register altitude hat.
gruss frank
Hallo,
den Aussensensor neu seit Gestern in Betrieb und hatte bis gestern auch kein global altitude gesetzt und somit erst auch kein pressureNN Reading , erst als ich dieses gesetzt hatte, kam dann das Reading. Habe noch die .12 vom 22.9.2014.
Gruß Stefan
Zitat von: Dirk am 05 Oktober 2014, 12:03:40
Vielleicht sollte ich den AVR veranlassen unter 0,8V Batteriespannung keine Daten mehr zu senden?
hört sich gut an. das könnte man ja, dann noch vor dem abschalten, mit einem battery=critical melden.
gruss frank
Hallo, kurze Frage:
Kommt die Temperatur beim Außensensor im Falle eines zugefügten SHT 10 aus diesem oder aus dem im Gehäuse liegenden Drucksensor?
Gruß
Boris
Hi Borin,
wenn am Außensensor der SHT10 angeschlossen ist, wird die Temperatur vom SHT10 übermittelt.
Gruß
Dirk
Hallo,
hier klinke ich mich auch mal mit einem kleinen Fingerheber ein.
Tolle Arbeit!
Darf ich auch irgendwo einen Sensor für außen und/oder ggf. einen für innen bestellen?
Hallo Dirk,
habe gestern den Innensensor in Betrieb genommen (v0.12) und alles hat auf Anhieb perfekt funktioniert. :)
Frage noch zum Reading Luftdruck. Longitude und Latitude sind in global gesetzt.
Zitat von: betateilchen am 27 August 2014, 11:44:35
Das Modul liefert doch zwei Luftdruckwerte: Einmal den gemessenen und einmal den korrigierten, sofern Du das globale Attribut altitude für Deinen Standort in fhem gepflegt hast. Welcher Luftdruckwert fehlt Dir denn jetzt noch?
Zitat von: Dirk am 27 August 2014, 11:52:08
Er benutzt den Sensor an einer CCU. Der Sensor liefert nur den Luftdruck. Die Korrektur für den Luftdruck bezogen auf Meereshöhe mach das FHEM-Modul. Das kann die CCU so (noch) nicht.
FHEM zeigt den gemessenen Luftdruck (derzeit ca 950 hPA) meines Standorts (ca 520m über NN) im Reading "pressure". Wo liefert denn das Modul den Luftdruck bezogen auf Meereshöhe (NN)?
Gruß
Tobias
ZitatWo liefert denn das Modul den Luftdruck bezogen auf Meereshöhe (NN)?
pressure-nn. gleich daneben.
gruss frank
Zitat von: tpm88 am 11 Oktober 2014, 12:39:51
Longitude und Latitude sind in global gesetzt.
Diese beiden Attribute sind für die Brechnung des Luftdrucks bezogen auf Meereshöhe irrelevant.
Dafür musst du das globale Attribute Altitude setzen.
Zitat von: Dirk am 11 Oktober 2014, 13:27:50
Dafür musst du das globale Attribute Altitude setzen.
Danke Frank & Dirk - wer lesen kann, ist klar im Vorteil... Dabei steht es sogar in dem Zitat von Betateilchen, das ich in meiner Frage kopiert habe. ::)
Hier noch eine Gute und Schlechte Nachricht für die Freunde der CCU und dem Firmwareupdate über die CCU.
Die Gute Nachricht:
Das Firmwareupdate über die CCU2 / LXCCU mit HM-LAN-GW (dem neuen) funktioniert jetzt.
Zumindestens bei mir. Falls mich noch jemand beim Testen unterstützen möchte. Sehr gerne.
Die schlechte Nachricht:
Leider nicht mit dem derzeitig installierten Bootloader (0.6.1)
Siehe hier: http://forum.fhem.de/index.php/topic,18071.msg207192.html#msg207192
Viele Grüße
Dirk
Jetzt habe ich mir extra einen HM-CFG-USB-2 besorgt ;-) .
Das Firmwareupdate hat damit auf dem AUssensensor schon mal funktioniert. Nach Ab- und wieder Anleren wurde auch die V0.13 Firmware angezeigt. Leider läuft noch irgendetwas beim Einspielen der HB-UW-Sen-THPL_CCU-addon.tgz schief. Unter /firmware/rftypes liegt lediglich die alte hb_uw_sen_thpl.xml. Weder die neue hb_uw_sen_thpl.xml noch die hb_uw_sen_thpl_le_v0_11.xml werden kopiert.
Zitat von: Dirk am 11 Oktober 2014, 23:35:04
Hier noch eine Gute und Schlechte Nachricht für die Freunde der CCU und dem Firmwareupdate über die CCU.
Die Gute Nachricht:
Das Firmwareupdate über die CCU2 / LXCCU mit HM-LAN-GW (dem neuen) funktioniert jetzt.
Zumindestens bei mir. Falls mich noch jemand beim Testen unterstützen möchte. Sehr gerne.
Die schlechte Nachricht:
Leider nicht mit dem derzeitig installierten Bootloader (0.6.1)
Siehe hier: http://forum.fhem.de/index.php/topic,18071.msg207192.html#msg207192
Viele Grüße
Dirk
Vielleicht kann ich Dich ja hier besser beim Testen unterstützen. Mein Innensensor ist genau dafür gedacht. Sofort einsatzbereit wäre auch ein ISP (http://www.ebay.de/itm/331211711785). Raspi und Arduino Uno müsste ich erst aktivieren.
Zitat von: cactus-online am 12 Oktober 2014, 13:27:49
Leider läuft noch irgendetwas beim Einspielen der HB-UW-Sen-THPL_CCU-addon.tgz schief. Unter /firmware/rftypes liegt lediglich die alte hb_uw_sen_thpl.xml. Weder die neue hb_uw_sen_thpl.xml noch die hb_uw_sen_thpl_le_v0_11.xml werden kopiert.
Das einfache Überkopieren des Addon funktioniert noch noch nicht. Das kommt die Tage noch.
Akzuell gibt es aber 2 alternativen:
- Die neuen XML-Dateien manuell auf die CCU kopieren. Die alte hb_uw_sen_thpl.xml vorher löschen und anschliessend die CCU neu starten.
- Das Addon komplett von der CCU löschen. Das geht aber nur durch ein Firmwareupdate.
Also so:
- Backup der CCU anlegen
- letzte Firmware auf die CCU einspielen. Damit ist das Addon dann wieder von der CCU verschwunden.
- Addon erneut installieren
- Backup wieder zurück spielen
ZitatSofort einsatzbereit wäre auch ein ISP (http://www.ebay.de/itm/331211711785). Raspi und Arduino Uno müsste ich erst aktivieren.
ISP ist super.
Die Anschlussbelegung ist hier:
http://forum.fhem.de/index.php/topic,20620.msg203302.html#msg203302
Du musst den ISP aber auf 3,3 V einstellen.
Das Flash-Tool was ich zusammengestrickt habe funktioniert derzeit aber nur unter Windows.
Das habe ich aber noch nicht in Github. Das kann ich dir aber schicken.
Gruß
Dirk
Schweren Herzens starte ich auch mal Windows. Also kann ich das Windows Tool nutzen. Sag' einfach (möglichst genau) was ich tun soll.
Zitat von: Dirk am 13 Oktober 2014, 11:01:45
Das einfache Überkopieren des Addon funktioniert noch noch nicht. Das kommt die Tage noch.
Akzuell gibt es aber 2 alternativen:
- Die neuen XML-Dateien manuell auf die CCU kopieren. Die alte hb_uw_sen_thpl.xml vorher löschen und anschliessend die CCU neu starten.
- Das Addon komplett von der CCU löschen. Das geht aber nur durch ein Firmwareupdate.
Also so:
- Backup der CCU anlegen
- letzte Firmware auf die CCU einspielen. Damit ist das Addon dann wieder von der CCU verschwunden.
- Addon erneut installieren
- Backup wieder zurück spielen
Gruß
Dirk
Ja von Hand geht das schon. Mir ist nur noch nicht ganz klar, wo das Problem liegt. Wie legt denn das Script das Directory /mnt-root überhaupt an, das liegt (im normalen Betrieb) auf einem ro Filesystem? Allerdings kann ich den Mount-Befehl mount -t ubifs ubi0:root auch nicht ausführen, wenn ich statt /mnt-root z.B. /tmp/mnt-root verwende (auch wenn dieses Direktory existiert):
mount: mounting ubi0:root on /tmp/mnt-root failed: Device or resource busy
@Dirk
ich habe ja von dir den Aussen Sensor neu bekommen, ist das richtig das dieser mir jetzt den Luftdruck so anzeigt:
pressure 10028
pressure-nn 10056
Ich frage ja diesen in meiner RSS layout Datei folgendermaßen ab: da steht dann eben 10028 ist etwas krass..! ;)
{ ReadingsVal('Aussensensor_Terrasse','pressure','')." hPa"}
kann ich das wieder richtig einstellen..? ich weiß leider nicht wie. :-\
Schau mal bitte welche Firmware der neue Sensor hat.
Es kann sein das die schon neuer als die des "alten" Sensors ist.
Dann muss du die aktuelle HMConfig_SenTHPL.pm aus dem Github bei dir kopieren.
Gruß
Dirk
D-firmware 0.12
welche muss ich nehmen, dort finde ich 4 Stück... Ah jetzt bin ich richtig diese bestimmt Wettersensor / Contrib / FHEM
Zitat von: moonsorrox am 15 Oktober 2014, 12:55:23
D-firmware 0.12
welche muss ich nehmen, dort finde ich 4 Stück... Ah jetzt bin ich richtig diese bestimmt Wettersensor / Contrib / FHEM
Die Version für die 0.12er ist hier:
https://github.com/kc-GitHub/Wettersensor/blob/v0.12/Tools/FHEM/HMConfig_SenTHPL.pm
Unter Wettersensor / Contrib / FHEM in der Masterbranch ist die aktuellen Entwickler- / Beta-Version
Die geht zwar auch, du bekommst hier aber ggf. Register und Funktonen angezeigt, welche die 0.12er FW noch nicht unterstützt / verarbeitet.
Ok, habe ich drin bekomme aber nach wie vor diese Werte:
2014-10-15_13:19:29 Aussensensor_Terrasse T: 14.3 L: 22.35 P: 10029 P-NN: 10057 batVoltage: 2.82
etwas Geduld ist gefragt ;)
2014-10-15_13:24:38 Aussensensor_Terrasse T: 14.2 L: 15.37 P: 1002.8 P-NN: 1030.4
FHEM neu gestartet?
Wirklich die richtige Datei kopiert?
Du müsste da drinn diese Zeilen finden:
if ($pressure) {
$pressure = $pressure / 10;
habe editiert oben ;) alles da
2014-10-15_13:27:49 Aussensensor_Terrasse T: 14.2 L: 11.64 P: 1002.8 P-NN: 1030.4
2014-10-15_13:27:49 Aussensensor_Terrasse pressure-nn: 1030.4
2014-10-15_13:27:49 Aussensensor_Terrasse pressure: 1002.8
2014-10-15_13:27:49 Aussensensor_Terrasse luminosity: 11.64
2014-10-15_13:27:49 Aussensensor_Terrasse batVoltage: 2.80
2014-10-15_13:27:49 Aussensensor_Terrasse battery: ok
Zitat von: cactus-online am 13 Oktober 2014, 12:24:22
Schweren Herzens starte ich auch mal Windows. Also kann ich das Windows Tool nutzen. Sag' einfach (möglichst genau) was ich tun soll.
Benötigst Du noch Unterstützung beim Testen ?
Zitat von: cactus-online am 15 Oktober 2014, 17:20:54
Benötigst Du noch Unterstützung beim Testen ?
Klar. Wird vermutlich aber erst heute abend.
Ich habe die Tage noch am Bootloader mit gefeilt. Siehe hier:
http://forum.fhem.de/index.php/topic,18071.0.html
Der neue Bootloader kann sich auch selber Updaten. Dann kannst du zumindest hierfür auf Windows in Zukunft verzichten.
Gruß
Dirk
Zitat von: Dirk am 15 Oktober 2014, 17:23:30
Klar. Wird vermutlich aber erst heute abend.
bis 2 in der früh kann ich dir helfen
lg
bullshit
Hallo,
anbei ist das Hexfile mit dem neuen Bootloader und einer 0.13er Version von der Firmware.
Bitte dann auch den Quellcode vom Bootloader von Github herunter laden:
https://github.com/kc-GitHub/Asksin_OTA_Bootloader
Unter Tools/Flash-Tool-Windows liegt das Flashtool. Der Rest wird nicht benötigt.
Das Flash-Tool kann unter Windows genutzt werden um die Firmware direkt in den Sensor zu "brennen".
Wer unter Windows direkt Programmieren möchte macht dann folgendes:
Zum Prüfen ob die Kommunikation mit dem ISP-Adapter steht:
bin\avrdude -p m328p -c usbaspDas Ergebnis sollte dann ungefähr so aussehen:
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.03s
avrdude: Device signature = 0x1e950f
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Das Flashen starten man dann so:
flash.cmd usbasp WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-THPL.hex F1:02 AA:BB:CC ABCDEFGHIJ
usbasp: Das ist der ISP-Programmer den ich aktuell benutze. Hier kann auch ein anderer angegeben werden den AVRDUDE unterstützt.
Bei AA:BB:CC geb ihr eure HM-ID ein, bei "ABCDEFGHIJ" kommt eure Seriennummer hin.
Dann sollte das Programmieren beginnen.
Das sollte dann ungefähr so aussehen:
****************************************
* Set fusebits with bitClock 187,5 KHz *
****************************************
avrdude.exe: set SCK frequency to 187500 Hz
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.03s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: erasing chip
avrdude.exe: set SCK frequency to 187500 Hz
avrdude.exe: reading input file "0xE2"
avrdude.exe: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0xE2:
avrdude.exe: load data lfuse data from input file 0xE2:
avrdude.exe: input file 0xE2 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.01s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0xD0"
avrdude.exe: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0xD0:
avrdude.exe: load data hfuse data from input file 0xD0:
avrdude.exe: input file 0xD0 contains 1 bytes
avrdude.exe: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.01s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of hfuse verified
avrdude.exe: reading input file "0x06"
avrdude.exe: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude.exe: 1 bytes of efuse written
avrdude.exe: verifying efuse memory against 0x06:
avrdude.exe: load data efuse data from input file 0x06:
avrdude.exe: input file 0x06 contains 1 bytes
avrdude.exe: reading on-chip efuse data:
Reading | ################################################## | 100% 0.01s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of efuse verified
avrdude.exe: safemode: Fuses OK
avrdude.exe done. Thank you.
*************************************************************************
* Write bootloader, application and set lock bits with bitClock 1,5 MHz *
*************************************************************************
avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.03s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: reading input file "WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-THPL.bin"
avrdude.exe: writing flash (32768 bytes):
Writing | ################################################## | 100% 6.99s
avrdude.exe: 32768 bytes of flash written
avrdude.exe: verifying flash memory against WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-THPL.bin:
avrdude.exe: load data flash data from input file WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-THPL.bin:
avrdude.exe: input file WetterSensor+AskSinBootloader_HB-UW-Sen-THPL.bin contains 32768 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 5.86s
avrdude.exe: verifying ...
avrdude.exe: 32768 bytes of flash verified
avrdude.exe: reading input file "0x3F"
avrdude.exe: writing lock (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude.exe: 1 bytes of lock written
avrdude.exe: verifying lock memory against 0x3F:
avrdude.exe: load data lock data from input file 0x3F:
avrdude.exe: input file 0x3F contains 1 bytes
avrdude.exe: reading on-chip lock data:
Reading | ################################################## | 100% 0.01s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lock verified
avrdude.exe: safemode: Fuses OK
avrdude.exe done. Thank you.
Wer lieber unter Linux mit einem "eigenen" AVRDUDE Flashen möchte der muss trotzdem einmal das obrige Kommando ausführen.
Es kommen dann von AVRDUDE jede Menge Fehlermeldungen, diese können aber ignoriert werden.
Das wichtige: es wird eine Datei angelegt WetterSensor+AskSinBootloader_HB-UW-Sen-THPL.bin.
Diese enthält dann eure oben eingegebenen Adressdaten.
Die Bin-Datei kann dann direkt mit AVRDUDE geflasht werden.
avrdude -cusbasp -patmega328p -B0.5 -Uflash:w:WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-THPL.bin.bin:r -Ulock:w:0x3F:m
Wenn das fertig ist, ist der neue Bootloader und eine ältere Test-Firmware mit der Version 0.11 auf dem Sensor die alle 10 Sekunden sendet.
Weiter im Anhang sind Firmwaredateien der Version 0.13 für den Innen- und Außensensor.
Diese können direkt mit der CCU geflasht werden. Zum flashen mit dem USB-CGF-Adapter oder dem CUL muss man das TGZ auspacken und die eq3-Datei benutzen.
Das Flashen auf der CCU läuft dann so ab:
- Die Firmwaredatei auf die CCU hochladen.
- In die Geräteeinstellungen gehen. Hier sollte sich jetzt ein Update-Button befinden
- Den Bootloader vom Sensor starten: Die Batterie aus dem Sensor nehmen, die Configtaste gedrückt halten und die Batterie wieder einlegen. Dabei die Configtaste gedrückt halten und den Update-Button im UI der CCU anklicken. Dann sollte das Update beginnen. Die LED am Sensor sollte dann Blinken so lange das Update läuft.
- Wenn das Update nicht startet wird ggf. eine Fehlermeldung angezeigt und eine Servicemeldung "Firmwareupdate steht an" wird in der CCU abgelegt. Jetzt kann man das Update trotzdem noch starten indem man den Bootloader vom Sensor erneut startet. Siehe oben.
Die Firmwaredatei (TGZ) trägt zwar die Nummer 0.14 die CCU zeigt diese Version zwar auch an, Dennoch wird die Version 0.13 auf den Sensor geflasht.
Wenn man den Sensor nach dem Flashen von der CCU abmeldet und wieder anmeldet, wird dann auch korrekterweise die Version 0.13 angezeigt.
Da das Firmwarefile sich aber der CCU gegenüber als 0.14er Version ausgibt, kann man das Flashen so oft wiederholen wie man möchte.
@bullshit und cactus-online @alle anderen Tester
Ich hoffe Ihr kommt mit den Anweisungen so zurecht.
Gruß
Dirk
Damit auch die CCU-Only-User das Update des Bootloaders durchführen können, ohne eine neue Adresse zu vergeben: So könnt ihr die Adresse des Sensors auf der CCU so ermitteln:
Per Telnet / SSH auf die CCU gehen:
cat /etc/config/rfd/<seriennummer>.dev
In der ersten Zeile steht dann unter "address" eine 3-Bit Hex-Zahl.
Das ist die Adresse.
Gruß
Dirk
Die Anweisungen scheinen ausführlich zu sein. Ich kämpfe aber gerade noch mit einem Anfängerproblem. Ich muss noch die richtige Verbindung zwischen USBASP und dem Sensor herausfinden. Ich dächte das auch schon gelesen zu haben, habe mir aber nicht gemerkt wo. Wühle mich also gerade durch 79 Seiten ... .
ZitatWühle mich also gerade durch 79 Seiten ... .
fang hinten an. ;) beitrag 1159 hat ein link.
Ich wusste es doch ! (http://forum.fhem.de/index.php/topic,20620.msg203302.html#msg203302)
Tausend Dank.
Hallo Zusammen,
nachdem is keinen isp programmer oder gleichen habe wollte ich natürlich den Raspberry Pi zum flashen des bootloaders benutzen.
Mithilfe des Windows flash.cmd und der Anleitung auf http://www.lxccu.com/hb-raspberry-bootloader-update (http://www.lxccu.com/hb-raspberry-bootloader-update) habe ich nun ein perl Skript wie bei der "Wetterstation FIrmware" geschrieben. https://github.com/bullshit/AskSinBootloader_Flash-Tool-RaspberryPi (https://github.com/bullshit/AskSinBootloader_Flash-Tool-RaspberryPi)
Von mir aus kannst du Dirk es ja als git module in den AskinBootloader Repository einbinden.
Nun gesagt getan. Der Flash vorgang ging reibungslos.
root@pi:~/Flash-Tool-RaspberryPi# perl flash.pl WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-THPL.hex F1:02 XX:XX:XX 123456789A
Test Bootloader connection
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Write Bootloader
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e950f
avrdude: erasing chip
avrdude: reading input file "WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-THPL.bin"
avrdude: writing flash (32768 bytes):
Writing | ################################################## | 100% 16.72s
avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-THPL.bin:
avrdude: load data flash data from input file WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-THPL.bin:
avrdude: input file WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-THPL.bin contains 32768 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 15.58s
avrdude: verifying ...
avrdude: 32768 bytes of flash verified
avrdude: reading input file "0x2F"
avrdude: writing lock (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x2F:
avrdude: load data lock data from input file 0x2F:
avrdude: input file 0x2F contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
danach hab ich mich auf die serielle console des sensors gehängt und mal nachgesehen was es beim neu einlegen der Batterien sagt.
AskSin OTA Bootloader V0.7.0
Start App
<- 14 00 A2 70 4B 61 4D 26 67 FF 01 0E 00 03 D4 00 00 10 7E 09 D6 (l:21)(2017)
-> 0A 00 80 02 26 67 FF 4B 61 4D 00 (l:11)(2158)
Vorher war der 0.6 Bootloader drauf also hat wirklich alles funktioniert.
Danach auf der lxccu die Firmware aus diesem Forum unter Geräte-Firmware hochgeladen.
Nun auf dem Sensor ist noch immer die Firmware 0.11 und leider taucht nirgends ein Firmware-Upgrade Button auf.
Danach hab ich die xml Files von https://github.com/kc-GitHub/Wettersensor/tree/master/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon-src/firmware/rftypes (https://github.com/kc-GitHub/Wettersensor/tree/master/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon-src/firmware/rftypes) händisch raufkopiert und die lxccu neu gestartet. Ab dann wird auch wieder der Luftdruck angezeigt. Aber wieder kein update.
Danach hab ich die Batterien entfernt. Die configtaste gedrückt gehalten und die batterien eingesetzt wie im changelog des firmware upgrades beschrieben auch auch hier hat sich nichts getan.
Anbei hab ich noch ein paar Screenshots angehängt.
Wenn ich die Firmware auf die lxccu hochlade erscheint folgendes in dem hmserver.log
Zitat
==> hmserver.log <==
Oct 17 01:54:56 de.eq3.ccu.system.http.service.DeviceFirmwareController INFO [pool-2-thread-27] /etc/config/firmware/61698 created!
Oct 17 01:54:56 freemarker.cache DEBUG [pool-2-thread-27] "AvailableFirmware.ftl"["en_US",ISO-8859-1,parsed] using cached since /opt/HMServer/pages/AvailableFirmware.ftl didn't change.
Hab dann natürlich in den Ordner auch mal reingesehen
# cd /etc/config/firmware/61698/
# ls
HB-UW-Sen-THPL_update_V0_14_000_141015.eq3 changelog.txt info
# cat info
TypeCode=61698
Name=HB-UW-Sen-THPL-O
CCUFirmwareVersionMin=2.9.0
FirmwareVersion=0.14
# md5sum HB-UW-Sen-THPL_update_V0_14_000_141015.eq3
5b74977551ffac823c717dcb5b973147 HB-UW-Sen-THPL_update_V0_14_000_141015.eq3
# ls -lh HB-UW-Sen-THPL_update_V0_14_000_141015.eq3
-rw-r--r-- 1 root root 56.9K Oct 17 01:54 HB-UW-Sen-THPL_update_V0_14_000_141015.eq3
Besten Dank vorerst. Bin gespannt an was das liegt.
lg
bullshit
Hast du eine Servicemeldung dass einen neue Firmware zum Update bereitsteht?
Nein. Keine Servicemeldung. Hatte nur zwei Meldungen das die Kommunikation gestört war.
Schau mal ob du die richtige Update-Datei auf die CCU geladen hast. Für Innen- und Außensensor gibt es je eine.
Die existierende XML-Datei hattest du auch sicher überschrieben?
Das sind die einzigen 2 Punkte die mir einfallen warum du kein Update-Button siehst.
Bootloaderversion an sich ist zur Anzeige des Buttons erst mal unrelevant.
Auch bein einem Sensor mit Bootloader < 0.7.0 muss der Updatebutton angezeigt werden, wenn die richtigen XML-Dateien und das zur Sensorversion passende Updatefile auf der CCU sind.
Gruß
Dirk
Hier der Auszug der xml files. Geflasht hab ich den Aussensensor.
# cd /firmware/rftypes/
# ls
hb_uw_sen_thpl.xml rf_d.xml rf_fs_ba.xml rf_rhs_e_v1_7.xml rf_sec_mdir_v1_5.xml
hb_uw_sen_thpl_le_v0_11.xml rf_d_le_v1_7.xml rf_keymatic.xml rf_rhs_le_v1_6.xml rf_sec_sco.xml
replaceMap rf_d_le_v1_9.xml rf_ks550.xml rf_roto_wdf_solar.xml rf_sec_sd.xml
rf_4dis.xml rf_ddc.xml rf_ou_led16_ge_v1_1.xml rf_s.xml rf_sec_sd_schueco.xml
rf_ash550.xml rf_dim_1l_644.xml rf_ou_led16_le_v1_0.xml rf_s550ia.xml rf_sec_sfa.xml
....
....
....
# cat hb_uw_sen_thpl.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<device version="2" rx_modes="CONFIG,WAKEUP,LAZY_CONFIG" cyclic_timeout="600">
<supported_types>
<type name="HB-UW-Sen-THPL-I" id="HB-UW-Sen-THPL-I" updatable="true">
<parameter index="9.0" size="1.0" cond_op="GE" const_value="12" />
<parameter index="10.0" size="2.0" const_value="0xF101" />
</type>
<type name="HB-UW-Sen-THPL-O" id="HB-UW-Sen-THPL-O">
<parameter index="9.0" size="1.0" cond_op="GE" const_value="12" />
<parameter index="10.0" size="2.0" const_value="0xF102"></parameter>
</type>
</supported_types>
<paramset type="MASTER" id="hb_uw_sen_thpl_dev_master">
<parameter id="BURST_RX">
<logical type="boolean" default="false" />
<physical type="integer" interface="config" list="0" index="1" size="1.0" />
</parameter>
<parameter id="DEVICE_LED_MODE">
<logical type="option">
<option id="OFF" default="true" />
<option id="ON" />
</logical>
<physical type="integer" interface="config" list="0" index="5.6" size="0.2" />
<conversion type="integer_integer_map">
<value_map device_value="0x00" parameter_value="0" />
<value_map device_value="0x01" parameter_value="1" />
</conversion>
</parameter>
<parameter id="LOW_BAT_LIMIT">
<logical type="float" min="1.0" max="5" default="2.6" unit="V" />
<physical type="integer" interface="config" list="0" index="18" size="1" />
<conversion type="float_integer_scale" factor="10" />
</parameter>
<parameter id="TRANSMIT_DEV_TRY_MAX">
<logical type="integer" min="1.0" max="10" default="6" />
<physical type="integer" interface="config" list="0" index="20" size="1" />
</parameter>
<parameter id="Altitude">
<logical type="integer" min="-500" max="10000" default="0" unit="m" />
<physical type="integer" interface="config" list="0" index="36" size="2" />
</parameter>
</paramset>
<channels>
<channel index="0" type="MAINTENANCE" ui_flags="internal" class="maintenance" count="1">
<paramset type="MASTER" id="maint_ch_master"></paramset>
<paramset type="VALUES" id="maint_ch_values">
<parameter id="UNREACH" operations="read,event" ui_flags="service">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="UNREACH" />
</parameter>
<parameter id="STICKY_UNREACH" operations="read,write,event" ui_flags="service,sticky">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="STICKY_UNREACH" />
</parameter>
<parameter id="CONFIG_PENDING" operations="read,event" ui_flags="service">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="CONFIG_PENDING" />
</parameter>
<parameter id="LOWBAT" operations="read,event" ui_flags="service">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="LOWBAT" />
</parameter>
<parameter id="RSSI_DEVICE" operations="read,event">
<logical type="integer" />
<physical type="integer" interface="internal" value_id="RSSI_DEVICE" />
</parameter>
<parameter id="RSSI_PEER" operations="read,event">
<logical type="integer" />
<physical type="integer" interface="internal" value_id="RSSI_PEER" />
</parameter>
<parameter id="DEVICE_IN_BOOTLOADER" operations="read,event" ui_flags="service">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="DEVICE_IN_BOOTLOADER" />
</parameter>
<parameter id="UPDATE_PENDING" operations="read,event" ui_flags="service">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="UPDATE_PENDING" />
</parameter>
</paramset>
</channel>
<channel index="1" type="WEATHER" autoregister="true">
<link_roles>
<source name="WEATHER_TH" />
</link_roles>
<paramset type="MASTER" id="hb_uw_sen_thpl_ch_master"></paramset>
<paramset type="VALUES" id="hb_uw_sen_thpl_ch_values">
<parameter id="TEMPERATURE" operations="read,event">
<logical type="float" min="-40.0" max="80.0" unit="�C" />
<physical type="integer" interface="command" value_id="TEMPERATURE">
<event frame="WEATHER_EVENT" />
</physical>
<conversion type="float_integer_scale" factor="10.0" />
<description>
<field id="AutoconfRoles" value="WEATHER" />
</description>
</parameter>
<parameter id="HUMIDITY" operations="read,event">
<logical type="integer" min="1" max="99" unit="%">
<special_value id="NO_SENSOR" value="0" />
</logical>
<physical type="integer" interface="command" value_id="HUMIDITY">
<event frame="WEATHER_EVENT" />
</physical>
<description>
<field id="AutoconfRoles" value="WEATHER" />
</description>
</parameter>
<parameter id="AIR_PRESSURE" operations="read,event">
<logical type="float" min="500.0" max="1100.0" unit="hPa">
<special_value id="NO_SENSOR" value="0.0" />
</logical>
<physical type="integer" interface="command" value_id="AIR_PRESSURE">
<event frame="WEATHER_EVENT" />
</physical>
<conversion type="float_integer_scale" factor="10.0" />
<description>
<field id="AutoconfRoles" value="WEATHER" />
</description>
</parameter>
<parameter id="LUMINOSITY" operations="read,event">
<logical type="float" min="0" max="65535">
<special_value id="NO_SENSOR" value="65538" />
</logical>
<physical type="integer" interface="command" value_id="LUMINOSITY">
<event frame="WEATHER_EVENT" />
</physical>
<conversion type="float_integer_scale" factor="100.0" />
</parameter>
<parameter id="BatteryVoltage" operations="read,event">
<logical type="float" min="0.4" max="5.5" unit="V" />
<physical type="integer" interface="command" value_id="BatteryVoltage">
<event frame="WEATHER_EVENT" />
</physical>
<conversion type="float_integer_scale" factor="1000.0" />
</parameter>
</paramset>
<paramset type="LINK" id="hb_uw_sen_thpl_ch_link"></paramset>
</channel>
</channels>
<frames>
<frame id="WEATHER_EVENT" direction="from_device" event="true" fixed_channel="1" type="0x70">
<parameter type="integer" signed="true" index="9.0" size="1.7" param="TEMPERATURE" />
<parameter type="integer" index="11.0" size="1.0" param="HUMIDITY" />
<parameter type="integer" index="12.0" size="2.0" param="AIR_PRESSURE" />
<parameter type="integer" index="14.0" size="4.0" param="LUMINOSITY" />
<parameter type="integer" index="18.0" size="2.0" param="BatteryVoltage" />
</frame>
</frames>
<paramset_defs></paramset_defs>
</device>
# cat hb_uw_sen_thpl_le_v0_11.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<device version="1" rx_modes="CONFIG" cyclic_timeout="600">
<supported_types>
<type name="HB-UW-Sen-THPL-I" id="HB-UW-Sen-THPL-I">
<parameter index="9.0" size="1.0" cond_op="LE" const_value="11" />
<parameter index="10.0" size="2.0" const_value="0xF101" />
</type>
<type name="HB-UW-Sen-THPL-O" id="HB-UW-Sen-THPL-O">
<parameter index="9.0" size="1.0" cond_op="LE" const_value="11" />
<parameter index="10.0" size="2.0" const_value="0xF102" />
</type>
</supported_types>
<paramset type="MASTER" id="hb_uw_sen_thpl_dev_master"></paramset>
<channels>
<channel index="0" type="MAINTENANCE" ui_flags="internal" class="maintenance" count="1">
<paramset type="MASTER" id="maint_ch_master"></paramset>
<paramset type="VALUES" id="maint_ch_values">
<parameter id="UNREACH" operations="read,event" ui_flags="service">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="UNREACH" />
</parameter>
<parameter id="STICKY_UNREACH" operations="read,write,event" ui_flags="service,sticky">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="STICKY_UNREACH" />
</parameter>
<parameter id="CONFIG_PENDING" operations="read,event" ui_flags="service">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="CONFIG_PENDING" />
</parameter>
<parameter id="LOWBAT" operations="read,event" ui_flags="service">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="LOWBAT" />
</parameter>
<parameter id="RSSI_DEVICE" operations="read,event">
<logical type="integer" />
<physical type="integer" interface="internal" value_id="RSSI_DEVICE" />
</parameter>
<parameter id="RSSI_PEER" operations="read,event">
<logical type="integer" />
<physical type="integer" interface="internal" value_id="RSSI_PEER" />
</parameter>
<parameter id="DEVICE_IN_BOOTLOADER" operations="read,event" ui_flags="service">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="DEVICE_IN_BOOTLOADER" />
</parameter>
<parameter id="UPDATE_PENDING" operations="read,event" ui_flags="service">
<logical type="boolean" />
<physical type="integer" interface="internal" value_id="UPDATE_PENDING" />
</parameter>
</paramset>
</channel>
<channel index="1" type="WEATHER" autoregister="true">
<link_roles>
<source name="WEATHER_TH" />
</link_roles>
<paramset type="MASTER" id="hb_uw_sen_thpl_ch_master"></paramset>
<paramset type="VALUES" id="hb_uw_sen_thpl_ch_values">
<parameter id="TEMPERATURE" operations="read,event">
<logical type="float" min="-40.0" max="80.0" unit="�C" />
<physical type="integer" interface="command" value_id="TEMPERATURE">
<event frame="WEATHER_EVENT" />
</physical>
<conversion type="float_integer_scale" factor="10.0" />
<description>
<field id="AutoconfRoles" value="WEATHER" />
</description>
</parameter>
<parameter id="HUMIDITY" operations="read,event">
<logical type="integer" min="1" max="99" unit="%">
<special_value id="NO_SENSOR" value="0" />
</logical>
<physical type="integer" interface="command" value_id="HUMIDITY">
<event frame="WEATHER_EVENT" />
</physical>
<description>
<field id="AutoconfRoles" value="WEATHER" />
</description>
</parameter>
<parameter id="AIR_PRESSURE" operations="read,event">
<logical type="integer" min="500" max="1100" unit="hPa">
<special_value id="NO_SENSOR" value="0" />
</logical>
<physical type="integer" interface="command" value_id="AIR_PRESSURE">
<event frame="WEATHER_EVENT" />
</physical>
<description>
<field id="AutoConfRoles" value="WEATHER" />
</description>
</parameter>
<parameter id="LUMINOSITY" operations="read,event">
<logical type="float" min="0" max="65535">
<special_value id="NO_SENSOR" value="65538" />
</logical>
<physical type="integer" interface="command" value_id="LUMINOSITY">
<event frame="WEATHER_EVENT" />
</physical>
<conversion type="float_integer_scale" factor="100.0" />
</parameter>
<parameter id="BatteryVoltage" operations="read,event">
<logical type="float" min="0.4" max="5.5" unit="V" />
<physical type="integer" interface="command" value_id="BatteryVoltage">
<event frame="WEATHER_EVENT" />
</physical>
<conversion type="float_integer_scale" factor="1000.0" />
</parameter>
</paramset>
<paramset type="LINK" id="hb_uw_sen_thpl_ch_link"></paramset>
</channel>
</channels>
<frames>
<frame id="WEATHER_EVENT" direction="from_device" event="true" fixed_channel="1" type="0x70">
<parameter type="integer" signed="true" index="9.0" size="1.7" param="TEMPERATURE" />
<parameter type="integer" index="11.0" size="1.0" param="HUMIDITY" />
<parameter type="integer" index="12.0" size="2.0" param="AIR_PRESSURE" />
<parameter type="integer" index="14.0" size="4.0" param="LUMINOSITY" />
<parameter type="integer" index="18.0" size="2.0" param="BatteryVoltage" />
</frame>
</frames>
<paramset_defs></paramset_defs>
</device>
Ich hab dann die "HB-UW-Sen-THPL_update_V0_14_000_141015-O.tgz" unter Geräte-Firmware hochgeladen und ich hab natürlich das neue Lan-Gateway mit der Firmware 1.1.4
Oct 17 14:51:21 homematic-ccu2 user.info logger: Updating RF Lan Gateway Firmware
Oct 17 14:51:21 homematic-ccu2 user.info update-lgw-firmware: LAN Gateway Firmware Update...
Oct 17 14:51:21 homematic-ccu2 user.info update-lgw-firmware: Gateway KEQ10XXXXX
Oct 17 14:51:23 homematic-ccu2 user.info update-lgw-firmware: Gateway type is eQ3-HM-LGW-App
Oct 17 14:51:23 homematic-ccu2 user.info update-lgw-firmware: Available Firmware Version: 1.1.4
Oct 17 14:51:23 homematic-ccu2 user.info update-lgw-firmware: Lan Gateway Firmware Version: 1.1.4
Okey ich hab jetzt die XML Files von Franz schicken lassen und siehe da der Update-Button ist da
Ich habe den neuen Bootloader auf den Innensensor aufgespielt. Das hat geklappt -> allerdings ist er nun ein Außensensor. (Kann ich das wieder hinbiegen ?)
Ich konnte auch ein Firmwareupdate per CCU durchführen. Prima Leistung Dirk ! Vielen Dank. Der Updatebutton ist auch für den (richtigen) Außensensor vorhanden. Funktioniert aber nicht. Ist (noch) kein neuer Bootloader drauf. Das Verhalten ist korrekt so ?
Ah mist. Ich habe grade gesehen dass ich meine Repository-Struktur geändert habe. Und die Änderungen sind noch nicht im GIT.
Sorry für die Verwirrung. Ich hole das die tage noch nach.
Anbei schon mal die aktuellen XML-Dateien für alle anderen bis das Repo wieder aktuell ist.
Aber gut dass es jetzt geht. Ich hoffe der Updateprozess klappt bei dir jetzt auch.
Zitat von: cactus-online am 17 Oktober 2014, 21:53:14
Ich habe den neuen Bootloader auf den Innensensor aufgespielt. Das hat geklappt -> allerdings ist er nun ein Außensensor. (Kann ich das wieder hinbiegen ?)
Ja. Type F1:01 ist der Innensensor, F1:02 ist der Außensensor.
Du musst also noch mal Flashen.
ZitatFunktioniert aber nicht. Ist (noch) kein neuer Bootloader drauf. Das Verhalten ist korrekt so ?
Das hab ich grade nicht verstanden. Was funktioniert nicht?
Gruß
Dirk
Zitat von: Dirk am 17 Oktober 2014, 21:56:35
Aber gut dass es jetzt geht. Ich hoffe der Updateprozess klappt bei dir jetzt auch.
Ja. Type F1:01 ist der Innensensor, F1:02 ist der Außensensor.
Du musst also noch mal Flashen.
Grr, ich habe gerade die Kabel abgelötet. OTA geht nicht, oder ?
Zitat von: Dirk am 17 Oktober 2014, 21:56:35
Das hab ich grade nicht verstanden. Was funktioniert nicht?
Gruß
Dirk
Es startet kein OTA-Update über die CCU. Der Außensensor hat noch den von Dir ausgelieferten Bootloader. Aber schon V.13 Firmware.
Hallo Dirk,
update hat super funktioniert. Auch die Einstellungen wurden erfolgreich übertragen. Echt coole Sache. Problem vorher waren wirklich meine XML Files.
Mir fällt da gerade noch etwas auf. Wenn ich die Konfiguration ändere dann erwartet die CCU ja wohl, dass man die Config-Taste drückt. Drücke ich die Config-Taste (kurz) werden die Einstellungen von der CCU gesendet, aber der Sensor hört gar nicht mehr auf zu blinken ... .
Zitat von: cactus-online am 17 Oktober 2014, 22:06:03
Mir fällt da gerade noch etwas auf. Wenn ich die Konfiguration ändere dann erwartet die CCU ja wohl, dass man die Config-Taste drückt. Drücke ich die Config-Taste (kurz) werden die Einstellungen von der CCU gesendet, aber der Sensor hört gar nicht mehr auf zu blinken ... .
ja ist mir auch aufgefallen. hat jetzt gut 5 minuten durchgeblinkt. erst nach rausnehmen der batterie hat sich die led beruhigt.
Zitat von: cactus-online am 17 Oktober 2014, 22:01:22
Grr, ich habe gerade die Kabel abgelötet. OTA geht nicht, oder ?
Die Seriennummer, HM-ID und Type-ID lässt sich nicht per OTA-Update ändern.
Du könntest dir eine Spezielle Firmware bauen in der die Daten fest codiert sind. Aber das müsstest du dann jedesmal bei einem Update machen.
Noch mal zum Lötkolben greifen ist da bestimmt einfacher :)
Es startet kein OTA-Update über die CCU. Der Außensensor hat noch den von Dir ausgelieferten Bootloader. Aber schon V.13 Firmware.
Der Bootloader < 0.7.0 kann keine OTAU-Update. Daher klappt das so nicht.
Zitat von: cactus-online am 17 Oktober 2014, 22:06:03
werden die Einstellungen von der CCU gesendet, aber der Sensor hört gar nicht mehr auf zu blinken ... .
Die 0.13er Version ist noch Beta. Das ist ein noch bekannter Fehler. Aber das hört auch wieder auf.
Daher solltest du am besten bis zur nächsten Stabilen ein Downgrade auf die 0.12er Version machen.
Das Update war erst mal ein Test für den Bootloader.
Gruß
Dirk
Zitat von: Dirk am 17 Oktober 2014, 22:09:37
Noch mal zum Lötkolben greifen ist da bestimmt einfacher :)
Garantiert. Gut das ich eine Leiste drauf gelötet habe und somit nicht immer auf der Platine rumfummeln muss.
Zitat von: Dirk am 17 Oktober 2014, 22:09:37
Es startet kein OTA-Update über die CCU. Der Außensensor hat noch den von Dir ausgelieferten Bootloader. Aber schon V.13 Firmware.
Der Bootloader < 0.7.0 kann keine OTAU-Update. Daher klappt das so nicht.
Nur über den HM-CFG-USB-2. Aber der Außensensor soll ja auch seinen neuen Bootloader bekommen.
Zitat von: Dirk am 17 Oktober 2014, 22:09:37
Die 0.13er Version ist noch Beta. Das ist ein noch bekannter Fehler. Aber das hört auch wieder auf.
Daher solltest du am besten bis zur nächsten Stabilen ein Downgrade auf die 0.12er Version machen.
Das Update war erst mal ein Test für den Bootloader.
Gruß
Dirk
Alles schick, mit DEM Bug kann ich leben.
Zitat von: cactus-online am 17 Oktober 2014, 22:14:50
Nur über den HM-CFG-USB-2. Aber der Außensensor soll ja auch seinen neuen Bootloader bekommen.
Die Pinbelegung ist mit dem des Innensensors identisch.
Daher funktioniert das Flashen per ISP hier genau so. Du musst dann nur den richtigen Type beim Flashen wieder einstellen.
ZitatAlles schick, mit DEM Bug kann ich leben.
Das ist bestimmt nicht der einzige. :)
Hallo Dirk,
wenn Du mal wieder am Wiki bist: Mir hätte es geholfen, wenn dort die Pinbelegung beschrieben gewesen wäre, so wie Du es z.B. für das Breakout-Modul sehr schön gemacht hast. Was mich dabei verwirrt hat, war das Foto mit dem Firmware-Update per RasPi. Da werden scheinbar andere Pins verwendet als beim USBASP.
Ansonsten ist mein Innensensor jetzt dank F1:01 wieder ein Innensensor und der Aussensensor ist mit F2:02 auch ein Aussensensor geblieben ;-) . Jetzt können die Firmwareupdates von mir aus kommen. So schön bequem wie das Einspielen jetzt geht.
Nochmal vielen Dank.
Hallo Dirk,
ich habe die ersten 20 Seiten komplett durch, und danach nur noch in 10er Schritten überflogen.
Ich weiß sicher, dass ich so ein paar Sensoren sehr gut gebrauchen könnte.
Deshalb ein auch für mich geltendes Zitat an dieser Stelle:Zitat@Dirk: kannst Du mir bitte auch Infos zur Sammelbestellung/Beschaffung senden? Vielen Dank!
Im Übrigen habe ich keinen Lötkolben. :-[
Gibt's die Sensoren auch komplett, oder was ist die Mindestanforderung an meine Fähigkeiten der Elektrotechnik?
Steht alles auf Seite 67 :)
So, Bestellung ist raus.
Noch eine Frage:
In der Aufstellung auf Seite 67 heißt es, beim "alten HM-LAN" würde das OTA update nicht funktionieren.
Ist dem noch so?
Und was heißt hier alt? Mein HM-CFG-LAN ist vor 3 Wochen gekauft. Ist das dann trotzdem alt?
Ich habe nun mit OTA Bootloader bestellt, da ich nicht seriell updaten will.
Muss ich mich dann schon mal wegen eines HM-CFG-USB umsehen?
ZitatMuss ich mich dann schon mal wegen eines HM-CFG-USB umsehen?
ja. oder cul. hmlan geht nicht.
OK.
Muss es der HM-CFG-USB2 sein, oder reicht auch der alte HM-CFG-USB?
OK, ich hab's gefunden.
Mit dem Updatetool von mgernoth sollte es auch mit der alten Version gehen, und mit der ELV Software nur mit der USB2.
http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update (http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update)
Zitat von: cactus-online am 18 Oktober 2014, 11:06:17
wenn Du mal wieder am Wiki bist: Mir hätte es geholfen, wenn dort die Pinbelegung beschrieben gewesen wäre
Das wird noch nachgeholt. Hier ist das aber auch schon mal beschrieben:
http://www.lxccu.com/hb-raspberry-bootloader-update
Zitat
Was mich dabei verwirrt hat, war das Foto mit dem Firmware-Update per RasPi. Da werden scheinbar andere Pins verwendet als beim USBASP.
Die Pinbelegung muss auch hier die Selbe sein.
@Pjg
Ich schicke die die Liste
Zitat von: Pjg am 21 Oktober 2014, 11:49:02
Gibt's die Sensoren auch komplett, oder was ist die Mindestanforderung an meine Fähigkeiten der Elektrotechnik?
Das sollte machbar sein.
ZitatUnd was heißt hier alt? Mein HM-CFG-LAN ist vor 3 Wochen gekauft. Ist das dann trotzdem alt?
Der "alte" HM-LAN-Adapter heisst jetzt HM-CFG-LAN und ist rund. Damit klappt es nicht.
Der "neue" HM-LAN-Adapter sieht aus wie eine CCU2 wird von FHEM mwn. aber noch nicht unterstützt.
ZitatMuss ich mich dann schon mal wegen eines HM-CFG-USB umsehen?
Das macht dann durchaus Sinn.
Viele Grüße
Dirk
Zitat von: cactus-online am 18 Oktober 2014, 11:06:17
Was mich dabei verwirrt hat, war das Foto mit dem Firmware-Update per RasPi. Da werden scheinbar andere Pins verwendet als beim USBASP.
Ich glaube ich weiß jetzt auf welches Foto du dich da beziehst. Du meinst das hier?
http://www.fhemwiki.de/wiki/Datei:CC1101-Sensor_Firmwareupdate_mit_dem_Raspberry_Pi.jpg
Das ist die Belegung wenn man das Update mit dem Raspberry Pi über den Seriellen Bootloader durchführen möchte.
Damit lässt sich aber kein Bootloader flashen.
Gruß
Dirk
Zitat von: Dirk am 22 Oktober 2014, 09:35:47
Das wird noch nachgeholt. Hier ist das aber auch schon mal beschrieben:
http://www.lxccu.com/hb-raspberry-bootloader-update
Die Pinbelegung muss auch hier die Selbe sein.
Viele Grüße
Dirk
Das kannte ich nicht. Allerdings hätte mir das auch nur bedingt geholfen. In dem dort dargestellten Fall muss der Sensor seine Betriebsspannung noch zusätzlich bekommen ((VCC) ist ja nicht belegt) und ich wüsste immer noch nicht, was die Anschlüsse eigentlich bedeuten.
Ich habe mir das dann auf einem Blatt Papier so aufgemalt:
GND RESET VCC SCK MISO MOSI
o o o o o o o o o o o o
o o o o o o o o o o o o
Wobei die obere Reihe die der Batteriehalterung entfernte Reihe ist (Innensensor). Auf jeden Fall liegt sie "über" dem Controller (Punkt auf dem Controller links) wie im o.g. Link für den Außensensor gut ersichtlich ist. Ich habe das nur noch mal direkt "aufgeschrieben" um anderen das Suchen zu erleichtern. Mit den Infos aus http://forum.fhem.de/index.php/topic,20620.msg203302.html#msg203302 (http://forum.fhem.de/index.php/topic,20620.msg203302.html#msg203302) und http://arduinodev.com/program_arduino_with_usbasp/ (http://arduinodev.com/program_arduino_with_usbasp/) sollte die nötige Beschaltung leicht zu finden sein.
Zitat von: Dirk am 22 Oktober 2014, 10:03:21
Ich glaube ich weiß jetzt auf welches Foto du dich da beziehst. Du meinst das hier?
http://www.fhemwiki.de/wiki/Datei:CC1101-Sensor_Firmwareupdate_mit_dem_Raspberry_Pi.jpg
Das ist die Belegung wenn man das Update mit dem Raspberry Pi über den Seriellen Bootloader durchführen möchte.
Damit lässt sich aber kein Bootloader flashen.
Gruß
Dirk
Ja genau das meinte ich. Ich habe das nicht aufmerksam genug gelesen. Firmware-Update vs. Bootloader-Update. Gut das Du es klar gestellt hast.
Jetzt wird mir einiges klaar ::)
Und ich hatte schon die ganze Zeit befürchtet ich wäre zu doof dafür... ???
Hallo,
zwei Sachen sind mir noch nicht klar:
HMID und Seriennummer können nicht über OTA-Update angepasst werden.
Das bedeutet doch vom Ablauf her:
1. Pairen mit mit FHEM um meine eigene HMID auf das Device zu bekommen. Dazu könnte ich die Seriennummer gebrauchen. --> Steht die auch auf dem Sensor, denkt sich da Dirk jeweils etwas initiales aus?
2. z.B. Firmwareupdate über ELV-Tool --> findet der HM-CFG-USB2 dann meinen neuen Sensor, wenn doch schon mit FHEM gepaired und damit die entsprechende hmid verinnerlicht hat?
Oder wäre der Abalauf anders, um ohne seriellen Firmwareupdate die Sensoren mit aktuellster Firmware in Betrieb nehmen zu können?
Das ist ganz einfach.
Die Seriennummer und die HM-ID befinden sich im Bootloader-Bereich.
In der Regel bekommst du das Teil schon fertig mit Bootloader. Dann sind hier die Daten schon "drin". Die Seriennummer steht dann auf dem Batteriefach.
Damit kann man dann das Firmwareupdate starten. Durch das Update werden die Daten nicht verändert.
Wenn man die Daten verändern möchte gibt es 2 Möglichkeiten:
1. Den Bootloader selber per ISP flashen. Dabei kann man diese Daten selber festlegen.
2. eine gepatchte selber kompilierte Firmware einspielen welche diese Daten fest Einkompiliert hat
Mal eine blöde Frage: Ich suche das "normale" Windows-Flashtool, um die Firmware auf die Sensoren aufzuspielen. Früher gab es im GIT ein Verzeichnis "Tools/Flashtool-Windows". Mag an mir liegen, aber ich seh das im aktuellen Repo nicht mehr und laut Log wurde das Repo umstrukturiert. Kann mir jemand sagen, wo ich das Flashtool jetzt her bekommen kann? Danke!
Ja. Ich habe das Repo etwas umstrukturiert.
Im v0.12er Tag ist es aber noch zu finden:
https://github.com/kc-GitHub/Wettersensor/tree/v0.12/Tools/Firmware/Flash-Tool-Windows
Ich baue das Flashtool auch noch etwas um, so dass das Platformübergreifend wird (Perl) und weitgehend ohne zusätzliche Binaries auskommt.
ZitatWenn man die Daten verändern möchte gibt es 2 Möglichkeiten:
1. Den Bootloader selber per ISP flashen. Dabei kann man diese Daten selber festlegen.
2. eine gepatchte selber kompilierte Firmware einspielen welche diese Daten fest Einkompiliert hat
Ich habe ja letztlich eine FHEM Installation mit einem HM-CFG-LAN welches eine eigene hmid hat.
Alle Sensoren benötigen am Ende diese hmid.
Wenn ich das jetzt richitg verstehe, wäre Deine Option1 ein serielles flashen?
Wo kann ich mich bzgl Option 2 schlau machen?
Ein letzter Versuch. Sowas geht also mit den Sensoren nicht:
set <Name HM-Gerät> pair
Pjg, du sitz da auf dem falsche Pferd.
Jedes HM Gerät hat seine eigene HM-ID, die muss in deinem kleinen FHEM Universum auch einzigartig sein und hat nichts mit der HM-ID des HMLAN zu tun.
Ich bin mir sehr sicher, dass das im Einsteiger.pdf erklärt ist.
Gruß
Ingo
Hallo Ingo,
ich empfehle den hier:
http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen (http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen)
Kleiner Auszug:
ZitatDurch das Pairing wird ein HM-Gerät genau einem IO-Device (zB CUL) zugeordnet. Wenn ein Gerät mit dem IO-Device gepairt ist, kann es darüber gesteuert werden.
Beim Pairing wird die HMID des IO-Device in das Gerät geschrieben.
Mein io device ist halt der HM-LAN.
Ich spreche nicht von der Seriennummer der Geräte.
Dein Zitat ist schon ok.
Wenn ein Device hier also z.B. ein Sensor mit dem HM-LAN gepairt wird, dann wie die HM-ID des HM-LAN als "Zentralen-ID" in den Sensor geschrieben.
Der Sensor sendet dann also Nachrichten an deinen HM-LAN und erwartet von diesem auch die Antworten.
Das ist aber ein "normaler" Vorgang der bei allen HM-Geräten gleich abläuft.
Ich glaube hier gab es vorhin einfach ein Missverständnis.
Der Sensor hat, wie alle anderen HM-Geräte auch, eine eindeutige HM-ID sowie auch eine Seriennummer. Diese Daten brauchen in der Regel nur einmalig beim Programmieren des Bootloaders eingegeben werden. Anschliessend ist der Sensor unter diesen "Adressdaten" im HM-System erreichbar.
Alles weitere wie z.B. das Peering erfolgt "normal" mit FHEM wie bei allen anderen HM-Geräten auch.
Gruß
Dirk
Ok, die HMID des IO Devices wird also als Zentralen ID in den Sensor geschrieben und ist somit ungleich der HMID des Sensors.
Was für ein Konstrukt.
Sorry, das habe ich falsch verstanden. Ist aber auch verwirrend. Zwei unterschiedliche HMIDs in einem Sensor.
Danke.
Nicht ganz richtig. Nicht die HMID des IO-Devices sondern der Zentrale. Eine Zentrale kann mehrere IODevs haben.
Wie bitte?
Ich habe gar keine Zentrale? Bei mir läuft fhem und da gibt es einen HM-LAN dran mit ner HMID.
Ihr schafft mich.
Zitat von: Pjg am 23 Oktober 2014, 06:53:16
Ok, die HMID des IO Devices wird also als Zentralen ID in den Sensor geschrieben und ist somit ungleich der HMID des Sensors.
Was für ein Konstrukt.
Sorry, das habe ich falsch verstanden. Ist aber auch verwirrend. Zwei unterschiedliche HMIDs in einem Sensor.
Danke.
Ist doch ganz einfach. Jeder hat sein unique ID und kennt auch eine ID der Zentralle, damit er auch weiß, mit wem er überhaupt sprechen darf (beim Peeren kommen sogar weitere IDs dazu) ;)
Als Vergleich: Du kennst Deinen Namen und Name deiner Frau/Freundin. Da kennst Du schon zwei Namen ;)
Ok. Verstanden. Nur wo ich meine zentralen ID eingeben soll, wenn das nun etwas anderes als die HMID des IODevices sein soll, und man ja keine Zentrale hat?
FHEM ist deine "Zentrale"
Und Zentralen-ID ist in der Regel die ID deines HM-LAN.
Man kann aber auch mehrere HM-LAN oder ein HM-LAN und ein CUL usw. an einer Zentrale "FHEM" betreiben.
Dann hat jedes dieser IO-Devices eine eigene HM-ID. Und auch dann kann ein HM-Devices also z.b. der Sensor mit der "Zentrale" gepairt sein. Dann muss man sich aber aussuchen mit welchem IO-Device dieses Pairing erfolg.
Ok. Doch richtig verstanden.
Danke.
Und jetzt Nerv ich auch nicht mehr rum.
Und Troll mich mit weiteren Fragen in den Anfängerbereich.
Hier geht's ja schließlich um die tollen Sensoren.
Ich freue mich schon drauf.
Hallo,
ich benötige Hilfe beim update. Ich habe mir die "tgz" Dateien heruntergeladen. Da bei dem Outdoorsensor ohnehin die Batterien platt waren, habe ich versucht, dem das update zu verpassen. Das ganze habe ich mit der Original HM Software und einem HM-CFG-USB2 gemacht. Mit den USB2 habe ich auch schon meine RT's upgedatet.
Alles nach Anweisung - Batterie raus, Knopf drücken, Batterie rein. Das Update beginnt, bricht aber bei ca. 80 % immer mit zu vielen Übertragungsfehlern ab.
Der Sensor sagt so auch nichts mehr - die LED binkt einmal lang, dann zweimal kurz - Pause und das ganze von vorne.
Geliefert wurde der Sensor mit OTA Bootloader und der FW 0.11
Was kann ich noch machen um das Teil wieder ans laufen zu bekommen ?
Gruß Christoph
Zitat von: Bennemannc am 28 Oktober 2014, 19:28:22
Das Update beginnt, bricht aber bei ca. 80 % immer mit zu vielen Übertragungsfehlern ab.
Steht auf deinem Seriennummernaufkleber eine Versionsnummer des Bootloaders?
Hallo Dirk,
nein, da steht nur eine Seriennummer drauf. Die ist UWS0511720 - kannst Du nachsehen, was Du damals draufgespielt hat.
Gruß Christoph
Zitat von: Bennemannc am 28 Oktober 2014, 21:55:54
nein, da steht nur eine Seriennummer drauf. Die ist UWS0511720 - kannst Du nachsehen, was Du damals draufgespielt hat.
Dann vermute ich dass du einer der Ersten mit dem OTAU-Bootloader warst.
Dieser hatte einen Bug wo das Update mit dem HM-USB-CFG und der Win-Software nicht bis zum Ende durchlief.
Ansonsten würde da "OTAU 0.6.1" stehen.
Hast du Zugriff auf einen Raspberry Pi oder einen Arduino? Dann bekommen wir den Bootloader auch remote geupdated.
Alternativ lässt sich das Update auch über die Linux-Software aufspielen.
Gruß
Dirk
Hallo Dirk,
eine RPI habe ich hier rumliegen. Da ist auch Fhem zum testen Drauf und ein HM-CFG-USB2 eingerichtet.
Kannst Du mir eine detaillierte Anleitung geben, was ich machen muss und woher ich die Software, Firmware, Bootloader bekomme ?
Gruß Christoph
Hallo Christoph
Zitat von: Bennemannc am 28 Oktober 2014, 22:26:18
eine RPI habe ich hier rumliegen.
Das klingt gut.
Da haben wir 2 Mögichkeiten.
1. Update mit dem Linux-Tool (der schnelle Weg ohne Verkabelung)flash-ota aus dem hmland-Paket: https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb
sudo ./flash-ota -f payload.eq3 -s <SERIAL_NUMBER>Die "payload.eq3" findest du im .tgz-File
Hier hat Franz eine kleine Anleitung geschrieben:
http://www.lxccu.com/hb-linux-ota-usb-update
Weitere Updates musst du dann aber auch per flash-ota einspielen.
2. Update das Bootloaders und anschließendes Flashen mit der Win-SoftwareDazu muss der Raspberry Pi mit dem Sensor verkabelt werden.
http://www.lxccu.com/hb-raspberry-bootloader-update
Die Seriennummer und die HM-ID bekomst du von FHEM. Die Schritte zum Auslesen mit der LXCCU kannst du dann ignorieren.
Anschließend kann das Update auch über die Win-Software erfolgen.
Was dann auch in Zukunft für weitere so funktioniert.
Gruß
Dirk
Hej Dirk,
heute ist mir aufgefallen, dass einer meiner Außensensoren (testweise noch mit v0.11 drauf) ausgefallen ist.
Hab mir daraufhin das Logfile angesehen und den Batterie-Verlauf fand ich äußerst interessant. ;-)
Hab mal das Logfile angehängt. ;-)
Gestern habe ich meine ccu2 mit der neuen Version 2.11.6 upgedatet. Dummerweise spricht mein Innensensor jetzt nicht mehr mit der ccu2.
Der Sensor wird nicht mehr angezeigt und ein erneutes Anlernen ist ebenfalls nicht möglich.
Was muss ich machen um den Sensor wieder zu erreichen?
THX
_cv
Zitat von: Mr. P am 29 Oktober 2014, 15:31:38
Hab mir daraufhin das Logfile angesehen und den Batterie-Verlauf fand ich äußerst interessant. ;-)
Das sieht so aus wie bei mir bisher.
Der MAX "lutscht" die Batterien ziemlich leer. Schau mal ob eine Batterie komplett entladen ist.
Zitat von: _cv am 30 Oktober 2014, 22:56:12
Gestern habe ich meine ccu2 mit der neuen Version 2.11.6 upgedatet. Dummerweise spricht mein Innensensor jetzt nicht mehr mit der ccu2.
Bei einem Firmwareupdate der CCU verschwinden auch die Files die die CCU für den Sensor benötigt. Daher muss das Addon nach einem Update wieder eingespielt werden.
Aber auch danach ist es möglich, dass dann der Sensor neu angelernt werden muss.
Daher sollte das Update so verlaufen:
- Backup der CCU machen
- Firmware-Update durchführen
- Sensor-Addon installieren
- Backup zurück spielen
Gruß
Dirk
Zitat von: Dirk am 31 Oktober 2014, 09:37:25
Der MAX "lutscht" die Batterien ziemlich leer. Schau mal ob eine Batterie komplett entladen ist.
Allerdings... :-)
Komme erst am Wochenende wieder zu dem Sensor, da werde ich ihm neue Batterien und auch das Update auf die aktuelle Version verpassen.
Hab die Tage die Werte zwischen den 0.11er, 0.12er & 0.13er Versionen verglichen und konnte gut sehen, dass
1) die 0.11er um einiges mehr an Strom zieht als die Folgeversionen (da hast du dann aber auch gut dran gedreht)
2) die 0.12er schon mal um einiges besser ist und
3) die 0.13er scheinbar noch um einen Tick besser zu sein scheint... zumindest fällt die Bandbreite der Spannungs-Schwankungen um eine Spur geringer aus. *thumbsUp*
Hallo Dirk,
danke für die Hilfestellung, leider kann ich das Addon für die ccu2 nicht mehr runterladen. Links aus dem Forum funktionieren leider nicht mehr.
Gibt es aktuelle Downloadlinks?
THX
_cv
Hier ist das Addon für die 0.12er Firmware:
https://github.com/kc-GitHub/Wettersensor/raw/v0.12/Tools/CCU/HB-UW-Sen-THPL_CCU-addon.tgz
Gruß
Dirk
Danke!
THX
_cv
Hallo!
Sorry, falls ich da in der Sucxhe etwas überlesen haben sollte.
Ich hätte Interesse an dem Außensensor, gibt es die Platine (unbestückt oder bestückt) irgendwo zu bestellen?
Oder das ganze als Bausatz?
Danke!
Viele Grüße...
Zitat von: rammelsberg am 03 November 2014, 09:00:36
Ich hätte Interesse an dem Außensensor, gibt es die Platine (unbestückt oder bestückt) irgendwo zu bestellen?
Oder das ganze als Bausatz?
Hab dir eine PM mit den weiteren Infos geschickt.
Gruß
Dirk
Zitat von: Dirk am 31 Oktober 2014, 09:37:25
Der MAX "lutscht" die Batterien ziemlich leer. Schau mal ob eine Batterie komplett entladen ist.
So... Am Wochenende wurde das Update gefahren und neue Batterien eingelegt. Die Batterien waren tatsächlich leer.
Ich Frage mich nur, warum das so plötzlich kam. Womöglich, weil sie mehreren Jahren ihren Dienst im freien verrichtet hatten und jetzt einfach end-of-life war?
Denn der Absturz innerhalb von 2 Tagen von 2,65 auf 0 muss wohl irgend einen Grund haben. Wird die Spannungsmessung eigentlich vor oder nach dem MAX durchgeführt?
Die Spannungsmessung findet vor dem MAX statt. Alles andere macht keinen Sinn, da der MAX die Spannung bis zum Ende auf 3,3 V hält.
Ich kann mir das aktuell nur so erklären: Wenn eine der Batterien zuerst den "Geist aufgibt", bei mir war jedes Mal eine Batterie komplett leer, dann kommt es zu dem Plötzlichen rapiden Spannungsabfall, da die Spannung einer Zelle auf einmal fehlt, und die zweite Zelle die leere quasi mit versorgt.
Der Strom der die Batterie liefern muss erhöht sich auch mit sinkender Spannung.
Ich habe das mal nachgemessen und in einem Diagramm aufgezeichnet.
Der gelb markierte Bereich ist der Bereich der bei Batterieversorgung relevant ist.
Der Stromverbrauch entspricht dem, dem der Sensor bei Aktivität benötigt.
In der nächsten Firmwareversion werde ich den Sendezyklus noch einstellbar machen.
Aktuell Sendet der Sensor ca. alle 2-3 Minuten. Ich werde die Sendezeit wohl in 1-10 Min. einstellbar machen. Default wird aber 2-3 Minuten bleiben. Vor allem wegen dem Pairing zum RT.
Zitat von: Dirk am 03 November 2014, 10:18:41
Die Spannungsmessung findet vor dem MAX statt. Alles andere macht keinen Sinn, da der MAX die Spannung bis zum Ende auf 3,3 V hält.
Leuchtet ein!
Zitat von: Dirk am 03 November 2014, 10:18:41
Ich kann mir das aktuell nur so erklären: Wenn eine der Batterien zuerst den "Geist aufgibt", bei mir war jedes Mal eine Batterie komplett leer, dann kommt es zu dem Plötzlichen rapiden Spannungsabfall, da die Spannung einer Zelle auf einmal fehlt, und die zweite Zelle die leere quasi mit versorgt.
So erklärt, dass man es einfach nicht nicht verstehen kann. :-)
Zitat von: Dirk am 03 November 2014, 10:18:41
Der Strom der die Batterie liefern muss erhöht sich auch mit sinkender Spannung.
Ich habe das mal nachgemessen und in einem Diagramm aufgezeichnet.
Der gelb markierte Bereich ist der Bereich der bei Batterieversorgung relevant ist.
Jo, macht natürlich Sinn!
Zitat von: Dirk am 03 November 2014, 10:18:41
In der nächsten Firmwareversion werde ich den Sendezyklus noch einstellbar machen.
Aktuell Sendet der Sensor ca. alle 2-3 Minuten. Ich werde die Sendezeit wohl in 1-10 Min. einstellbar machen. Default wird aber 2-3 Minuten bleiben. Vor allem wegen dem Pairing zum RT.
Wäre es möglich, bei einem vorhandenen Peering die Zeit fix auf die 2-3 Minuten zu setzen während ohne Peering diese eben von 1-10 Minuten frei wählbar ist? :-)
Auf alle Fälle vielen Dank für deine Ausführungen! :-)
Zitat von: Mr. P am 03 November 2014, 10:42:07
Wäre es möglich, bei einem vorhandenen Peering die Zeit fix auf die 2-3 Minuten zu setzen während ohne Peering diese eben von 1-10 Minuten frei wählbar ist? :-)
Ja, irgend so was hatte ich vor.
Zitat von: rammelsberg am 03 November 2014, 09:00:36
Hallo!
Ich hätte Interesse an dem Außensensor, gibt es die Platine (unbestückt oder bestückt) irgendwo zu bestellen?
Oder das ganze als Bausatz?
Danke!
Viele Grüße...
Hätte auch interesse, ist schwierig hier die passenden infos aus dem fred heraus zu filtern.
Vielleicht bkannst du mir auch eine Nachricht schicken.
Gruß Holgi
Zitat von: The-Holgi am 03 November 2014, 19:07:42
Hätte auch interesse, ist schwierig hier die passenden infos aus dem fred heraus zu filtern.
Da gebe ich dir recht.
Ich habe dir auch eine Nachricht geschickt.
Viele Grüße
Dirk
meine Frage zu der erwartenden Batterie Lebensdauer... weil bei mir im Wohnzimmer ist es echt "saukalt" und "saufeucht" ;) siehe Screenshot
Habe ja zwei Innensensoren von dir, beide zeigen im Batteriestatus "low" an der im Bad arbeitet, aber der im Wohnzimmer zeigt eine schreckliche Temperatur an. Frage hängt das mit dem Batteriestatus zusammen.?
Wenn ja, solange habe ich da ja nun noch nicht (irgendwie seit Sommer), aber dieser Zyklus ist natürlich bescheiden kurz...!
Beide Sensoren haben seiner Zeit neue Batterien bekommen...
D-Firmware beider Sensoren ist die 0.11
Brauchst du noch weitere Angaben..?
Hej moonsorrox,
gibt schon Berichte hier im Thread, dass die Sensoren teilweise irrwitzige Werte anzeigen, wenn es mit der Batterie zu Ende geht.
Solltest auf alle Fälle ein Update machen. Mit v0.12 hat Dirk einige Verbesserungen eingebaut, die sich auch sehr gut auf die Lebensdauer der Batterie auswirken.
Mit v0.13 gibt es jetzt auch noch die Möglichkeit, den Grenzwert für die Batterie-Warnung selbst zu definieren.
Beim Update nicht vergessen, auch das HMConfig-File mit auszutauschen und anschließend mal den Config-Button zu drücken. ;-)
da hätte ich dann jetzt mal die nächste Frage... weil er war ja gepairt und jetzt nachdem ich die Batterien gewechselt habe hatte er ein anderes Pairing drin..! weiß jetzt nicht welches Gerät das ist.
Meine Geräte sind normal alle gepairt
PairedTo: 0x1EA121
dieser Sensor hatte, schreib er da irgend etwas rein
PairedTo: 0xFFFFFF
Ich habe nochmals die Config Taste gedrückt jetzt ist das wieder richtig drin... :)
Ist das normal so..?
Mit dem Firmwarewechsel werde ich mich morgen mal beschäftigen, dazu muss ich ja den USB Adapter wieder in den PC stecken und das mit dem Windows Tool machen, muss mal nachschauen wie das ging (war ja nicht so schwer) nur brauche ich dazu die Firmware.
Soll ich dann die 0.12 oder die 0.13 nehmen..?
Zitat von: Mr. P am 05 November 2014, 14:33:28
gibt schon Berichte hier im Thread, dass die Sensoren teilweise irrwitzige Werte anzeigen, wenn es mit der Batterie zu Ende geht.
Das dürfte aber nur bei Sensoren passieren ei denen kein MAX bestückt ist.
Zitat von: moonsorrox am 05 November 2014, 18:06:25
dieser Sensor hatte, schreib er da irgend etwas rein
PairedTo: 0xFFFFFF
Das bedeuted dass der Sensor nicht gepaired ist 0xFFFFFF ist die Broadcastadresse.
ZitatIch habe nochmals die Config Taste gedrückt jetzt ist das wieder richtig drin... :)
Ist das normal so..?
Das Pairing geht normalerweise bei einem Batteriewechsel nicht verloren.
Kannst du ja noch mal testen. Batterie raus und dann wieder ein.
ZitatSoll ich dann die 0.12 oder die 0.13 nehmen..?
Die 0.13er ist noch beta. Und auch noch nicht komplett. Daher am besten die 0.12er nehmen.
Gruß
Dirk
OK, es war aber so, er zeigte die irrwitzige Temperatur an, Batterie war low und es stand 0xFFFFFF drin...
Habe dann die Batterien gewechselt und es stand immer noch 0xFFFFFF drin, neu gepairt jetzt alles wieder richtig ;)
Ich habe die Innensensoren mit allem also diese hier
2x 03. Funk-Innensensor, Batterie mit Temperatur / Feuchte, Helligkeit, MAX1724, Gehäuse weiß
Ich warte mal bis der im Badezimmer die Grätsche macht, is ja auf dem besten Weg dahin... mal schauen was mit dem pairing passiert
Das sollten wir auf alle Fälle weiter mal beobachten.
Das sollte bei Sensoren mit Max nicht passieren.
Wie lange hatte dein Innensensor jetzt durchgehalten?
Gruß
Dirk
Zitat von: Dirk am 05 November 2014, 18:52:54
Das sollten wir auf alle Fälle weiter mal beobachten.
OK werde berichten...!
Zitat von: Dirk am 05 November 2014, 18:52:54
Wie lange hatte dein Innensensor jetzt durchgehalten?
du hast mir am 25. August geschrieben das meine Sensoren fertig sind, am 27. August hast du meine Überweisung erhalten also sollten die Sensoren in diesem Dreh bei mir angekommen sein, ich weiß es leider nicht mehr Tag genau, sollte dir aber reichen...!
Also knapp 2 Monate. Für den Innensensor ist das ziemlich wenig.
Wenn die Batterien voll waren sollter der mit der 0.11er FW deutlich länger durchhalten.
Du kannst du das Datum vom Batteriewechsel ja mal mit Permanentmarker auf die Batterien schreiben.
Dann wissen wir beim nächsten mal bescheid.
Batterien waren Neu, heutige Batterie Spg 3.06V
Badezimmer kurz vor der Grätsche 1.88V
Hast du die Möglichkeit den Standby-Verbrauch vom Sensor zu messen? Multimeter im mA-Bereich?
Zitat von: Dirk am 05 November 2014, 19:08:08
Hast du die Möglichkeit den Standby-Verbrauch vom Sensor zu messen? Multimeter im mA-Bereich?
klar kann ich machen... nur jetzt nicht da ich gleich weg bin und wenn ich nachher wiederkomme mit ganz viel Bier und Sljivovic messe ich mit dem Multimeter Temperatur oder Promille ;) :D
Mache ich dann morgen, wenn du mir sagen kannst wie und wo...
Morgen oder Wochenende recht ja auch.
Einfach z.B. zwischen Batterie+ und dem + des Batteriehalters messen.
Dann prost nacher :)
Hallo Dirk,
bezüglich der Batterien habe ich ähnliche Erfahrungen gemacht. Der Outdoor Sensor hat einfach das senden eingestellt als die Batterien leer waren, der Innensensor hat utopische Werte angezeigt. Die Laufzeit war auch vom Versenden bis vor einer Woche. Den Draußen habe ich zuerst bekommen - der war auch als erster leer. Beide sollten eigentlich mir MAX sein ( kannst Du vielleicht noch nachsehen) und haben sich trotzdem unterschiedlich verhalten. Das kann natürlich auch an den unterschiedlichen Sensoren liegen. Innen nur Temp und Feuchtigkeit - Außen Licht, Temp und Feuchtigkeit (Breakoutboard) und Luftdruck.
Ich bin immer noch nicht dazu gekommen, den neuen Bootloader draufzuspielen. In sofern ist immer noch die Version 0.11 auf beiden Geräten.
BTW. Du hattest mir doch mal die Anleitung zum Flshen des Bootloaders geschickt, kannst Du die mal ins Wiki stellen, dann findet man die schneller.
Gruß Christoph
Hej folks,
also bei meinem Innensensor, von dem ich auch das Log gepostet hatte, war auch Ende September Schluss. Allerdings hat der bis zum letzten Funksignal die richtigen Werte geliefert.
Meine restlichen Innensensoren hab ich besser im Zugriff und entsprechend direkt beim Erscheinen von v0.12 aktualisiert. Diese liefern seither recht konstante Spannungswerte. :-)
Hallo Mr.P,
wie hast Du das mit den unterschiedliche Versionen des .pm Moduls in FHEM denn gelöst bei einem Mix aus 0.11 und 0.12 ? So wie ich das verstanden habe benötigt die 0.12 doch eine geänderte Config Datei.
Gruß Christoph
Zitat von: Bennemannc am 05 November 2014, 19:52:17
Der Outdoor Sensor hat einfach das senden eingestellt als die Batterien leer waren
Das hatte ich weiter vorne schon mal gepostet warum das vorkommen kann.
ZitatBeide sollten eigentlich mir MAX sein ( kannst Du vielleicht noch nachsehen)
Wenn die Spule drauf ist, dann ist der MAX auch mit bestückt.
ZitatBTW. Du hattest mir doch mal die Anleitung zum Flshen des Bootloaders geschickt, kannst Du die mal ins Wiki stellen, dann findet man die schneller.
Ich werde mal sehen dass ich die Tage da was zusammenschreibe.
Ansonsten steht hier dazu auch schon mal was:
http://www.lxccu.com/hb-raspberry-bootloader-update
Sensoren mit gemischten FW-Versionen sind aktuell tatsächlich ein Problem.
Dem werde ich mich auch noch mal annehmen.
Du kannst aber die 0.12er pm-Version mit einem 0.11er Sensor benutzen.
Der Luftdruck wird in diesem Fall vom 0.11er Sensor um den Faktor 10 zu niedrig angezeigt.
also ich jetzt mir einigen Sljivovic im Kopp frage nochmals... damit ich morgen auch Ergebnisse liefern kann wo finde ich die aktuelle Firmware...
@Dirk
wenn du etwas zusammen schreibst, Bitte auch das flashen der Firmware.. denn schnell ist dies vergessen und ich bin kein Profi sondern Anwender und ich habe es schnell vergessen wie man so etwas macht...
Hallo,
habe meinen Innensensor in Betrieb genommen.
Dazu gleich mal 2 Fragen:
1.) Die Werte (temp.) scheinen bei mir ca. 1°C zu hoch. Gibt es so etwas wie ein Kalibriemöglichkeit? Oder passt sich das noch an, da der Sensor erst eine Stunde läuft?
2.) Ich habe nicht ganz aufgeladene Akkus eingesetzt, da ich nicht warten konnte. Jetzt zeigt mir der Sensor 2,68V an. Ich habe einen mit Max und dachte der müsste dann immer 3,3V stabil bis zum Ende bringen?
Zusatzfrage zu meinem noch nicht instillierten Außensensor. Da waren zwei Folien dabei. Soll ich beide verwenden, oder nur einen? Oder evtl. mal erst ohne probieren?
Zitat von: Pjg am 06 November 2014, 13:47:27
Jetzt zeigt mir der Sensor 2,68V an. Ich habe einen mit Max und dachte der müsste dann immer 3,3V stabil bis zum Ende bringen?
Das ist die Spannung an der Batterie / Akku. Also vor dem Max gemessen.
Zitat1.) Die Werte (temp.) scheinen bei mir ca. 1°C zu hoch. Gibt es so etwas wie ein Kalibriemöglichkeit? Oder passt sich das noch an, da der Sensor erst eine Stunde läuft?
Womit misst du die Referenztemperatur?
ZitatDa waren zwei Folien dabei. Soll ich beide verwenden, oder nur einen? Oder evtl. mal erst ohne probieren?
Eine Folie sollte reichen. Selten im Hochsommer hatte der Sensor auch mit einer Folie noch übersteuert. Daher kann man auch 2 Folien verwenden.
Gruß
Dirk
Ich habe daneben einen andere Temperaturanzeige liegen (inkl. Feuchte) weiß natürlich nicht welcher Sensor da drin ist.
Dieser zeigt ca. 1° weniger an.
Darüber hinaus ist im gleichen Raum noch der Thermostat der Buderus Heizung, welcher ca. 1,3° weniger anzeigt.
Außerdem habe ich einen netatmo im Raum und noch einen Temperaturfühler für die Lüftungsanlage.
Die zeigen letztlich alle ander Werte an. Aber der Universalsensor ist mit 24° Raumtemp. der Spitzenreiter und min. 1° höher als alle anderen.
Das ist ja auch kein größeres Problem. Die Frage ist nur, ob man das über eine Kalibrierung, also z.B. ein Attribut welches man eingibt und um den wert wird dann die Temperatur korrigiert, lösen kann.
Ansonsten baue ich mir halt etwas in FHEM was mir einen korrigierten Wert zurück gibt.
Der zweite Teil der Frage wäre, ob es sich evtl. noch anpasst. Der Sensor startete auch mit 25,8°C und hangelte sich langsam runter.
Evtl. tut sich ja noch etwas oder ich versuche es einmal mit komplett aufgeladenen Batterien.
Und zu guter Letzt, ob andere auch Erfahrungen bzgl. der Temperaturwerte haben.
Feuchte scheint bei mir übrigens besser zu sein.
Hast du den Sensor mal direkt neben einen deiner Referenzen gelegt?
Laut Datenblatt hat der SHT10 eine Genauigkeit von +/- 0.5 °C bei 25 °C.
Ja nach dem wo sich die Sensoren befinden kann das schon hinkommen mit dem einen Grad.
Und je nach dem wie genau der Sensor der Referenz misst, kann sich der "Fehler" dann auch addieren.
shit, jetzt war ich zu langsam. Hier nochmal der angepasste teil:
ZitatDas ist ja auch kein größeres Problem. Die Frage ist nur, ob man das über eine Kalibrierung, also z.B. ein Attribut welches man eingibt und um den wert wird dann die Temperatur korrigiert, lösen kann.
Ansonsten baue ich mir halt etwas in FHEM was mir einen korrigierten Wert zurück gibt.
Der zweite Teil der Frage wäre, ob es sich evtl. noch anpasst. Der Sensor startete auch mit 25,8°C und hangelte sich langsam runter.
Evtl. tut sich ja noch etwas oder ich versuche es einmal mit komplett aufgeladenen Batterien.
Und zu guter Letzt, ob andere auch Erfahrungen bzgl. der Temperaturwerte haben.
Feuchte scheint bei mir übrigens besser zu sein.
Zitat von: Pjg am 06 November 2014, 14:27:47
Der zweite Teil der Frage wäre, ob es sich evtl. noch anpasst. Der Sensor startete auch mit 25,8°C und hangelte sich langsam runter.
Evtl. tut sich ja noch etwas oder ich versuche es einmal mit komplett aufgeladenen Batterien.
Bisschen was kann sich natürlich noch tun. Aber nach einer Stunde sollte er bei den Temperaturunterschieden schon ziemlich am Ziel sein.
Da dein Sensor mit einem MAX ausgestattet ist, wird es keinen Unterschied machen, ob die Batterien voll, voller oder am vollsten sind. Entweder er sendet oder aber eben nicht. ;-)
Dann ist ja schon mal gut das ich den Max habe.
Kann es auch an der Lage liegen? Also wie das Teil steht/liegt, wo die Lüftungsschlitze sind, wierum die Platin im Gehäuse liegt, auch insbesondere im Bezug zu den Lüftungsschlitzen?
Zu Testzwecken liegt das Gehäuse nun einfach flach neben dem anderen Fühler.
Ich glaube ich hole ihn mal aus dem Gehäuse, mal sehen ob es dann unterschiede gibt.
OK. Das Gehäuse ist entscheidend.
Ich habe den Deckel entfernt. Innerhalb von 12 Minuten ist die Differenz auf nunmehr lediglich 0,6° statt 1,0° gesunken.
Und fällt weiter.
So, leider tut sich nun doch nicht mehr. Es bleibt ohne Gehäusedeckel bei einer Diff. zum anderen Fühler von 0,6°C.
Also würde ich mal sagen, dass die Lüftungsschlitze auf jeden Fall vertikal anzuordnen sind, damit "wärmere" Luft nach oben entweichen kann.
Auch wenn der Staub dann bessere eindringen kann...
Die Restdifferenz kalibriere ich dann raus.
Zitat von: Pjg am 06 November 2014, 14:58:45
Auch wenn der Staub dann bessere eindringen kann...
Einfach beim Frühjahrsputz mit einplanen. ;-)
Zitat von: Pjg am 06 November 2014, 14:27:47
Das ist ja auch kein größeres Problem. Die Frage ist nur, ob man das über eine Kalibrierung, also z.B. ein Attribut welches man eingibt und um den wert wird dann die Temperatur korrigiert, lösen kann.
Das gibt es aktuell noch nicht. Das muss man also in FHEM aktuell selber machen.
Vielleicht baue ich das noch in die FW mit ein.
Zitat
OK. Das Gehäuse ist entscheidend.
Das ist klar. Mit Gehäuse, auch wenn das Zirkulationsschlitze hat, braucht es länger bis die Temperatur und die Feuchte sich da angeglichen haben.
ZitatAlso würde ich mal sagen, dass die Lüftungsschlitze auf jeden Fall vertikal anzuordnen sind, damit "wärmere" Luft nach oben entweichen kann.
Ja, das macht Sinn.
Zitat von: Pjg am 06 November 2014, 14:58:45
OK. Das Gehäuse ist entscheidend.
Bei mir stehen im WoZi ein HM_WDS10_TH_O Innensensor mit SHT10 im Gehäuse, ein 1wire DS1820 Temperatursensor und eine kleine TFA Wetterstation nebeneinander auf dem Regal. Alle drei zeigen gerade einträchtig 20,4°C an ...
Ich habe einen OC3-Funk-Kombisensor, den Außensensor und einen weiteren 433 MHz-Sensor. Alle 3 zeigen verschiedene Werte an. Die Differenz ist jedoch bei verschiedenenen Temperaturen verschieden groß. Welchem Sensor soll ich jetzt trauen ?
Antwort: Jedem oder keinen.
Eine Temperatur-Angabe in Zentel-Grad suggeriert ohnehin eine Genauigkeit, die gar nicht da ist.
ZitatBei mir stehen im WoZi ein HM_WDS10_TH_O Innensensor mit SHT10 im Gehäuse, ein 1wire DS1820 Temperatursensor und eine kleine TFA Wetterstation nebeneinander auf dem Regal. Alle drei zeigen gerade einträchtig 20,4°C an ...
Ohne Kalibrierung? Glückspilz!
ZitatEine Temperatur-Angabe in Zentel-Grad suggeriert ohnehin eine Genauigkeit, die gar nicht da ist.
Völlig klar, daher ja auch die Frage nach der Kalibrierung. So ein halbes Grad hoch oder runter hat ja der SHT10 sowieso schon als Genauigkeitsdifferenz lt. Datenblatt.
ZitatSo ein halbes Grad hoch oder runter hat ja der SHT10 sowieso schon als Genauigkeitsdifferenz lt. Datenblatt.
was bedeutet denn "sowieso schon". die deutlich grössere anzahl sind besser als +/- 0.5 grad.
mein innensensor (v0.13), aussen unterm dachüberstand montiert, zeigt bei ruhigem wetter in der regel den selben wert wie der aussenfühler meiner heizungsanlage an. dieser ist an der gleichen hausfront etwa 8m entfernt angebracht. da der heizungsfühler nicht so geschützt ist, gibt es bei bestimmten wetterlagen schon mal abweichungen von bisher maximal 0.5 grad.
es kann zb auch grössere differenzen geben, wenn ein vergleichsfühler an einer zimmerwand angebracht ist und der umweltsensor nicht. da sollte man die zu vergleichenden sensoren eventuell mal in einen schuhkarton legen.
gruss frank
Sowieso schon heißt: Works as designed.
Man muss mit 0,5 bei 25 Grad Leben. Bei 20 Grad sind es schon wieder mehr.
Wer genauere Werte will, muss andere Sensoren nehmen.
Das ist alles ganz normal und auch kein großes Problem.
Man kalibriert die Differenz halt raus.
Hallo zusammen,
nun bin ich auch in dem Kreis, der zwei von den hier beschriebenen Sensoren sein eigen nennen kann.
Dafür mal ein richtig dickes Lob an alle Beteiligten. Top arbeit.
Allerdings ergibt sich nun eine kleine Frage, die ich nicht richtig beantworten konnte.
Auch aufgrund der vielen Informationen hier im Fred nicht.
Ich habe diesen Aussensensor:
Funk-Außensensor, Batterie mit Temperatur / Luftdruck, Helligkeit, MAX1724, Gehäuse grau
Da hat Dirk mir den Sensor an sich, das Gehäuse plus zwei Folien zugeschickt.
Nun werde ich ehrlich gesagt nicht wirklich schlau draus, was das mit der Folie des Aussensensors auf sich hat.
Was muss da machen? Möglicherweise noch am Gehäuse bohren/feilen/schleifen?
Und bzgl. der Temperaturmessung bin ich auch unsicher.
Das Innengehäuse hat ja Lüftungsschlitze. Der Aussensensor nicht. Stimmt denn dann die gemessene Temperatur überghaupt?
Die dürften dann doch differieren oder?
Oder sollte ich die am Gehäuse nachfräsen o.ä.?
In dem Posting steht ja noch, dass am Aussensensor eine Temperaturmessung gar nicht möglich sei.
Hat sich aber dann doch irgendwie anders ergeben oder?
http://forum.fhem.de/index.php/topic,20620.msg149358.html#msg149358
Es wäre cool, wenn mir hier jemand helfen könnte.
Am besten vielleicht auch ein kleines Bildchen. Sagt ja manchmal mehr als 1000 Worte :)
Wenn ich das dann verstanden habe, könnte das ggf ins Wiki?
Hallo,
1) das Aussensensorgehäuse ist ja nicht hermetisch dicht. Insofern funktionieren natürlich Temperatur und Luftdruck, wenngleich die Sensoren ggf. etwas langsamer reagieren (können), als wenn sie außerhalb des Gehäuses wären. Der Ausgleich dauert halt.
2) Die Folien brauchst Du nur, wenn ein direktes Bescheinen mit Sonnenlicht zu erwarten ist. Steht im Wiki.
3) Wenn der Außensensor ein paar Werte geliefert hat, könntest Du mal ein Plot-Screenshot posten; insbesondere die L-Werte interessieren mich.
Zitat von: Dirk am 05 November 2014, 19:20:56
Morgen oder Wochenende recht ja auch.
Einfach z.B. zwischen Batterie+ und dem + des Batteriehalters messen.
Da ich zwei Sensoren habe, habe ich das mal verglichen. Zur Information mein Multimeter hat einmal den Messbereich 20mA und einmal 200mA. Den Badezimmer Sensor muss ich im 200 Bereich messen weil der am Anfang sehr hoch geht, sonst steht da ne 1 drin
Badezimmer:beim messen fängt der an mit ca. 42mA an geht dann hoch auf ca. 140 ungefähr und dann zurück auf Null... sollte also kaum etwas fließen wenn ich das richtig deute..! Oder sollte im Standby ein Wert zusehen sein..?
Badezimmer lasse ich bis er sich verabschiedet - ist aktuell bei einer Spg. von 1.85 - um zu sehen ob er die selben Spinnereien macht wie der im Wohnzimmer...
Wohnzimmer:der geht hoch bis ca. 28,5mA also viel weniger, zeigt aber dann bei Umschaltung des Messbereichs (auf 20mA) so um die 0.02 an und springt immer mal auf 0.10
Dieser war aber der, der sich vor zwei Tagen verabschiedet hat mit der unmöglichen Temperatur und hat jetzt neue Batterien.
Wohnzimmer zeigt aktuell eine Spg. von 3.06
Evtl. kannst du damit was anfangen...!
Ich habe jetzt auch meinen Außensensor in Betrieb genommen.
Zunächst einmal mit einer Folie.
Aktuell hier eher bedeckt und trübe. Dabei habe ich Werte zwischen 1000 und 1100. wie hoch geht denn du Skala? Drin hatte ich 100 und mit Folie so 60
Ich habe jetzt auch meinen Außensensor in Betrieb genommen.
Zunächst einmal mit einer Folie.
Aktuell hier eher bedeckt und trübe. Dabei habe ich Werte zwischen 1000 und 1100. wie hoch geht denn du Skala? Drin hatte ich 100 und mit Folie so 60
Hallo Dirk,
ich habe gerade versucht, nach der ANleitung im Thread (http://forum.fhem.de/index.php/topic,20620.msg208682.html#msg208682) mein Sensor (noch aus der Prototypen-Reihe, Board rev. 1.0, 03/2014) mit dem OTA Bootloader zu versehen.
Die Verbindung klappte zunächst, avrdude meldete Erfolg. Der Flashvorgang war jedoch nicht erfolgreich (verify error). Das Script hängte sich anschliessend auf (nach längerer Zeit habe ich es mit Ctrl-C abgebrochen). Abbruch und Neuversuch, aber Device meldet sich nicht mehr. Es blinkt auch nichts mehr auch mit Batterien tut sich erwartungsgemäß nichts. Zerflasht? :'( Aber aus welchem Grund? Kannst Du die Ursache sehen (und vor allem einen Weg, den Sensor wieder zu beleben?)
*ratlos*
SinBootloader_0-7-0_HB-UW-Sen-THPL.tmp
12:34 HB0Default AB:CD:EF
Start flashing device with HM-TYPE: F1:02, HM-ID: 6F:B7:5D and serial number: UW
S0000001
****************************************
* Set fusebits with bitClock 187,5 KHz *
****************************************
avrdude.exe: set SCK frequency to 187500 Hz
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.04s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: erasing chip
avrdude.exe: set SCK frequency to 187500 Hz
avrdude.exe: reading input file "0xE2"
avrdude.exe: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0xE2:
avrdude.exe: load data lfuse data from input file 0xE2:
avrdude.exe: input file 0xE2 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.01s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0xD0"
avrdude.exe: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.03s
avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0xD0:
avrdude.exe: load data hfuse data from input file 0xD0:
avrdude.exe: input file 0xD0 contains 1 bytes
avrdude.exe: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.01s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of hfuse verified
avrdude.exe: reading input file "0x06"
avrdude.exe: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude.exe: 1 bytes of efuse written
avrdude.exe: verifying efuse memory against 0x06:
avrdude.exe: load data efuse data from input file 0x06:
avrdude.exe: input file 0x06 contains 1 bytes
avrdude.exe: reading on-chip efuse data:
Reading | ################################################## | 100% 0.01s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of efuse verified
avrdude.exe: safemode: Fuses OK
avrdude.exe done. Thank you.
*************************************************************************
* Write bootloader, application and set lock bits with bitClock 1,5 MHz *
*************************************************************************
avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.04s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be perfo
rmed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: reading input file "WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-T
HPL.bin"
avrdude.exe: writing flash (32768 bytes):
Writing | ################################################## | 100% 6.96s
avrdude.exe: 32768 bytes of flash written
avrdude.exe: verifying flash memory against WetterSensor+AskSinBootloader_0-7-0_
HB-UW-Sen-THPL.bin:
avrdude.exe: load data flash data from input file WetterSensor+AskSinBootloader_
0-7-0_HB-UW-Sen-THPL.bin:
avrdude.exe: input file WetterSensor+AskSinBootloader_0-7-0_HB-UW-Sen-THPL.bin c
ontains 32768 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 6.34s
avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
0x0c != 0x00
avrdude.exe: verification error; content mismatch
avrdude.exe: safemode: lfuse changed! Was e2, and is now 0
Would you like this fuse to be changed back? [y/n] y
^CBatchvorgang abbrechen (J/N)? J
T:\_USB1_alt\WetterSensor\Asksin_OTA_Bootloader\Tools\Flash-Tool-Windows>bin\avr
dude -p m328p -c usbasp
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
Danke und Grüße,
Alexander
Zitat von: Ralli am 07 November 2014, 10:27:01
3) Wenn der Außensensor ein paar Werte geliefert hat, könntest Du mal ein Plot-Screenshot posten; insbesondere die L-Werte interessieren mich.
Hi Ralli,
heute hat der Aussensensor den ersten Tag vollständig an seinem Bestimmungsort verbracht.
Bislang hatte ich den an Stellen, wo dann urplötzlich doch prall die Sonne drauf scheint und die Werte verfälschte.
Nun hängt der unter einem Dachvorsprung, wo die Sonne hoffe ich nicht hinkommt.
Danke - hast Du eine Folie drauf?
Hier mal ein Plot von meinem (keine Folie, Helligkeit ist durch 10 dividiert, Luftdruck sind 950 abgezogen und dann mit 10 multipliziert):
Nein, eine Folie habe ich nicht drauf.
Und der Sensor hängt unter einem Dachvorsprung an der Wand. Da kommt direkt mal keine Sonneneinstrahlung hin.
Umgerechnet habe ich da auch nichts. Alles nativ die Werte vom Sensor.
Bei mir ist es ähnlich. Nordseite = keine direkte Sonneneinstrahlung ausser im Hochsommer früh morgens.
Unsere Werte unterscheiden sich aber recht stark.
Ich komme mit einer Folie bei direkter Sonne ohne Wolken auf 5100-5400
So, heute die 6000er Marke gerissen.
Weiß jemand ab wann der Sensor übersteuert? Als was der max. Wert ist?
Laut Wikipedia sind an einem hellen Sonnentag 100.000 Lux zu erwarten.
Ich habe eine Folie drauf. Diese soll 26% des Lichts durchlassen.
Das bedeutet doch, dass ich in dem Fall 26.000 als Wert angezeigt bekommen müsste, oder?
Da mein bisheriger Maximalwert 6400 bei wolkenlosem Himmel (aber halt jetzt im Hebst) war, frage ich mich ob
1. 26000 theoretisch mit einer Folie denkbar wäre und
2. 26000 praktisch überhaupt vom Sensor gemeldet werden können?
Hallo!
Hmm, irgendwie hab ich jetzt Probleme, die neue Software (0.13) zum Laufen zu kriegen...
Habe die neue Firmware auf den Arduino geflasht, die neue HMConfig_SenTHPL.pm ins Fhem Verzeichnis kopiert, und gepairt.
Pairen klappt, nur werden keine Werte von den Sensoren übertragen....
Hier mal ein List:
Internals:
CFGFN
CUL1_MSGCNT 15
CUL1_RAWMSG A0E0EA410ABCDEFF112340601000000::-83.5:CUL1
CUL1_RSSI -83.5
CUL1_TIME 2014-11-14 13:13:10
DEF ABCDEF
IODev CUL1
LASTInputDev CUL1
MSGCNT 15
NAME CUL_HM_HB_UW_Sen_THPL_O_ABCDEF
NR 124
STATE ???
TYPE CUL_HM
lastMsg No:0E - t:10 s:ABCDEF d:F11234 0601000000
protLastRcv 2014-11-14 13:13:10
protResnd 1 last_at:2014-11-14 13:13:06
protSnd 19 last_at:2014-11-14 13:13:10
protState CMDs_done
rssi_at_CUL1 avg:-80 min:-84.5 max:-76 lst:-83.5 cnt:15
Readings:
2014-11-14 13:13:01 Activity alive
2014-11-14 13:12:24 CommandAccepted yes
2014-11-14 13:13:01 D-firmware 0.12
2014-11-14 13:13:01 D-serialNr HB0Default
2014-11-14 13:13:02 PairedTo 0xF11234
2014-11-14 13:12:24 R-burstRx off
2014-11-14 13:12:24 R-pairCentral 0xF11234
2014-11-14 13:13:02 RegL_00: 01:00 02:01 0A:F1 0B:12 0C:34 00:00
2014-11-14 13:13:07 recentStateType info
Helper:
cSnd 01F11234ABCDEF010E
mId F102
peerIDsRaw ,00000000
rxType 132
Io:
newChn +ABCDEF,00,01,00
nextSend 1415967190.11201
prefIO
rxt 0
vccu
p:
ABCDEF
00
01
00
Mrssi:
mNo 0E
Io:
CUL1 -81.5
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO CUL1
flg A
ts 1415967190.01786
ack:
HASH(0x189ea90)
0E8002F11234ABCDEF00
Rssi:
At_cul1:
avg -80
cnt 15
lst -83.5
max -76
min -84.5
Shadowreg:
Attributes:
IODev CUL1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 0.12
model HB-UW-Sen-THPL-O
peerIDs 00000000,
room CUL_HM
serialNr HB0Default
subType THPLSensor
Hat jemand eine Idee, was ich falsch mache???
es könnte der sehr hohe RSSI Wert sein der nichts übermittelt, lege den Sensor mal näher an dein FHEM Gerät
@moonsorrox: Hilft leider auch nix....
Hab die Firmware mit Standard-HM-ID und Standard Serial geflasht. Vielleicht liegts daran?
Aber wie krieg ich die HM-ID und die Serial raus? Auf http://www.lxccu.com/hb-raspberry-bootloader-update wird zwar ein Shell-Befehl empfohlen, aber ich hab die Firmware mit WIndows geflasht...
@Dir: Ist in dem fertigen HEX, bzw. eq3-File auch schon die serielle Ausgabe aktiviert???
EDIT:
Hab jetzt nochmal die 0.10 Firmware draufgespielt - da werden die Sensordaten problemlos übertragen.. (habe auch die 0.10er HMConfig_SenTHPL.pm kopiert...) Nur bei 0.12 krieg' ich keine Daten. Muss ich da noch was konfigurieren?? Wie kann ich da die Volt-Parameter angeben??
Hi zusammen,
Habe hier grade etwas Stress. Daher die späte Antwort.
Zitat von: Pjg am 07 November 2014, 15:04:20
Dabei habe ich Werte zwischen 1000 und 1100. wie hoch geht denn du Skala? Drin hatte ich 100 und mit Folie so 60
Der Helligkeitssensor liefert ohne Abdeckung die Helligkeit in Lux. Das geht bis ~40.000 Lux. Wenn es heller wird, dann übersteuert der Sensor.
Dafür ist die Folie . Die nur ca. 26% vom Licht durchlässt.
ZitatDas bedeutet doch, dass ich in dem Fall 26.000 als Wert angezeigt bekommen müsste, oder?
So in etwa.
Anbei mal ein Plot von einem Sommertag meines Sensors.
Der schraffierte Bereich ist der Wert vom Sensor mit Folie, der grüne Bereich nach der Umrechnung.
Zitat von: thunder1902 am 14 November 2014, 13:26:22
Hmm, irgendwie hab ich jetzt Probleme, die neue Software (0.13) zum Laufen zu kriegen...
Die 0.13er hat noch ein paar Bugs. Daher am besten die 0.12er verwenden.
Allerdings fällt mir auch grade nicht ein warum der bei dir nicht sendet.
Hast du die LED eingeschaltet? Dann sollte die alle 2-3 Min. kurz blinken.
Zitat von: thunder1902 am 14 November 2014, 14:10:21
Hab die Firmware mit Standard-HM-ID und Standard Serial geflasht. Vielleicht liegts daran?
Wenn das Pairen klappt dann sollte die FW auch laufen.
Und dann sollte auch deine HM-ID und Seriennummer stimmen.
ZitatAber wie krieg ich die HM-ID und die Serial raus?
Vom Sensor?
Lass mal den Eventmonitor laufen und drücken die Config-Taste. Dann sollte der Sensor sich mit seiner Seriennummer und HM-ID melden.
ZitatNur bei 0.12 krieg' ich keine Daten. Muss ich da noch was konfigurieren?? Wie kann ich da die Volt-Parameter angeben??
Welches File hast du denn geflasht?
Gruß
Dirk
Hallo Dirk,
Könntest Du den Plot noch mal kurz erklären?
Der schraffierte Bereuch vom Sensor kommt mit Max 40k
Da rechnest Du um in 100k? Der Sensir liefert also keine Lux, sondern
Die rechnest Du dann erst aus?
Nach welcher Formel?
Und wenn der schraffierte Wert mit Folie bis 40k geht,
dann passt das ja nicht mit meiner Rechnung und den 26% zusammen, oder?
100k lux->26%->26000 max. Sensorwert
Deinen Plot könnte man ja so interpretieren:
100k lux errechnet, aufgrund Sensoreert 40k, was aber keine 26% sind.
Stehe auf'm Schlauch, sorry
Zitat von: Dirk am 14 November 2014, 22:35:34
Die 0.13er hat noch ein paar Bugs. Daher am besten die 0.12er verwenden.
Allerdings fällt mir auch grade nicht ein warum der bei dir nicht sendet.
Hast du die LED eingeschaltet? Dann sollte die alle 2-3 Min. kurz blinken.
Wenn das Pairen klappt dann sollte die FW auch laufen.
Und dann sollte auch deine HM-ID und Seriennummer stimmen.
Vom Sensor?
Lass mal den Eventmonitor laufen und drücken die Config-Taste. Dann sollte der Sensor sich mit seiner Seriennummer und HM-ID melden.
Welches File hast du denn geflasht?
Gruß
Dirk
Hallo Dirk,
ich habe von https://github.com/kc-GitHub/Wettersensor/tree/v0.12/Tools/Firmware
das File
HB-UW-Sen-THPL-O_update_V0_12_001_140922.hex
aufgespielt.
Seriell gibt die 0.12-FIrmware nichts aus wenn ich den Config-Button drücke....
Zitat von: thunder1902 am 14 November 2014, 13:26:22
Hmm, irgendwie hab ich jetzt Probleme, die neue Software (0.13) zum Laufen zu kriegen...
2014-11-14 13:13:01 D-firmware 0.12
die versionen passen ja nicht. entweder hast du dich verschrieben, die falsche version geflasht oder das flashen hat nicht funktioniert.
@Dir: Ich hab's jetzt nochmal probiert: das 0.12 Hexfile sendet definitiv keine Daten über die serielle Schnittstelle, wenn man den Config-Knopf drückt. Die 0.10er schon....
Zitat von: Pjg am 15 November 2014, 08:02:31
Könntest Du den Plot noch mal kurz erklären?
Ich habe grade nochmal mein gplot-file angesehen.
Da rechne ich aktuell mit $value / 0.40 daher sieht passt der plot nicht mit faktor 0,26 zusammen.
Da muss ich noch mal nachsehen warum ich das gemacht hatte.
Um das selber zu "kalibrieren":
- Nimm den Sensor ohne Folie / Abdeckung. Dann bekommst du de Helligkeitswert in Lux.
- Dann den Sensor mit Folie und Abdeckung versehen und dann den Helligkeitswert lesen.
- Daraus kannst du dann einen eigenen Faktor brechnen.
Das ganze sollte an einem Wolkenlosen Tag passieren. Am besten am Vormittag oder Nachmittag, so dass der Sensor bei der Messung ohne Folie nicht übersteuert.
Das kannst du zuerst auch im Innenraum abends unter einer Lampe testen.
Zitatdann passt das ja nicht mit meiner Rechnung und den 26% zusammen, oder?
Da hast du recht. Mein Plot stimmt hier nicht, da da 0,4 als Faktor steht.
Zitat von: thunder1902 am 15 November 2014, 20:07:06
@Dir: Ich hab's jetzt nochmal probiert: das 0.12 Hexfile sendet definitiv keine Daten über die serielle Schnittstelle, wenn man den Config-Knopf drückt. Die 0.10er schon....
Ah, du meinst die serielle Ausgabe.
Bei der 0.12er Firmware habe ich keine Debuginfo's drin gelassen. Hier bekommst du glaube nur eine Ausgabe wenn der Sensor startet.
Über den CC1101 solltest du aber pakete bekommen ?
Gruß
Dirk
Hallo Dirk,
ich habe heute versucht mich mit dem Bootloader Update für den Testsensor den ich hatte zu beschäftigen. Irgendwie stehe ich auf dem Schlauch oder finde nicht das Richtige.
Ist es auch Möglich mit dem USB BUBII den Bootloader zu aktualisieren?
Am einfachsten für mich unter Windows.
Oder bliebe mir nur der weg via Raspberry?
Nico
Hallo Dirk nochmal,
die 0.12 mit der Hex HB-UW-Sen-THPL-O_update_V0_12_001_140922.hex funktioniert bei mir leider nicht.
In den Readings werden die Sensor-Werte nicht übertragen. Sensoren habe ich alle bis auf den SHT10.
Activity
alive
2014-11-15 22:20:48
CommandAccepted
yes
2014-11-15 22:20:44
D-firmware
0.12
2014-11-15 22:20:43
D-serialNr
HB0Default
2014-11-15 22:20:43
PairedTo
0xF11234
2014-11-15 22:20:44
R-burstRx
off
2014-11-15 22:20:44
R-pairCentral
0xF11234
2014-11-15 22:20:44
RegL_00:
01:00 02:01 0A:F1 0B:12 0C:34 00:00
2014-11-15 22:20:44
So, ich habs jetzt geschafft, den Sourcecode (0.12) mit der Arduino-IDE zu kompilieren. Dazu muss man in der Wettersensor.ino folgende includes zusätzlich hinzufügen:
#include <Wire.h>
#include <Sensirion.h>
#include <BMP085.h>
#include <TSL2561.h>
Leider ist der Quellcode mit seriellem Debug zu groß für den Arduino Mini Pro mit dem normalen seriellen Bootloader.
Aber nun funktioniert der Sensor. Anscheinend ist das HEX im Git fehlerhaft!?!?
Wie oft wird eigentlich Activtiy gesetzt?
Ich dachte man könnte das mit actCycle beinflussen. Aber da tut sich nichts.
Mein Außensensor sendet oft mehrere Tage, ohne das activity aktualisiert wurde.
Das störte mich auch nicht weiter, nur kommt es ab und an vor, so wie auch heute leider über mehrere Stunden, das der Sensor auf dead geht. Dann kommen auch keine Daten mehr.
Wie bekomme ich ihn wieder zum laufen, sprich auf activity alive?
Durch warten klappt es, es dauert aber u.U. etwas zu lange. :-)
Der RSSI scheint da nicht allzu relevant zu sein. Der ist beim Außensensor eigentlich permanent auf -100 seit ich ihn draußen habe.
Betrifft auch den Innensensor, nur war der noch nie dead.
Aktuell hier Activity alive seit 13.11.
Firmware ist die 12er.
Ich würde sagen, dein Problem ist gerade der schlechte Empfang. RSSI kleiner als -80 ist schon kritisch und bei -100 wundere ich mich überhaupt nicht, dass du keinen stabilen Empfang hast. Und weil die Daten unterbleiben, wird der Sensor als "dead" vermerkt. ArtCycle gibt dabei die Grenz-Zeit an.
Was bedeutet Grenzzeit?
Steht bei mir auf 000:10 und der Sensor ist trotzdem tagelang alive?
Ach ja, er sendet ja auch tagelang. Deshalb. Danke
Aber wann sendet der Sensor ein alive oder wird als solches gekennzeihcnet.
Die Grenzzeit schien hier nicht relevant zu sein:
2014-11-18_09:55:46 AUSSEN1 Activity: dead <------------
2014-11-18_10:33:23 AUSSEN1 temperature: 0.0
2014-11-18_10:33:23 AUSSEN1 battery: ok
2014-11-18_10:33:23 AUSSEN1 batVoltage: 2.53
2014-11-18_10:33:23 AUSSEN1 luminosity: 1377
2014-11-18_10:33:23 AUSSEN1 T: 0.0 L: 1377
2014-11-18_10:35:46 AUSSEN1 Activity: alive <------------
2014-11-18_10:45:46 AUSSEN1 Activity: dead <------------
2014-11-18_10:47:03 AUSSEN1 temperature: 0.0
2014-11-18_10:47:03 AUSSEN1 battery: ok
2014-11-18_10:47:03 AUSSEN1 batVoltage: 2.52
2014-11-18_10:47:03 AUSSEN1 luminosity: 907
2014-11-18_10:47:03 AUSSEN1 T: 0.0 L: 907
2014-11-18_10:54:54 AUSSEN1 temperature: 0.0
2014-11-18_10:54:54 AUSSEN1 battery: ok
2014-11-18_10:54:54 AUSSEN1 batVoltage: 2.52
2014-11-18_10:54:54 AUSSEN1 luminosity: 984
2014-11-18_10:54:54 AUSSEN1 T: 0.0 L: 984
2014-11-18_10:55:46 AUSSEN1 Activity: alive <--------
Laut Commandref wird ein Device als 'alive' gesetzt, wenn diese _irgendwas_ sendet. Ein spezielles 'alive'-Zeichen gibte es mWn nicht.
Als Grenzzeit habe ich (evtl. etwas unglücklich) die maximale Inantivitätszeit bezeichnet. Wenn diese Zeit lang keine Meldung von dem Sensor erkannt wird, wird dieser 'dead'.
Ich weiß nicht genau, wie das implementiert ist. Ich vermute jedoch, das kann damit zu tun haben, dass der ActionDetector in diesen (actCycle) Abständen reinschaut. Daher bei Meldung um 10:33 wird um 10:35 alive gesetzt. 10 Min später dead (war ja dazwischen nichts). Dann 10:55 wieder alive. Scheint zu passen.
Ich denke jedoch nicht, dass Du Dein Gerät mit diesem RSSI wirklich sinnvoll betreiben kannst. Anderer Standort, evtl. etwas andere Ausrichtung, ein Repeater oder ein zweiter Transmitter... Irgendeine Lösung muss her.
Ein ähnliches Problem hatte ich auch mal. Habe zuerst mit einem Repeater versucht, habe aber keinen guten Platz dafür gefunden. Am Ende betreibe ich jetzt einen HMLAN im 1.OG und einen HMUSB im Erdgeschoss. Jetzt ist Ruhe ;)
Grüße,
Alexander
ZitatDer RSSI scheint da nicht allzu relevant zu sein. Der ist beim Außensensor eigentlich permanent auf -100 seit ich ihn draußen habe.
ermitteln kann man natürlich nur beim empfangen von messages. daher sind die werte beim nicht empfangen noch schlechter. wenn du nur -100 hast, sind das deine top werte. also äusserst schlecht.
Zitatermitteln kann man natürlich nur beim empfangen von messages
Ich habe mir jetzt einmal einen plot gebaut mit dem ich verfolgen kann wie sich die RSSI Werte ändern.
Eines ist schon einmal klar: Der RSSI Wert wird wie oben gesagt immer beim senden gesetzt.
Er ändert sich danach nicht - bis zum nächsten senden.
Also empfange ich bei einem RSSI von -100 Werte. Mein letzter war sogar -101 - wer bietet mehr 8)
Ich denke es hat mit dem momentan schlechten Wetter zu tun.
Meint ihr die Folie schirmt auch ab? Ich habe eine Schicht drauf.
Am WE ist mir auch aufgefallen das Wasser auf dem Gehäuse stand - vom Regen.
Je länger ich drüber nachdenke wird es wohl so sein, das es erst seit dem es hier trübe Novmebertage mit Nebel und Regen gab, der Sensor nicht mehr duch kommt. Und sobald der Regen auf dem Gehäuse getroiknet war, konnte ich wieder Werte empfangen.
Kann das eine Erklärung sein?
Ich werde am WE den Sensor einmal schräg stellen, so dass Wasser ablaufen kann.
Die Entfernung verkürzen kann ich schlecht. Es sind auch nur ca. 20m durch zwei Wände. Eigentlich sollte der HMLAN noch in den Keller wandern. Dann würde es ja noch schlechter...
mein hmlan hat im vergleich zum cul wirklich bescheidene emfangsleistungen. angeblich liegt es an der internen antenne und es soll sich verbessern lassen wenn man diese besser legt oder sogar gerade aus dem hmlan gehäuse heraus schauen lässt.
gruss
andre
Zitatwenn man diese besser legt oder sogar gerade aus dem hmlan gehäuse heraus schauen lässt.
Gute Idee. Das probiere ich am WE einmal aus.
Danke.
Und die Antenne im Außensensor? Ich habe die unter der Folie, da ich die Folie an den Deckel geklebt habe.
Schirmt die auch, so dass ich besser die Antenne über die Folie legen sollte?
Ich teste das alles mal am WE wenn ich dazu komme und werde berichten.
Weitere Vorschläge zur Verbesserung des RSSI-Wertes sind herzlich willkommen.
Zitat von: Pjg am 18 November 2014, 15:24:39
Schirmt die auch, so dass ich besser die Antenne über die Folie legen sollte?
Ich hatte das mal getestet und keine Verschlechterung bemerkt.
ZitatWeitere Vorschläge zur Verbesserung des RSSI-Wertes sind herzlich willkommen.
Versuch mal die Folie wie in diesem Bild zu "verlegen"
http://www.fhemwiki.de/wiki/Datei:CC1101-Sensor-Au%C3%9Fen_mit_Filterfolie.JPG
Hier kann auch die Antenne über der Folie verlegt werden.
ja, werde ich machen.
Eine Frage noch zur Ausrichtung der Antenne.
oben
links ----------------------------- rechts
unten
Wenn der Strich die Antenne ist, sollte man diese dann so ausrichten das sie mit oben/unten oder mit links/rechts in zum Empfänger zeigt?
Da die Antenne doch recht kurz ist (1/8 Lambda?) schätze ich mal das es besser ist die Spitze (links/rechts) in Richtung Empfänger zeigen zu lassen. Richtig?
Am besten währ es die Antennen von Sender und Empfänger nach oben bzw. unten zeigen zu lassen, da sich die Funkwellen bei den verwendeten Antennen theoretisch auf einer Ebene rund um die Längsachse der Antenne ausbreiten. Auf Grund der verschiedenen Gehäuseformen bei den HB-Geräten lässt sich das aber nicht immer realisieren. Daher sind die Antennen in den Gehäusen oft so verlegt wie es im Gehäuse am besten passt.
Wie gesagt das gilt für Sender und Empfänger.
Daher dürfte der Vorschlag von Andre, die Antenne vom HM-LAN gerade nach außen zu legen, schon für eine Verbesserung sorgen.
Gruß
Dirk
Das müsste eine Lambda/4 Antenne sein.
Soweit ich weiß, den besten Empfang hast du, wenn die Antennen von Sender und Empfänger parallel zueinander ausgerichtet werden.
Hm, 8,6cm? So lang kam die mir garnicht vor. Ich werde wohl mal nachmessen.
ZitatDer oft angegeben Antennengewinn bei längeren Antennen von "plus x db" wird von einer 1/4 Lambda (auch: "L/4") Antenne aus gerechnet und steigt mit jeder Längenstufe um ein paar Dezibel an. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnliche also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn"). Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Wenn man eine Lambda Antenne (36 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht Empfangen wird. Daher: Je länger die Antenne ist (in vielfachen von 1/4 Lambda!), desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen.
Das ist aus dem WIKI zur CUL.
Ich interpretiere das so, dass es bei einer kurzen Antenne wohl eher egal ist wie sie ausgercihtet ist, da die Abstrahlung dann mehr oder weniger kugelförmig ist. Erst mit längeren Antenne wäre es demnach wichtig diese parallel auszurichten.
Ich werde es wohl einfach testen.
Im Moment passieren wieder ganz spannende Sachen bezüglich der Spannungsanzeige in meinem Sensor...
Bis vorgestern war die Batteriespannung wochenlang permanent +/- 2,70V.
Gestern schwankte sie dann zwischen 2.68V und 2.66V
Aktuell liegt sie bei 2.0xV - und ich habe logischerweise eine Batteriewarnung.
Drinne- oder draußen? Wenn Außen, dann könnte es daran liegen, dass es kälter wurde, Batterien verlieren dann an Kapazität.
Drinnen, im Flur. Selten unter 20°C
Hm... Hätte ja sein können. So was in der Art habe ich bei meinem Außensensor beobachtet (allerdings mit Akku drin).
Aktuell 1,62V und eine absolute Phantasietemperatur in der Anzeige.
Zitat von: betateilchen am 19 November 2014, 12:18:30
Im Moment passieren wieder ganz spannende Sachen bezüglich der Spannungsanzeige in meinem Sensor...
Hast du schon v0.12 auf dem Sensor?
Zitat
Aktuell 1,62V und eine absolute Phantasietemperatur in der Anzeige.
Hat der Sensor einen Max?
zweimal JA
2014-11-19 19:43:16 Activity alive
2014-09-27 21:03:17 CommandAccepted yes
2014-09-27 21:03:16 D-firmware 0.12
2014-09-27 21:03:16 D-serialNr UWS2370787
2014-09-27 21:03:18 PairedTo 0x127000
2014-09-27 21:03:18 R-burstRx undef lit:255
2014-09-27 21:03:18 R-pairCentral 0x127000
2014-09-27 21:03:18 RegL_00: 01:FF 02:01 0A:12 0B:70 0C:00 00:00
2014-11-19 19:42:28 batVoltage 1.08
2014-11-19 19:42:28 battery low
2014-11-19 19:42:28 pressure 1018.0
2014-11-19 19:42:28 pressure-nn 1026.2
2014-11-19 19:42:28 state T: 24.7 P: 1018.0 P-NN: 1026.2
2014-11-19 19:42:28 temperature 24.7
Ich habe nun auch eine komische Anzeige des bmp085. Luftdruck soll 96 hPa betragen... Meine Batterie hängt an einem China-Step-Up-Wandler und wird von einer umgebauten Garten-Solarleuchte "aufgeladen". Hat immerhin noch 1,15 Volt. (China-Step-Up soll bis 0,9 Volt stabile 5V liefern, die ich mit 2 Dioden hintereinander wieder reduzieren musste). Alle anderen Werte passen aber..
@Dirk: ich hab grad den Beitrag von Dir gelesen:
http://forum.fhem.de/index.php/topic,20620.msg215560/topicseen.html#msg215560
ZitatSensoren mit gemischten FW-Versionen sind aktuell tatsächlich ein Problem.
Dem werde ich mich auch noch mal annehmen.
Du kannst aber die 0.12er pm-Version mit einem 0.11er Sensor benutzen.
Der Luftdruck wird in diesem Fall vom 0.11er Sensor um den Faktor 10 zu niedrig angezeigt.
Was ist eine pm-Version? Ich habe auf meinem Arduino Mini Pro die 0.12er aufgespielt. Liegt es vielleicht daran, dass der Luftdruck bei mir nicht stimmt??
Mein Sensor hat seit 20:23 Uhr den Betrieb bei einer Spannung von 0.69V eingestellt.
2014-11-19 22:22:33 Activity unknown
2014-09-27 21:03:17 CommandAccepted yes
2014-09-27 21:03:16 D-firmware 0.12
2014-09-27 21:03:16 D-serialNr UWS2370787
2014-09-27 21:03:18 PairedTo 0x127000
2014-09-27 21:03:18 R-burstRx undef lit:255
2014-09-27 21:03:18 R-pairCentral 0x127000
2014-09-27 21:03:18 RegL_00: 01:FF 02:01 0A:12 0B:70 0C:00 00:00
2014-11-19 20:23:15 batVoltage 0.69
2014-11-19 20:23:15 battery low
2014-11-19 20:23:15 pressure 1018.4
2014-11-19 20:23:15 pressure-nn 1026.6
2014-11-19 20:23:15 state T: 23.3 P: 1018.4 P-NN: 1026.6
2014-11-19 20:23:15 temperature 23.3
Die neuen Batterien wurden am 12.09. eingesetzt, damals noch mit Firmware 0.10 und am 27.09. wurde das Update auf 0.12 gemacht. Im Endeffekt bedeutet das aber, dass die Batterien immer noch "nur" eine Lebensdauer von ca. zwei Monaten haben.
Ich bin auch an einigen Modulen interessiert. Gibt es noch welche?
Zitat von: betateilchen am 19 November 2014, 19:22:08
zweimal JA
Da kann ich mir im Moment noch keinen Reim drauf machen.
Mein Außensensor mit 0.12er FW-Version läuft noch. aber noch keine 2 Monate. Dannach werde ich auch erst praktische Erfahrung mit der gehofften Verbesserung der Batterielaufzeit haben.
Warum bei dir aber Fantasietemperaturen angezeigt werden kann ich nicht nachvollziehen.
Deine geposteten Werte sehen aber ganz gut aus.
Zitat von: thunder1902 am 19 November 2014, 22:26:03
Ich habe nun auch eine komische Anzeige des bmp085. Luftdruck soll 96 hPa betragen...
Was ist eine pm-Version? Ich habe auf meinem Arduino Mini Pro die 0.12er aufgespielt. Liegt es vielleicht daran, dass der Luftdruck bei mir nicht stimmt??
In der 0.12er Firmware hatte ich die Übertragung des Luftdrucks geändert. Daher muss hier auch die Datei HMConfig_SenTHPL.pm getauscht werden.
Sonst stimmt die Luftdruckanzeige nicht.
Für FW 0.12 ist die Datei hier:
https://github.com/kc-GitHub/Wettersensor/raw/v0.12/Tools/FHEM/HMConfig_SenTHPL.pm
Zitat von: kmatthias am 20 November 2014, 13:11:41
Ich bin auch an einigen Modulen interessiert. Gibt es noch welche?
Ja. Hab dir die Infos gesendet.
Gruß
Dirk
Zitat von: Dirk am 20 November 2014, 15:22:04
Warum bei dir aber Fantasietemperaturen angezeigt werden kann ich nicht nachvollziehen.
Deine geposteten Werte sehen aber ganz gut aus.
Die Werte mögen gut aussehen, sie waren aber plötzlich viel zu hoch. Wobei die Temperatur ja im Gehäuse gemessen wird, vielleicht hat der Spannungsregler verzweifelt versucht, die Sollspannung aus der immer niedriger werden Batteriespannung zu erreichen und ist dabei ins Schwitzen gekommen? Wäre für mich eine logische Erklärung.
Zitat von: betateilchen am 20 November 2014, 15:27:44
vielleicht hat der Spannungsregler verzweifelt versucht, die Sollspannung aus der immer niedriger werden Batteriespannung zu erreichen und ist dabei ins Schwitzen gekommen? Wäre für mich eine logische Erklärung.
Das ist eine interessante Idee.
Das währ mir zwar noch nicht aufgefallen, ich werde das aber mal prüfen.
Um wieviel war die Temperatur denn zu hoch?
Ca. zwei Grad.
<klugscheiss>2 Kelvin</klugscheiss> 8)
Hallo,
bei mir verabschieden sich die Sensoren mit Akku auch aktuell der Reihe nach.
Nun kommen überall Batterien rein. Mal sehen ob ich da mehr als ca 6 Wochen hinbekomme.
Unzuverlässige Werte erhalte ich aber erst ab ca 1V dann aber richtig abgedreht (102°C in der Wohnung usw.)
Wäre es nicht möglich ab 1V die Werteübermittlung einzustellen und nur noch Batteriewarnings zu senden?
Ach alle Sensoren mit MAX und 2 mit V12 der Testsensor mit V10 (jetzt V12 aber noch seriell Bootloader, da ich wie schon geschrieben den nicht geflasht bekomme mit meinem USB-BUB II)
Nico
Hallo Dirk,
ich habe nun Deine empfohlene HMConfig_SenTHPL.pm eingespielt. Leider hat das nicht viel gebracht. Seit dem ich den Helligkeitssensor dran habe, wird der Luftdruck durch 10 geteilt.... komisch....
Zitat von: santalaus am 20 November 2014, 19:10:20
Wäre es nicht möglich ab 1V die Werteübermittlung einzustellen und nur noch Batteriewarnings zu senden?
Das hatte ich für die nächste FW-Version vor.
ZitatAch alle Sensoren mit MAX und 2 mit V12 der Testsensor mit V10 (jetzt V12 aber noch seriell Bootloader, da ich wie schon geschrieben den nicht geflasht bekomme mit meinem USB-BUB II)
Hast du mal versucht mit einem Raspberry Pi zu flashen (vorausgesetzt du hast einen)?
Zitat von: thunder1902 am 20 November 2014, 19:50:54
ich habe nun Deine empfohlene HMConfig_SenTHPL.pm eingespielt. Leider hat das nicht viel gebracht. Seit dem ich den Helligkeitssensor dran habe, wird der Luftdruck durch 10 geteilt.... komisch....
Das ist korrekt. Dann hast du aber nicht auf allen Sensoren die V0.12 drauf.
@Dirk: Ich hab nur einen Sensor :-)
Irgendwas stimmt da nicht - auch die Kommastelle "bewegt" sich fast nicht. Werd den Helligkeitssensor nochmal entlöten und dann mal testen..... Die Temperatur wird dagegen korrekt dargestellt (kommt vom BMP, da kein SHT vorhanden).
Zitat von: thunder1902 am 20 November 2014, 20:05:44
Irgendwas stimmt da nicht - auch die Kommastelle "bewegt" sich fast nicht. Werd den Helligkeitssensor nochmal entlöten und dann mal testen..... Die Temperatur wird dagegen korrekt dargestellt (kommt vom BMP, da kein SHT vorhanden).
Beim Helligkeitssensor gab es bei der 0.12er Firmware eine Änderung. Hier wird der Sensor per Interrupt ausgelesen.
Wenn der Interruptpin keine Verbindung hat, o.ä. dann gibt es keine Helligkeitswerte.
Ggf. kannst du das aber einfach testen indem du auf 0.11 downgradest.
Zitat von: Dirk am 20 November 2014, 19:59:56
Das hatte ich für die nächste FW-Version vor.
Cool.
Zitat von: Dirk am 20 November 2014, 19:59:56
Hast du mal versucht mit einem Raspberry Pi zu flashen (vorausgesetzt du hast einen)?
Im Moment habe ich da das gleiche Problem wie Du. Die Zeit....
Es dauert im Moment halt sich das alles zusammen zu suchen. Dazu muss ich den Pi noch vorbereiten, der ist im Moment anders genutzt.
Da müsste erst ein Debian drauf.
BTW Ich weiss was die anderen Werte Sprünge bei mir verursacht. Das ist ein FHEM/DB Problem und hat nix mit Homematic zu tun. ;)
FHEM und Mysql laufen bei mir in virtuellen Maschinen auf der gleichen HW und wenn da die IO Last zu hoch wird kann es dazu kommen, das wohl die Werte nicht schnell genug weggeschrieben werden,.
Da das DB Modul die Werte aber nicht mit der Empfangzeit sondern mit der Eintrage Zeit von Mysql in die DB einträgt sammeln sich die Werte an und scheinen irgendwie addiert zu werden.
Nico
Zitat von: Dirk am 20 November 2014, 20:17:08
Beim Helligkeitssensor gab es bei der 0.12er Firmware eine Änderung. Hier wird der Sensor per Interrupt ausgelesen.
Wenn der Interruptpin keine Verbindung hat, o.ä. dann gibt es keine Helligkeitswerte.
Ggf. kannst du das aber einfach testen indem du auf 0.11 downgradest.
Hallo Dirk, danke für den Tip!! Ja, bei meinem Helligkeitssensor fehlt die INT- Verbindung. Werde es testen und berichten! :-)
Heute mal neue Batterien eingesetzt - mal schauen wie lange es diesmal läuft.
Hallo Dirk,
habe jetzt die INT-Leitung des Helligkeitssensors mit A0 verbunden. Leider hat das nichts gebracht: Luftdruck liegt immernoch bei 96. Wenn ich allerdings die 0.10 FIrmware draufspiele (und in Fhem die entsprechende Datei auswechsle), dann ist der Luftdruck wieder bei 960. Irgendwas mach' ich falsch - aber was? .....
Int-Leitung ist nur für Lichtsensor relevant. In deinen Fall brauchst du neue Version von Fhem-THPL-Modul.
@hexenmeister:
Ich hab das Fhem-THPL-Modul schon der jeweiligen Firmware angepasst....
Hier die 0.12er FIrmware auf dem Sensor, und die 0.10 im Modul:
Readings
Activity
alive
2014-11-22 16:02:56
D-firmware
0.12
2014-11-20 18:47:01
D-serialNr
HB0Default
2014-11-20 18:47:01
batVoltage
0.00
2014-11-22 16:03:47
battery
low
2014-11-22 15:46:06
pressure
961
2014-11-22 16:03:47
state
T: 23.8 P: 961 batVoltage: 0.00
2014-11-22 16:03:47
temperature
23.8
Und hier 0.12er Sensor, 0.12er Modul:
Readings
Activity
alive
2014-11-22 16:06:11
D-firmware
0.12
2014-11-20 18:47:01
D-serialNr
HB0Default
2014-11-20 18:47:01
batVoltage
0.00
2014-11-22 16:06:07
battery
low
2014-11-22 15:46:06
pressure
96.1
2014-11-22 16:06:07
state
T: 23.8 P: 96.1
2014-11-22 16:06:07
temperature
23.8
2014-11-22 16:06:07
Zitat von: betateilchen am 06 April 2014, 10:49:52
Mal eine bescheidene Frage am Rande: Könnte man die Baugruppe irgendwie so einsetzen, dass man damit die Temperaturwerte von zwei Temperaturfühlern Typ K erfassen und übertragen kann?
Müsste mit dem AD8495 (http://www.adafruit.com/datasheets/AD8494_8495_8496_8497.pdf) bzw. dem "break-out" Board (http://www.exp-tech.de/Shields/Sonstige/adafruit-analog-output-k-type-thermocouple-amplifier-ad8495.html) halbwegs einfach zu realisieren sein. Die Spannung am A/D-Wandler einlesen entweder in der Firmware (besser) oder per UserReadings (vermutlich die schlechtere Variante wegen Homematic) in Temperatur umrechnen.
Gruß PeMue
@Hallo Dirk,
gibt es irgendwo noch Platienen und Funksensoren ???
Ich bräuchte 5 Stk.
Danke Mathias
Hej Dirk,
heute gab es wieder ein interessantes Verhalten von einem der Sensoren.
Aber sieh am besten selbst, wovon ich spreche. Der obere Graph zeigt die einzelnen Messwerte, im unteren ist die Spannung zu sehen. ;-)
da kann ich etwas dazu beisteuern, mein Aussensensor hat sich seit gestern verabschiedet und den habe ich erst Anfang Oktober bekommen und mit neuen Batterien bestückt, der ist total weg und zeigt eine Spannung von 1,26
Hatte mich gewundert warum der 6,3° anzeigt obwohl es wesentlich kälter war...
Hej Dirk,
nachdem ich heute die Batterien herausgenommen und gemessen hatte (beide knapp über 1V), dachte ich mir, ich steck sie einfach nochmal rein und warte ab, was passiert... und tatsächlich waren die übermittelten Werte plötzlich wieder in Ordnung und auch die Batterien haben sich wieder etwas gefangen (siehe Screenshot).
Wenn ich jetzt 1+1 zusammen zähle, dann würde ich sagen, irgendwas (ein Überlauf eines Zählers?) hat gestern dazu geführt, dass der Controller nicht mehr schlafen gegangen ist und somit angefangen hat, die Batterie leer zu saugen. Die allmähliche Zunahme der Temperatur von +3° würde auch dazu passen, dass der Chip ständig gewerkelt hat und etwas wärmer geworden ist, was schlussendlich den Sensor beeinflusst hat.
Ich habe zwar die v0.13 im Einsatz, da aber moonsorrox mit der v0.12 ein ähnliches Fehlerbild gemeldet hat, dürfte es zumindest nicht mit der Testversion zu tun haben. :-)
Hallo zusammen,
Im Moment bin ich leider durch meinen Umzug etwas "behindert".
Daher die längeren Reaktionszeiten aktuell.
Zitat von: ichdoof am 26 November 2014, 11:00:40
gibt es irgendwo noch Platienen und Funksensoren ???
Ja, Platinen gibt es noch. Du hast eine PM mit weiteren Infos.
Zitat von: Mr. P am 29 November 2014, 16:02:41
Wenn ich jetzt 1+1 zusammen zähle, dann würde ich sagen, irgendwas (ein Überlauf eines Zählers?) hat gestern dazu geführt, dass der Controller nicht mehr schlafen gegangen ist und somit angefangen hat, die Batterie leer zu saugen.
Sobald ich hier wieder Arbeitsfähig bin dann werde ich das auch untersuchen.
Derzeit muss ich sogar das Licht noch manuell schalten. Für den Einbau der HM-Komponenten war noch keine Zeit. Und der Server mit FHEM läuft auch noch nicht :(
Aber es wird langsam.
Gruß
Dirk
Hallo Zusammen,
Hab da ein Tool zum ATMEGA flashen entdeckt, einfach mit UBBasp und diesem Kabel welches direkt auf den QFN Chip gesteckt wird. Lästiges suchen von PIN Verbindungen wenn kein ISP-Header zur Verfügung steht.
Vielleicht nützt es ja jemanden von Euch, gibt es auch günstiger in der Bucht aus Korea.
http://www.hobbyking.com/hobbyking/store/__42120__Atmel_Atmega_Socket_Firmware_Flashing_Tool_EU_warehouse_.html (http://www.hobbyking.com/hobbyking/store/__42120__Atmel_Atmega_Socket_Firmware_Flashing_Tool_EU_warehouse_.html)
Gruß
Stefan
Zitat von: Porky666 am 03 Dezember 2014, 10:11:28
Hab da ein Tool zum ATMEGA flashen entdeckt, einfach mit UBBasp und diesem Kabel welches direkt auf den QFN Chip gesteckt wird. Lästiges suchen von PIN Verbindungen wenn kein ISP-Header zur Verfügung steht.
Vielleicht nützt es ja jemanden von Euch, gibt es auch günstiger in der Bucht aus Korea.
http://www.hobbyking.com/hobbyking/store/__42120__Atmel_Atmega_Socket_Firmware_Flashing_Tool_EU_warehouse_.html (http://www.hobbyking.com/hobbyking/store/__42120__Atmel_Atmega_Socket_Firmware_Flashing_Tool_EU_warehouse_.html)
Wuah, das Ding ist ja geil. Ich brauch's zwar eigentlich nicht mehr, aber ich will es haben! :) Das Korea Angebot, das ich gefunden habe, war allerdings minimal teurer (17,73€ vs. 17,56€).
Grüße, Marcel
P.S.: Im China Warehouse ist es noch für 16€ vorrätig: http://www.hobbyking.com/hobbyking/store/__27195__Atmel_Atmega_Socket_Firmware_Flashing_Tool.html (http://www.hobbyking.com/hobbyking/store/__27195__Atmel_Atmega_Socket_Firmware_Flashing_Tool.html)
Hallo Dirk,
nur zur Info, ich habe meinen Aussen-Sensor (nur Helligkeit, D-firmware 0.12) am 05.10. mit neuen Batterien in Betrieb genommen.
Am 29.11. hat er dann Batterie low gemeldet und gar keine Werte mehr übermittelt.
Nach Batteriewechsel läuft natürlich jetzt alles wieder.
Gruß
Adam
in etwa so wie meiner, Anfang Oktober in Betrieb genommen und am 29.11. den Dienst quittiert...
Batterien getauscht und er funktioniert wieder...
Aber irgendwie nicht zufriedenstellend ...!
29.11 magisches Datum...! ;)
Hej folks,
falls ihr noch die Logfiles der Sensoren habt, könnt' ihr bitte aus diesen einen Plot der Batteriespannung (und falls vorhanden) der Temperatur machen?
Oder aber mir einfach die Files zukommen lassen?
Thx a lot! :-)
Edit:
Hatte meinen Sensor ebenfalls am 05.10. in Betrieb genommen... also eigentlich kann das nur irgendein Überlauf sein, der zur Folge hat, dass gut Wärme produziert wird. Ist bestimmt nur eine Kleinigkeit und Dirk wird das recht schnell gefixt haben, sobald sein Umzug soweit "abgeschlossen" ist. :-)
hier mein Plot. Temperatur habe ich nicht, nur Helligkeit. Sensor steht draussen!
Zitat von: Mr. P am 29 November 2014, 16:02:41
Die allmähliche Zunahme der Temperatur von +3° würde auch dazu passen, dass der Chip ständig gewerkelt hat und etwas wärmer geworden ist, was schlussendlich den Sensor beeinflusst hat.
Das passt ja irgendwie exakt zu meinem bereits am 19./20.11. beschriebenen Fehlerbild :)
Die zwei Monate, die Temperaturerhöhung, der plötzliche Spannungsabfall...
Auf die Idee, die "alten" Batterien wieder zu verwenden, war ich allerdings nicht gekommen.
Zitat von: betateilchen am 04 Dezember 2014, 08:22:06Die zwei Monate,...
Hi,
seid Ihr sicher, dass es zwei Monate sind und nicht etwa zwischen 49 und 50 Tagen? Das könnte nämlich mit fehlerhafter Verwendung der millis() zusammenhängen. Ich habe mal kurz in die AskSin-Library geschaut und ein paar Stellen gefunden, die ungefähr so aussehen:
unsigned long xMillis = millis();
792 if (powr.nxtTO > xMillis) return; // no need to do anything
793
794 if (send.counter > 0) return; // send queue not empty
795
796 if ((powr.mode == POWER_MODE_BURST) && (powr.state == 0)) {
797 uint32_t nxtTO;
798
799 // power mode 2, module is in sleep and next check is reached
800 if (cc.detectBurst()) { // check for a burst signal, if we have one, we should stay awake
801 nxtTO = millis() + powr.minTO; // schedule next timeout with some delay
802 } else { // no burst was detected, go to sleep in next cycle
803 nxtTO = millis(); // set timer accordingly
804 }
Es wird da einfach etwas auf millis() drauf addiert bzw. millis() einfach mit einem Wert verglichen. Wenn nicht der millis()-Counter irgendwo zurückgesetzt wird (was nicht passiert, glaube ich), dann gibt das garantiert irgendwann mal Probleme.
Ich denke, dass es mehrere solcher Stellen gibt.
Gruß,
Thorsten
Hallo,
millis() haben noch einen anderen unangenehmen Effect. Ohne RTC laufen die millis() im Tiefschlaf nicht weiter. Ich habe mir bei meinen S0 Conuer damit geholfen, das ich immer nur kurz schlafe und die Anzahl der Schlafzeiten zähle - als Ersatz für millis().
Gruß Christoph
Zitat von: Porky666 am 03 Dezember 2014, 10:11:28
Hab da ein Tool zum ATMEGA flashen entdeckt, einfach mit UBBasp und diesem Kabel welches direkt auf den QFN Chip gesteckt wird. Lästiges suchen von PIN Verbindungen wenn kein ISP-Header zur Verfügung steht.
Cooles Teil. Danke für den Link.
Zitat von: Thorsten Pferdekaemper am 04 Dezember 2014, 09:45:16
seid Ihr sicher, dass es zwei Monate sind und nicht etwa zwischen 49 und 50 Tagen? Das könnte nämlich mit fehlerhafter Verwendung der millis() zusammenhängen.
Ich habe auch langsam die millis in verdacht.
Ich werde wohl schon in der kommenden FW Version auf die neue Asksin-Lib umschwenken. Da hatte das Trillu auch gefixt.
Zitat von: Bennemannc am 04 Dezember 2014, 09:57:25
millis() haben noch einen anderen unangenehmen Effect. Ohne RTC laufen die millis() im Tiefschlaf nicht weiter.
Das war im Code bereits berücksichtigt.
Gruß
Dirk
Zitat von: Thorsten Pferdekaemper am 04 Dezember 2014, 09:45:16
seid Ihr sicher, dass es zwei Monate sind
Ziemlich sicher - und reproduzierbar.
hier mal mein Plot vom 27. November.
Am 30 September 2014 habe ich die PM bekommen von ihm das Dirk mir den Sensor geschickt hat. Ich habe ihn am 03. Oktober in Betrieb genommen. Am 29. November habe ich eine neue Batterie eingesetzt.
Wenn ein Log gewünscht wird hätte ich auch noch hier...
So einen ähnlichen Plot hatte ich hier im Thread (http://forum.fhem.de/index.php/topic,20620.msg199651/topicseen.html#msg199651) schon im September gepostet :)
(http://up.picr.de/19501064ll.png)
Zitat von: Dirk am 04 Dezember 2014, 10:12:40
Ich habe auch langsam die millis in verdacht.
Ich werde wohl schon in der kommenden FW Version auf die neue Asksin-Lib umschwenken. Da hatte das Trillu auch gefixt.
Dann frag ich jetzt - unter Bedacht, dass Dirk gerade mit umziehen beschäftigt ist - ob es schon einen Zeithorizont gibt, bis wann es eine neue Version geben wird? Vielleicht geht es sich als Weihnachtsgeschenk aus? :-)
Zitat von: betateilchen am 04 Dezember 2014, 13:28:46
So einen ähnlichen Plot hatte ich hier im Thread (http://forum.fhem.de/index.php/topic,20620.msg199651/topicseen.html#msg199651) schon im September gepostet :)
nur meiner ist auf Deutsch gesagt einfach "abgekackt" weg war er ;)
hallo,
gibt es eigentlich schon die möglichkeit über peeren einen aktor lichtabhängig zu schalten? ich habe den sensor mal mit einem aktor gepeert, stelle aber keine weiteren messages fest. das peering sieht in beiden devices gut aus. sind eventuell schon pläne auf der todolist?
gruss frank
Hallo,
ich benötige Hilfe beim Flashen. Ich wollte mit dem RPI über GPIO den Outdoorsensor flashen. Das Hex File habe ich und auch die Verdrahtung. Ich scheitere daran, dass das avrdude aus dem Raspbinan Paket kein "-c gpio" mag und mir statt dessen einen Haufen anderer Schnittstellen vorschlägt. Benötigt man zu Flashen eine spezielle Version der avrdude ? Wo bekommt man diese her ?
Gruß Christoph
Hallo Christoph,
du kannst mein flash.pl skript benutzen (https://github.com/bullshit/AskSinBootloader_Flash-Tool-RaspberryPi) oder du verwendest die avrdude version von mir in der die GPIO erweiterung inkludiert ist.
Lg
@Hallo Dirk,
ich würde mir auch gerne so eine Baugruppe bauen. Hast Du noch Platinen oder gibts vielleicht auch eine fertige Baugruppe als RS485 Version???
Danke,
Detlef :)
Hallo Dirk,
Kann ich die HM_WDS10_TH_O auch mit ein 5volt netzteil betreiben?
Grüße Mark,
Zitat von: MdeJong am 13 Dezember 2014, 17:23:42
Kann ich die HM_WDS10_TH_O auch mit ein 5volt netzteil betreiben?
Wenn du am Sensor einen Max1724 verwendest, dann sind 5V drinnen, da der bis 5,5V seinen Job macht.
Einfach die Kabeln vom (ich nehme an) USB-Ladegerät an den Batteriekontakten fixieren und das wars (und bleibst flexibel, solltest du doch wieder einmal Batterien nutzen wollen). ;-)
Bist du sicher? Habe gerade kein Datenblatt zur Hand, aber die meisten stepup Wandler können keine Ausgangsspannung liefern, die kleiner als Eingang ist. Die kommen halt mit der etwas höheren Spannung klar, mehr nicht.
Der mC ist das egal, aber die Sensoren könnten das übel nehmen.
Ich würde zunächst liebst nachlesen.
Hallo zusammen,
Zitat von: Mr. P am 04 Dezember 2014, 15:10:10
Dann frag ich jetzt - unter Bedacht, dass Dirk gerade mit umziehen beschäftigt ist - ob es schon einen Zeithorizont gibt, bis wann es eine neue Version geben wird? Vielleicht geht es sich als Weihnachtsgeschenk aus? :-)
Jetzt sind wir hier langsam fertig, obwohl I-Net immer noch nicht geht.
Mit dem Firmwareupdate wird es vor Weihnachten wohl nichts mehr. Das wird eher ein Neujahrspräsent.
Ich werde aber noch einige Sensoren fertig machen, so dass der eine oder andere diese hoffentlich noch vor Weihnachten bekommt.
Zitat von: frank am 04 Dezember 2014, 18:46:29
gibt es eigentlich schon die möglichkeit über peeren einen aktor lichtabhängig zu schalten? ich habe den sensor mal mit einem aktor gepeert, stelle aber keine weiteren messages fest. das peering sieht in beiden devices gut aus. sind eventuell schon pläne auf der todolist?
Aktuell nur per FHEM. Das wird ggf. Feature einer späteren FW-Version.
Zitat von: un7 am 13 Dezember 2014, 14:05:39
ich würde mir auch gerne so eine Baugruppe bauen. Hast Du noch Platinen oder gibts vielleicht auch eine fertige Baugruppe als RS485 Version???
Ja, es ist noch alles da. Du bekommst eine PM mit den Details.
Zitat von: MdeJong am 13 Dezember 2014, 17:23:42
Kann ich die HM_WDS10_TH_O auch mit ein 5volt netzteil betreiben?
Die Maximale Eingangsspannung vom MAX1724 liegt laut Datenblatt bei 5,5V. Daher kannst du das so machen wie es Mr.P vorgeschlagen hat.
Alternativ habe ich hier eine fertig bestückte Variante des Sensors für externe Spannungsversorgung mit einem Eingangsspannungsbereich von ca. 5 V - ca. 30 V.
Viele Grüße
Dirk
Hallo Dirk,
ich möchte nochmal auf das Thema Luftdruck zurückkommen - siehe http://forum.fhem.de/index.php/topic,20620.msg222303.html#msg222303
Ich habe mir jetzt einen neuen Luftdrucksensor gekauft - aber ich habe weiterhin merkwürdige (geteilt durch 10) - Luftdruck-Werte, obwohl ich im Modul - als auch FIrmware die Version 0.12 drauf habe...
Hast du noch einen Tip für mich? :-)
EDIT:
Jetzt hab ich mal meinen China-Step-Up-Wandler rausgeschmissen, und den Sensor mit 3 Akkus verbunden - und siehe da: Der Luftdruck ist wieder korrekt da! Komisches Phänomen!!
hi,
hab die fuses falsch gesetzt, jetzt gibt der sensor keinen mucks mehr von sich.
avrdude -p atmega328p -P gpio -c gpio -U lfuse:w:0xFD:m -U hfuse:w:0xD8:m
platinchen hängt über sck/miso/mosi an gpio's eines raspberry.
aber leider nur noch
avrdude: AVR device not responding
wie komme ich da weiter ?
danke
Hat mir jemand eine Bezugsquelle für die Gehäuse (innen und aussen)?
ZitatGehäuse:
Innen weiß (Elfenbein oder schwarz sind auch möglich)
Außen grau mit transparenter Deckel, wasserdicht / luftdicht
aussen http://www.elv.de/industrie-aufputz-gehaeuse-ip65-modell-g201c.html
Zitat von: Hauswart am 30 Dezember 2014, 16:05:15
Hat mir jemand eine Bezugsquelle für die Gehäuse (innen und aussen)?
Interne Gehäuse war von tme.eu
Der Link muss irgendwo in diesem Thread sein.
Mein Außensensor brauchte nun nach knapp 2 Monaten auch neue Batterien.
Hat die 12er Firmware und ist lediglich mit dem Helligkeitssensor (+Max) bestückt.
Würde ein Update auf die 13er Firmware zu einer Verbesserung führen und geht das einfach über 'fwUpdate' oder muss ich da anders vorgehen?
Hallo,
ich bekomme den Wettersensor von Dirk nicht zu laufen.
Fhem auf dem neusten Stand, die HMConfig_SenTHPL.pm in das Verz. /opt/fhem/FHEM kopiert, Leserechte für alle und
Besitzer fhem. Alles auf einem Raspi, den auch neu gestartet.
Nach einem set CUL1 hmPairForSec 600 und dem Drücken der Taste am Wettersensor, ca. 5 sec, blinkt der Wettersensor,
aber kein Eintrag in der Fhem Config. Fhem über Cul, Version weis ich nicht. ca. 1,5 Jahre alt.(Version auslesen wie?)
Hat jemand ne Idee.
cu erwin23
Dein Fhem hat nen Stand von vor 1,5jahren?
Dann würde ich mal Update laufen lassen
Hallo,
die Cul hat diesen Stand, Fhem neu.
cu erwin23
@Pjg: Ja, da gibt es derzeit noch einen Bug (Überlauf?). Sobald zeitlich wieder Luft, wird sich Dirk damit auseinander setzen. Einstweilen kannst du "workarounden", indem du nach 1 1/2 Monaten die Batterien kurz raus nimmst und wieder hinein gibst. ;-)
@erwin23: Log doch bitte einmal die Raw-Messages während des pairen mit und poste sie.
Hallo,
habe die CUL upgedatet auf V1.61.
Nach einem set CUL1 hmPairForSec 600 holt sie noch Daten und hat Teile des Gebers in die .cfg eingetragen.
Hier die Eintäge:
define CUL_HM_HB_UW_Sen_THPL_O_F5B797 CUL_HM F5B797
attr CUL_HM_HB_UW_Sen_THPL_O_F5B797 room CUL_HM
define FileLog_CUL_HM_HB_UW_Sen_THPL_O_F5B797 FileLog ./log/CUL_HM_HB_UW_Sen_THPL_O_F5B797-%Y.log CUL_HM_HB_UW_Sen_THPL_O_F5B797
attr FileLog_CUL_HM_HB_UW_Sen_THPL_O_F5B797 logtype text
attr FileLog_CUL_HM_HB_UW_Sen_THPL_O_F5B797 room CUL_HM
oder fehlt da noch was?
Cu erwin23
Hej erwin23,
sieht eigentlich ganz gut aus...
Ich vermute, du bekommst jetzt auch Daten von dem Sensor? :-)
Hallo zusammen,
nachdem ich zwei Tage gebraucht habe, bis ich aus den Dateien im Git eine Firmware bauen konnte, will ich mal beschreiben, was ich tun musste:
Mein Setup: Arduino 1.0.5 auf Linux Mint KDE 17.0, Quelle ist Dirks GitHub (https://github.com/kc-GitHub)
- AskSin-Master und Wettersensor-master als Zip vom GitHub heruntergeladen
- AskSin-Master in den library-Ordner entpackt, dabei "-master" entfernt
- Wettersensor-master in ein getrenntes Verzeichnis entpackt, aus dem Unterordner Firmware-Src alles unter "Libraries" in sketchbook/libraries kopiert (BMP085, Sensirion, TSL2561, Wire)
- die übrigen Dateien in Firmware-Src (WetterSensor.h, WetterSensor.ino und Register.h) in das erstellte Verzeichnis sketchbook/WetterSensor kopiert
Wenn ich dann die Arduino-IDE starte, sind die Libs da (AskSin, BMP085, Sensirion, TSL2561 und Wire) und im Sketchbook-Menü gibt es den Eintrag "WetterSensor".
Beim Kompilieren kommt ein Fehler, dass "wire.h" nicht gefunden wird, das lässt sich beheben, indem "#include <wire.h>" auch in die WetterSensor.ino eingefügt wird (was wohl ein Bug in der Arduino-IDE ist?!). Gleiches gilt für die nächste Fehlermeldung - in der StatusLed.h-Datei wird Serial.h nicht gefunden; dies lässt sich beheben, indem in der Datei /sketchbook/libraries/AskSin/utility/StatusLed.h die Zeile
#include <Serial.h>
geändert wird in
#include "Serial.h"
Das gleiche nochmal in libraries/AskSin/utility/Battery.h, schließlich muss in libraries/AskSin/utility/FastDelegate.h der Eintrag "#include <memory.h>" auskommentiert werden, da auch die memory.h fehlt.
Als nächstes wirft mein avr-gcc (4.8.2) einen Fehler aus, weil in Register.h die Variable clnDefType nicht als "const" deklariert ist, obwohl sie in den Flashspeicher soll, also muss in Register.h in Zeile 82 ein "const" ergänzt werden:
const s_cnlDefType cnlDefType[] PROGMEM = {
Beim nächsten Anlauf wird in der Datei Sensor_SHT10_BMP085_TSL2561.cpp die Header-Datei "twi.h" nicht gefunden, auch hier kann man den Eintrag auskommentieren.
Nächste Beschwerde ist, dass initVal in AskSin/util/cc110x.cpp nicht als "const" definiert wird, also muss in der Datei die Zeile
static prog_uint8_t initVal[] PROGMEM = { geändert werden in
static const prog_uint8_t initVal[] PROGMEM = {
Danach läuft der Compiler durch, allerdings beschwert sich der Linker über fehlende Verweise auf verschiedene Funktionen, dies lässt sich beheben, indem man in der Datei WetterSensor.ino noch Folgendes ergänzt:
#include <TSL2561.h>
#include <Sensirion.h>
#include <BMP085.h>
So, jetzt habe ich nur noch das Problem, dass mein ProMicro (auf Basis 32u4) nicht unterstützt wird...
Schönen Sonntag,
Sebastian
Zitat von: juppzupp am 30 Dezember 2014, 16:13:51
aussen http://www.elv.de/industrie-aufputz-gehaeuse-ip65-modell-g201c.html
Zitat von: hexenmeister am 30 Dezember 2014, 17:46:51
Interne Gehäuse war von tme.eu
Der Link muss irgendwo in diesem Thread sein.
Danke ihr zwei :-)
Innen war: http://www.tme.eu/de/details/box-sens-white/gehaeuse-fuer-alarmanlagen-und-sensoren/supertronic/#
Hallo,
bekomme jetzt beim pairen keine Einträge in die fhem.cfg
im Logfile steht folgendes :
2015.01.05 21:06:48.408 4: CUL_Parse: CUL1 A 0F 17 8610 2BA327 000000 0AF4F61064402F -50.5
2015.01.05 21:06:49.943 4: CUL_Parse: CUL1 A 14 02 A270 F5B797 F11234 010000282F00006B8C0A9F2E -51
2015.01.05 21:06:49.952 3: CUL1: Unknown code A1402A270F5B797F11234010000282F00006B8C0A9F::-51:CUL1, help me!
2015.01.05 21:06:50.647 4: CUL_Parse: CUL1 A 14 02 A270 F5B797 F11234 010000282F00006B8C0A9F2E -51
2015.01.05 21:06:50.655 3: CUL1: Unknown code A1402A270F5B797F11234010000282F00006B8C0A9F::-51:CUL1, help me!
Was ist das?
cu erwin23
Hallo Erwin23,
hast Du die "HMConfig_SenTHPL.pm" heruntergeladen und in Dein /FHEM/ Verzeichnis eingefügt ?
Gruß Christoph
gibts da noch welche und was kostet das ?
gruß otto
Hallo,
ja die HMConfig_SenTHPL.pm ist im FHEM Verzeichnis mit Leserechten.
cu erwin23
Hallo Erwin23,
hast Du auch schon mal das PairSerial ausprobiert ? Bei mir hat das damals beim pairen auch nicht direkt funktioniert - aber nach mehreren Versuchen ging es dann doch.
Was hast Du denn für eine FW und welche Bootloader ?
Gruß Christoph
hallo erwin,
ich verstehe gerade dein problem nicht ganz. wenn du diese msg erhälst:
Zitat2015.01.05 21:06:49.943 4: CUL_Parse: CUL1 A 14 02 A270 F5B797 F11234 010000282F00006B8C0A9F2E -51
dann sendet dein sensor (rot) an deine zentrale F11234. dann sollte dein device doch gepairt sein. rssi sieht auch gut aus. autocreate hat ja auch ein device angelegt.
Hallo frank,
ich dachte wenn autocreate was anlegt steht es auch in der fhem.cfg
cu erwin23
define CUL_HM_HB_UW_Sen_THPL_O_F5B797 CUL_HM F5B797
attr CUL_HM_HB_UW_Sen_THPL_O_F5B797 room CUL_HM
define FileLog_CUL_HM_HB_UW_Sen_THPL_O_F5B797 FileLog ./log/CUL_HM_HB_UW_Sen_THPL_O_F5B797-%Y.log CUL_HM_HB_UW_Sen_THPL_O_F5B797
attr FileLog_CUL_HM_HB_UW_Sen_THPL_O_F5B797 logtype text
attr FileLog_CUL_HM_HB_UW_Sen_THPL_O_F5B797 room CUL_HMist dies nicht von autocreate? was ergibt ein list? es fehlt auf jeden fall attr model und subtype.
Zitatich dachte wenn autocreate was anlegt steht es auch in der fhem.cfg
hast du save gemacht, damit es auch reingeschrieben wird?
Ich habe ein ähnliches Problem. Paring geht offenbar, denn der Sensor wird in der Übersicht angezeigt, allerdings mit Fragezeichen. Im logfile werden Seriennummer und Firmware-Stand gelistet, sonst nichts. lastMsg ist bei mir: No:0A - t:70 s:95E92C d:F10000 0000000000000042BB09B1
Hab schon viel versucht :-\
Weiß jemand was?
Ich habe Fragen:
Wie kann die Sensoren von der Zentral unpairen? ... und wie kann man die Sensoren in den Werkszustand zurücksetzen?
Hallo ,
bin immer noch nicht weiter mit dem pairen des Wettersensors.
Die HMConfig_SenTHPL.pm ist aktuell und in /opt/fhem/FHEM mit den Rechten wied die anderen .pm Dateien.
Noch sicherheitshalber ein dos2unix über die HMConfig_SenTHPL.pm laufen lassen.
Nach einem set CUL1 hmPairForSec 600 wird nichts mehr in die fhem.cfg eingetragen auch im Logfile steht nichts für diesen Zeitpunkt.
Der Wettersensor blinkt nach betätigen von 5 sec., nur wir nichts ins Configfile geschriebn, auch nicht nach save config.
Im Logfile habe ich keine Meldungen die vom Wettersensor zu diesem Zeitpunkt stammen könnten.
Er kommen immer zyklisch diese Meldungen
2015.01.15 10:12:00.335 4: CUL_Parse: CUL1 A 14 29 A270 F5B797 F11234 00CD0026FC000006000A4426 -55
2015.01.15 10:12:00.345 3: CUL1: Unknown code A1429A270F5B797F1123400CD0026FC000006000A44::-55:CUL1, help me!
2015.01.15 10:12:01.043 4: CUL_Parse: CUL1 A 14 29 A270 F5B797 F11234 00CD0026FC000006000A4425 -55.5
2015.01.15 10:12:01.053 3: CUL1: Unknown code A1429A270F5B797F1123400CD0026FC000006000A44::-55.5:CUL1, help me!
Weiss jetzt nicht mehr weiter.
Bootloader und Firmware sollten aktuell sein, Geber 12/14 bei Dirk gekauft. Auf der Platine steht Rev. 1.2.
PairSerial, da muss ich mich noch einlesen oder hat jemend den schnellen Tip.
Beste Grüsse erwin23
Hallo,
mal set CUL1 hmPairSerial UWS45464XX für den Wettersensor durchgeführt.
Es wird nichts im Logfile noch in der fhem.cfg eingetragen,
Hier meine Einstellungen für die Logdateien mit Cul 868 von Busware V1.61
attr global verbose 1
attr global mseclog 1
attr CUL1 verbose 4
Sensor OTAU 0.70
Beste Grüsse erwin23
Hi erwin23,
ich würde dir heute Abend mal ein "nacktes" FHEM bauen welches ich vorher bei mir getestet habe.
Wenn das dann bei dir immer noch nicht funktioniert müssten wir dann noch mal weitersehen.
Viele Grüße
Dirk
Zitat von: Bastel-Frank am 13 Januar 2015, 18:29:48
Ich habe Fragen:
Wie kann die Sensoren von der Zentral unpairen?
set <sensorname> unpairAnschliesend dir Config-Taste einmal drücken
Zitatund wie kann man die Sensoren in den Werkszustand zurücksetzen?
set <sensorname> resetAnschliesend dir Config-Taste einmal drücken
oder:
- Configtaste drücken -> led blinkt
- Configtaste lange drücken (ca. 5-10 sek.) -> led blinkt schnell
- Configtaste noch mal lange drücken (ca. 5-10 sek.) -> led blinkt kurz und hört dann auf
Gruß
Dirk
Ich möchte mit den Devices von meiner Test- auf die Produktiv-Umgebung umziehen:
Zitat von: Dirk am 15 Januar 2015, 11:26:35
set <sensorname> unpair
...
set <sensorname> reset
...
- Configtaste drücken -> led blinkt
- Configtaste lange drücken (ca. 5-10 sek.) -> led blinkt schnell
- Configtaste noch mal lange drücken (ca. 5-10 sek.) -> led blinkt kurz und hört dann auf
Habe ich gerade alles gemacht. Nur leider werden die Events weiterhin von der Test-Umgebung empfangen, obwohl "PairedTo" auf 0x000000 steht. Das Anlernen an der Produktiv-Umgebung klappt nicht. Wie gesagt, die Events erscheinen weiterhin in der Test-Umgebung. Bin ratlos ...
Neu ist nun, dass ein Sensor "sabotageAttack" und "sabotageAttackId". Wie bekomme ich diese Meldungen weg? ... und warum kommen sie?
Viele Grüße
Frank
Wenn die Adresse "PairedTo" auf 000000 steht, geht die Meldung an broadcast und wird von allen Homematic Empfängern "gehört".
Eigentlich braucht man den Sensor überhaupt nicht zu pairen.
Hallo Dirk,
läuft immer noch nicht. Bin mal gespannt auf deine Version.
Beste Grüsse und thx erwin23
Hallo,
ZitatWenn die Adresse "PairedTo" auf 000000 steht, geht die Meldung an broadcast und wird von allen Homematic Empfängern "gehört".
Eigentlich braucht man den Sensor überhaupt nicht zu pairen.
Bedeutet aber auch, das die Message nicht wiederholt wird, wenn die Zentrale sie nicht komplett empfangen hat. Ist bei dem Sensor eventuell nicht tragisch, aber wenn ich darüber etwas steuern möchte, würde ich schon pairen.
Ein anderes Thema:
Ich lasse alle Werte mitloggen. Dabei ist mit aufgefallen, dass Nachts keine Werte für Lichstärke übertragen werden - auch kein "0"
2015-01-12_03:34:21 Weather_1 T: 6.9 H: 83 P: 10153 P-NN: 10155 batVoltage: 2.82
2015-01-12_03:37:25 Weather_1 T: 6.9 H: 84 P: 10154 P-NN: 10156 batVoltage: 2.82
2015-01-12_03:40:15 Weather_1 T: 7.0 H: 84 P: 10154 P-NN: 10156 batVoltage: 2.80
2015-01-12_03:42:48 Weather_1 T: 7.0 H: 84 P: 10155 P-NN: 10157 batVoltage: 2.79
2015-01-12_03:45:06 Weather_1 T: 7.0 H: 83 P: 10154 P-NN: 10156 batVoltage: 2.79
2015-01-12_03:48:18 Weather_1 T: 7.0 H: 84 L: 0 P: 10153 P-NN: 10155 batVoltage: 2.80
2015-01-12_03:51:14 Weather_1 T: 7.0 H: 84 L: 0 P: 10151 P-NN: 10153 batVoltage: 2.81
2015-01-12_03:53:55 Weather_1 T: 7.0 H: 84 P: 10152 P-NN: 10154 batVoltage: 2.79
2015-01-12_03:56:19 Weather_1 T: 7.0 H: 84 P: 10151 P-NN: 10153 batVoltage: 2.79
2015-01-12_03:59:38 Weather_1 T: 7.0 H: 84 P: 10150 P-NN: 10152 batVoltage: 2.80
2015-01-12_04:05:28 Weather_1 T: 7.0 H: 84 L: 0 P: 10151 P-NN: 10153 batVoltage: 2.80
2015-01-12_04:08:00 Weather_1 T: 7.0 H: 84 P: 10149 P-NN: 10151 batVoltage: 2.82
2015-01-12_04:10:16 Weather_1 T: 7.0 H: 84 L: 0 P: 10149 P-NN: 10151 batVoltage: 2.82
2015-01-12_04:13:25 Weather_1 T: 7.0 H: 84 P: 10149 P-NN: 10151 batVoltage: 2.81
2015-01-12_04:16:19 Weather_1 T: 7.0 H: 84 P: 10150 P-NN: 10152 batVoltage: 2.80
2015-01-12_04:18:58 Weather_1 T: 7.1 H: 84 P: 10149 P-NN: 10151 batVoltage: 2.80
2015-01-12_04:21:21 Weather_1 T: 7.1 H: 84 L: 0 P: 10148 P-NN: 10150 batVoltage: 2.79
2015-01-12_04:24:37 Weather_1 T: 7.1 H: 84 L: 0 P: 10148 P-NN: 10150 batVoltage: 2.81
2015-01-12_04:27:38 Weather_1 T: 7.1 H: 84 L: 0 P: 10148 P-NN: 10150 batVoltage: 2.80
2015-01-12_04:30:23 Weather_1 T: 7.1 H: 84 L: 0 P: 10148 P-NN: 10150 batVoltage: 2.82
2015-01-12_04:32:53 Weather_1 T: 7.1 H: 84 P: 10148 P-NN: 10150 batVoltage: 2.80
2015-01-12_04:35:07 Weather_1 T: 7.1 H: 84 P: 10148 P-NN: 10150 batVoltage: 2.82
2015-01-12_04:38:15 Weather_1 T: 7.2 H: 84 P: 10147 P-NN: 10149 batVoltage: 2.80
2015-01-12_04:41:07 Weather_1 T: 7.2 H: 84 P: 10147 P-NN: 10149 batVoltage: 2.82
2015-01-12_04:43:44 Weather_1 T: 7.2 H: 84 P: 10146 P-NN: 10148 batVoltage: 2.80
2015-01-12_04:46:05 Weather_1 T: 7.2 H: 84 P: 10147 P-NN: 10149 batVoltage: 2.80
2015-01-12_04:49:19 Weather_1 T: 7.2 H: 84 L: 0 P: 10146 P-NN: 10148 batVoltage: 2.82
2015-01-12_04:52:18 Weather_1 T: 7.2 H: 84 P: 10145 P-NN: 10147 batVoltage: 2.81
2015-01-12_04:55:02 Weather_1 T: 7.2 H: 84 L: 0 P: 10144 P-NN: 10146 batVoltage: 2.80
2015-01-12_04:57:29 Weather_1 T: 7.2 H: 84 L: 0 P: 10143 P-NN: 10145 batVoltage: 2.80
2015-01-12_04:59:41 Weather_1 T: 7.3 H: 84 L: 0 P: 10144 P-NN: 10146 batVoltage: 2.80
2015-01-12_05:02:47 Weather_1 T: 7.2 H: 84 P: 10144 P-NN: 10146 batVoltage: 2.80
2015-01-12_05:05:37 Weather_1 T: 7.3 H: 84 P: 10144 P-NN: 10146 batVoltage: 2.81
2015-01-12_05:08:12 Weather_1 T: 7.3 H: 84 P: 10145 P-NN: 10147 batVoltage: 2.81
2015-01-12_05:10:31 Weather_1 T: 7.3 H: 84 P: 10144 P-NN: 10146 batVoltage: 2.82
2015-01-12_05:13:43 Weather_1 T: 7.3 H: 84 P: 10144 P-NN: 10146 batVoltage: 2.80
2015-01-12_05:16:40 Weather_1 T: 7.3 H: 84 P: 10145 P-NN: 10147 batVoltage: 2.82
2015-01-12_05:19:22 Weather_1 T: 7.4 H: 84 P: 10143 P-NN: 10145 batVoltage: 2.80
2015-01-12_05:21:48 Weather_1 T: 7.4 H: 84 P: 10141 P-NN: 10143 batVoltage: 2.80
2015-01-12_05:25:07 Weather_1 T: 7.4 H: 84 P: 10142 P-NN: 10144 batVoltage: 2.79
2015-01-12_05:28:11 Weather_1 T: 7.3 H: 84 P: 10141 P-NN: 10143 batVoltage: 2.80
2015-01-12_05:30:59 Weather_1 T: 7.4 H: 84 P: 10140 P-NN: 10142 batVoltage: 2.81
2015-01-12_05:33:32 Weather_1 T: 7.4 H: 84 P: 10141 P-NN: 10143 batVoltage: 2.80
2015-01-12_05:35:49 Weather_1 T: 7.4 H: 84 L: 0 P: 10141 P-NN: 10143 batVoltage: 2.80
2015-01-12_05:41:54 Weather_1 T: 7.4 H: 84 L: 0 P: 10139 P-NN: 10141 batVoltage: 2.80
2015-01-12_05:44:34 Weather_1 T: 7.4 H: 84 L: 0 P: 10138 P-NN: 10140 batVoltage: 2.80
2015-01-12_05:46:58 Weather_1 T: 7.4 H: 84 P: 10137 P-NN: 10139 batVoltage: 2.79
2015-01-12_05:50:15 Weather_1 T: 7.4 H: 84 P: 10137 P-NN: 10139 batVoltage: 2.82
2015-01-12_05:53:17 Weather_1 T: 7.5 H: 84 L: 0 P: 10138 P-NN: 10140 batVoltage: 2.80
2015-01-12_05:56:03 Weather_1 T: 7.5 H: 84 L: 0 P: 10136 P-NN: 10138 batVoltage: 2.81
2015-01-12_05:58:34 Weather_1 T: 7.5 H: 84 L: 0 P: 10137 P-NN: 10139 batVoltage: 2.82
2015-01-12_06:03:58 Weather_1 T: 7.5 H: 84 L: 0 P: 10136 P-NN: 10138 batVoltage: 2.82Ist da etwas bekannt, oder ist das "normal" ? Es macht auf jedenfall Probleme beim Plotten.
Gruß Christoph
Kennst Du das Verhalten der "originalen" Homematic Sensoren? Denen ist es völlig wurscht, mit wem sie gepairt sind, die senden auch nach dem Pairen grundsätzlich an Broadcast. Das Thema wurde hier im Forum schon mehrfach diskutiert
Hallo Zusammen,
ist es denn möglich, noch so ein Teil zu bekommen?
Viele Grüße
Christoph
Zitat von: erwin23 am 15 Januar 2015, 10:59:26
Hallo,
mal set CUL1 hmPairSerial UWS45464XX für den Wettersensor durchgeführt.
Es wird nichts im Logfile noch in der fhem.cfg eingetragen,
Hier meine Einstellungen für die Logdateien mit Cul 868 von Busware V1.61
attr global verbose 1
attr global mseclog 1
attr CUL1 verbose 4
Sensor OTAU 0.70
Beste Grüsse erwin23
Geht mit genauso. Ich bekomme kein Pairing mehr hin. Das Log zeigt:
2015-01-16 12:04:28 CUL_HM CUL_HM_ID_F102_DDE867 D-firmware: 0.12
2015-01-16 12:04:28 CUL_HM CUL_HM_ID_F102_DDE860 D-serialNr: UWS4335040
2015-01-16 12:04:28 CUL_HM CUL_HM_ID_F102_DDE860 R-pairCentral: set_0x229045
2015-01-16 12:04:32 CUL_HM CUL_HM_ID_F102_DDE860 R-pairCentral: 0x229045Das Device wird aber nicht angelegt.
PS-1: Ich versuche gegen eine vccu zu pairen
PS-2: Das Device wird "roh" angelegt, aber mit ? und unter CUL_HM aufgeführt. Die eigentlichen Readings (wie Temperatur, Luftdruck usw.) werden nicht angelegt
2015-01-16 12:04:32 CUL_HM CUL_HM_ID_F102_DDE860 R-pairCentral: 0x229045das bedeutet aber, dass gepairt wurde.
ZitatDas Device wird aber nicht angelegt.
autocreate ist aktiv?
ZitatDas Device wird "roh" angelegt, aber mit ? und unter CUL_HM aufgeführt.
poste ein list vom device.
Zitat von: erwin23 am 15 Januar 2015, 19:34:03
Bin mal gespannt auf deine Version.
Anbei ein Link mit einem kompletten FHEM incl. HMConfig_SenTHPL.pm zum Testen:
https://www.dropbox.com/s/54khvb8h5op6vgt/FHEM-Test.tgz?dl=0
Das FHEM ist frisch aus dem SVN von vorhin. Ein Sensor habe ich vorhin per Autocreate anlegen lassen.
einfach in einem Ordner entpacken und so starten:
sudo ./fhem.pl ./fhem.cfgDieses FHEM ist so konfiguriert, das es "interaktiv" läuft.
Alle Logausgaben werden in der Konsole angezeigt
Als Interface habe ich mit einem ein CUL an /dev/ttyACM0@9600 getestet
Wenn das FHEM läuft dann einfach die Config-Taste vom Sensor drücken. Dann muss dieser per Autocreate angelegt werden. Ggf. den Event-Monitor beobachten.
Der Sensor befindet sich dann im "Raum" CUL_HM.
Es sind dann ggf. noch keine Sensordaten zu sehen. Diese werden erst mit dem nächsten Sendezyklus vom Sensor übertragen. Also nach ca. 2-3 Min. Wenn man nicht so lange warten möchte, den Sensor kurz stromlos machen, die Config-Taste drücken (damit werden die Kondensatoren entladen) und die Batterien wieder einsetzen. Nach dem Einsetzen der Batterien und dem "Booten" des Sensors sendet dieser direkt ein erstes Datenpaket.
Zitat von: betateilchen am 15 Januar 2015, 16:43:22
Eigentlich braucht man den Sensor überhaupt nicht zu pairen.
Das braucht man nur wenn man den Sensor konfigurieren möchte.
Zitat von: CQuadrat am 16 Januar 2015, 10:00:43
ist es denn möglich, noch so ein Teil zu bekommen?
Ja. Ich habe noch Teile da.
Einfach kurze PM an mich.
Viele Grüße
Dirk
Hallo allerseits,
ich bin auf der Suche nach einem Feuchtesensor für das Bad. Ich würde ihn gerne wired an HM anschliessen. Ist das mit dem hier bearbeiteten Teil auch möglich? Gibt es irgendwo eine Zusammenfassung über den technischen Stand?
Gruß
Wolfgang
Hallo Wolfgang,
Die Hardware des Sensors unterstützt schon eine Wired-Anbingung per RS485.
Allerdings ist die Firmware dafür noch fertig.
Es existiert eine experimentelle Firmware worüber die Temperatur an den Sensor angeschlossener 1-Wire Sensoren per HM-Wired übertragen werden.
Zitat von: Kruemel am 17 Januar 2015, 11:44:12
Gibt es irgendwo eine Zusammenfassung über den technischen Stand?
http://www.fhemwiki.de/wiki/Universalsensor
Gruß
Dirk
Hallo Dirk,
danke für die Info. Ich hatte den Link zu Universalsensor schon gesehen, konnte aber nicht einschätzen wie aktuell er ist.
Da ich hier gerade mein Badezimmer umbaue werde ich mir schon mal Kabel legen um später noch auf wired wechseln zu können. Im Moment könnte ich die Feuchte erst einmal mit einem vorhandenen HM-TC-IT-WM-W-EU messen. Ich hab noch einen liegen.
Wegen dem wired-Anschluss habe ich noch ein paar Anfängerfragen: Wieviele Adern braucht man für einen Meßfühler? Gelesen habe ich: 2. Ist das ok? Gibt es eine max. Leitungslänge vom Meßfühler zur Sensorelektronik? Gibt es sonst noch etwas worauf ich bei der Leitung achten müßte?
Gruß
Wolfgang
Zitat von: Dirk am 16 Januar 2015, 23:42:29
Anbei ein Link mit einem kompletten FHEM incl. HMConfig_SenTHPL.pm zum Testen:
https://www.dropbox.com/s/54khvb8h5op6vgt/FHEM-Test.tgz?dl=0
Das FHEM ist frisch aus dem SVN von vorhin. Ein Sensor habe ich vorhin per Autocreate anlegen lassen.
Mit deinem Test-Image werden meine Sensoren angelegt, so wie es sein soll :). Nur mit meiner fhem-Installation (V5.6.deb + Update) geht es nicht.
Viele Grüße
Frank
Zitat von: Bastel-Frank am 17 Januar 2015, 18:53:41
Mit deinem Test-Image werden meine Sensoren angelegt, so wie es sein soll :).
Leider doch nicht so ganz: Beim ersten Anlernen geht alles. Wenn man den Sensor ablernt und erneut anlernen möchte, wird das Device nicht angelegt. Das gleiche Verhalten wie beim aktuellen fhem.Edit:
Sorry, da hat meine normale fhem-Installation quer geschossen: Es geht mit dem Test-Image wohl, d.h. auch das erneute Anlernen funktioniert.
Hallo,
versuch mal auf der Testumgebung die fhem.save zu löschen und dann neu zu pairen. Nur so ein dummer Gedanke - es könnte sein, das die Readings dort schon eingetragen sind und deshalb beim erneuten pairen am Device nicht angelegt werden.
Gruß Christoph
Zitat von: Kruemel am 17 Januar 2015, 16:07:14
Wegen dem wired-Anschluss habe ich noch ein paar Anfängerfragen: Wieviele Adern braucht man für einen Meßfühler? Gelesen habe ich: 2. Ist das ok? Gibt es eine max. Leitungslänge vom Meßfühler zur Sensorelektronik? Gibt es sonst noch etwas worauf ich bei der Leitung achten müßte?
Wenn der Sensor per RS485 also HM-Wired angeschlossen werden soll, dann sind es 4 Adern.
2 mal Spannungsversorgung (24V und Masse) und 2 differenzielle Datenleitungen.
Zitat von: Bastel-Frank am 17 Januar 2015, 18:53:41
Mit deinem Test-Image werden meine Sensoren angelegt, so wie es sein soll :). Nur mit meiner fhem-Installation (V5.6.deb + Update) geht es nicht.
Schau mal ob die HMConfig_SenTHPL.pm aus der Testumgebung und deiner Umbegung identisch sind.
Gruß
Dirk
Hallo Dirk,
deine Hinweis:
Zitat von: Dirk am 18 Januar 2015, 19:43:27
Schau mal ob die HMConfig_SenTHPL.pm aus der Testumgebung und deiner Umbegung identisch sind.
hat mich dann auf die Spur gebracht: Ich hatte vergessen, die HMConfig_SenTHPL.pm in das neue Produktiv-System zu kopieren 8). Nachdem ich gemacht habe, klappt auch das erneute Pairing wieder. Vielen Dank mal wieder für deinen Support.
Frank
ich möchte hier wieder einmal eine Statusmeldung zu meinem Außensensor machen, was die Batterie betrifft.
Ich hatte es mir ja extra aufgeschrieben, damit ich mal ganz genau schreiben kann wie lange die Batterie tatsächlich hält.
Also hier mein Logauszug und gut zu sehen der Sensor hat sich gestern Nacht verabschiedet:
2015-01-25_00:30:16 Aussensensor_Terrasse Activity: unknown
2015-01-25_00:28:20 Aussensensor_Terrasse Activity: unknown
2015-01-24_03:45:49 Aussensensor_Terrasse Activity: dead
2015-01-24_03:28:09 Aussensensor_Terrasse T: 0.9 L: 0 P: 1016.7 P-NN: 1044.3
2015-01-24_03:28:09 Aussensensor_Terrasse pressure-nn: 1044.3
2015-01-24_03:28:09 Aussensensor_Terrasse pressure: 1016.7
Gewechselt habe ich die Batterie genau am 29.11.2014, dass sind keine 2 Monate. Der Zeitraum ist echt unbefriedigend..!
Wenn ich dann mal meinen Homematic Außensensor vergleiche, solange wie ich den besitze (schätze ca. 9 Monate) habe ich noch nie eine Batterie gewechselt.
Zitat von: moonsorrox am 25 Januar 2015, 02:41:50
Gewechselt habe ich die Batterie genau am 29.11.2014, dass sind keine 2 Monate. Der Zeitraum ist echt unbefriedigend..!
Wenn ich dann mal meinen Homematic Außensensor vergleiche, solange wie ich den besitze (schätze ca. 9 Monate) habe ich noch nie eine Batterie gewechselt.
Du hast aber bestimmt den Thread genau verfolgt und weißt daher, dass derzeit ein Bug in der Firmware ist, der die Batterie nach ~2 Monaten plötzlich zum Leersaugen beginnt? ;-)
In deinem Log müsste sich auch gut erkennen lassen, dass die Batterie innerhalb der letzten 24 Stunden plötzlich leer wird.
Dirk weiß Bescheid und einstweilen kannst du dir behelfen, indem du die Batterie nach ca. 1 1/2 Monaten für ca. 3 Sekunden raus nimmst und wieder einsetzt, damit der (wie ich stark annehme) verursachende Zähler zurück gesetzt wird und es somit zu keinem batterieaussaugendem Überlauf kommt.
Zitat von: Mr. P am 25 Januar 2015, 04:09:50
Du hast aber bestimmt den Thread genau verfolgt und weißt daher, dass derzeit ein Bug in der Firmware ist, der die Batterie nach ~2 Monaten plötzlich zum Leersaugen beginnt? ;-).
Nein, ich schaue nur sporadisch rein deshalb ist mir dies wohl entgangen..!
Ich werde dieses mit den Batterien mal ausprobieren.
Zitat von: Dirk am 16 Januar 2015, 23:42:29
Ja. Ich habe noch Teile da.
Einfach kurze PM an mich.
Hi Dirk,
kann es sein, dass Du PMs deaktiviert hast? Ich sehe bei mir nichts im Postausgang.
Viele Grüße
Christoph
Zitat von: CQuadrat am 26 Januar 2015, 15:40:09
kann es sein, dass Du PMs deaktiviert hast? Ich sehe bei mir nichts im Postausgang.
Nö, PM funktioniert.
Hab von die auch keine PM gefunden.
Deine Mail ist aber angekommen.
Viele Grüße
Dirk
Hallo,
habe gerade den Außensensor von Dirk erhalten. Gibt es irgendwo eine Anleitung zur inbetriebnahme ?
Pairing hat soweit geklappt aber autocreate hat außer 5 button nichts angelegt. Im log tauchen auch einege Warnungen auf:
2015.01.27 14:08:15 3: CUL_HM set vccu hmPairForSec 60
2015.01.27 14:08:24 2: CUL_HM Unknown device CUL_HM_ID_F102_BA306C is now defined
2015.01.27 14:08:24 2: autocreate: define CUL_HM_ID_F102_BA306C CUL_HM BA306C
2015.01.27 14:08:24 2: autocreate: define FileLog_CUL_HM_ID_F102_BA306C FileLog ./log/CUL_HM_ID_F102_BA306C-%Y.log CUL_HM_ID_F102_BA306C
2015.01.27 14:08:24 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/10_CUL_HM.pm line 4797.
2015.01.27 14:08:24 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 2446.
2015.01.27 14:08:24 3: CUL_HM pair: CUL_HM_ID_F102_BA306C , model unknown serialNr
2015.01.27 14:08:24 3: CUL_HM set CUL_HM_ID_F102_BA306C getConfig
2015.01.27 14:08:28 3: CUL_HM set CUL_HM_ID_F102_BA306C getConfig
2015.01.27 14:10:07 1: PERL WARNING: Use of uninitialized value $regReq in string eq at ./FHEM/10_CUL_HM.pm line 2930.
2015.01.27 14:10:07 1: PERL WARNING: Use of uninitialized value $regName in hash element at ./FHEM/10_CUL_HM.pm line 6007.
2015.01.27 14:10:07 1: PERL WARNING: Use of uninitialized value $addr in numeric lt (<) at ./FHEM/10_CUL_HM.pm line 6020.
2015.01.27 14:11:17 3: CUL_HM set CUL_HM_ID_F102_BA306C getConfig
Gruß Holgi
Damit der Sensor von FHEM erkannt wird, musst du noch die Datei HMConfig_SenTHPL.pm in das Modules-Verzeichniss von FHEM kopieren.
https://github.com/kc-GitHub/Wettersensor/raw/v0.12/Tools/FHEM/HMConfig_SenTHPL.pm
Viele Grüße
Dirk
Danke für die Info. Jetzt geht es. :)
Muß man in das Gehäuse zur Luftdruckmessung noch ein Loch bohren ?
Gruß Holgi
Hallo,
ich habe da viele kleine Löcher drin, alleine schon wegen der Temperturmessung. Ich will ja nicht die Arbeitstemperatur" des Prozessors messen. Die Löcher zeigen nach unten und das Gerät ist unterm Dachüberstand angebracht - also weitestgehend Regengeschützt.
Alternativ, wenn Du nur Luftdruck messen möchtest, kannst Du natürlich auch in der Dichtung eine Akleine Lücke lassen.
Gruß Christoph
Danke für die Info. Werde dann auch mal ein paar löcher bohren.
Wie werden eigentlich die luxwerte berechnet, wenn man die Filterfolie verwendet ?
Denke so ist der angezeigte Wert ja verfälscht oder ?
Gruß Holgi
Die Folie lässt ca. 25% des Lichtes durch.
http://www.fhemwiki.de/wiki/Universalsensor#Der_Helligkeitssensor
Viele Grüße
Dirk
OK, also den angezeigten Wert X4 sollte passen.
Hm, nur wie baut man das am besten in fhem ein ?
Zitat von: The-Holgi am 27 Januar 2015, 17:04:23
Hm, nur wie baut man das am besten in fhem ein ?
Ich habe das über stateFormat realisiert:
{my $l = ReadingsVal($name, 'luminosity', 0); sprintf('Helligkeit: %.2f Lux (%d)<br>Temperatur: %.1f °C<br>Luftdruck: %d hPa<br>Batterie: %.2f V', ($l/0.265), $l, ReadingsVal($name, 'temperature', 0), ReadingsVal($name, 'pressure', 0), ReadingsVal($name, 'batVoltage', 0) );}
Supi, da wäre ich nicht drauf gekommen. Schöner wäre allerdings wenn der korregierte Luftdruckwert angezeigt würde.
Habe mir mal ein DOIF gebastelt, ich möchte damit eine Lampe schalten sobald es dunkel wird. Den genauen luminosity Wert muß ich noch ermitteln aber ansonsten müßte es doch so klappen oder ?
define Licht_Kugel_an doif ([Aussen_Sensor:luminosity:] < 0.70 ) (set FS20_S8_B on) DOELSE (set FS20_S8_B off)
Gruß Holgi
Zitat von: The-Holgi am 27 Januar 2015, 17:34:15
Schöner wäre allerdings wenn der korregierte Luftdruckwert angezeigt würde.
Dann musst du das Reading "pressure-nn" verwenden.
Vorher aber das globale Attribut "altitude" setzen
Gruß
Dirk
Zitat von: Mr. P am 25 Januar 2015, 04:09:50
Dirk weiß Bescheid und einstweilen kannst du dir behelfen, indem du die Batterie nach ca. 1 1/2 Monaten für ca. 3 Sekunden raus nimmst und wieder einsetzt, damit der (wie ich stark annehme) verursachende Zähler zurück gesetzt wird und es somit zu keinem batterieaussaugendem Überlauf kommt.
also heute habe ich nun einmal das beherzigt was du geschrieben hast, aber leider funktioniert das nicht mit dem raus nehmen..!
Die Batterien sind wohl echt "tot"
Habe heute neue eingesetzt und der Sensor startet nun wieder von neuem mit einer Anfangsspannung von 3.07V
Ich schreibe mir das ja jetzt auf um es weiterhin für mich zu kontrollieren.
Letzter Wechsel - 29.11.2014 - 3.03V
heutiger Wechsel - 28.01.2015 - 3.07V
Zitatalso heute habe ich nun einmal das beherzigt was du geschrieben hast, aber leider funktioniert das nicht mit dem raus nehmen..!
rausnehmen
bevor sie tot sind. darum 1.5 monate. du warst 2 wochen zu spät.
Zitat von: frank am 28 Januar 2015, 13:55:32
rausnehmen bevor sie tot sind. darum 1.5 monate. du warst 2 wochen zu spät.
mmh OK ;)
aber ich hoffe das ändert sich mit einer neueren Firmware, denn ich wollte das Ding ja mal an seinem Platz festschrauben, sonst brauche ich jedes mal ne Leiter :-\
Zitat von: frank am 28 Januar 2015, 13:55:32
rausnehmen bevor sie tot sind. darum 1.5 monate. du warst 2 wochen zu spät.
Genau. ;-)
Wenn du dich natürlich per Mail, SMS, usw. über schwache Batterien deiner Komponenten informieren lässt, kannst du auch noch reagieren und sie schnell raus und wieder hinein geben. Aber das sollte dann binnen 1-2 Stunden nach der Info geschehen, bevor die Batterien ganz leer gesaugt sind.
hier mal eine schöne batterie-selbstheilung, ohne rausnehmen der batterie. sehr schön erkennt man auch, dass sofort mit beginn des spgs-abfalls (kurz vor 8.00) temp und feuchte zu vergessen sind. die kurven machen quasi den batterie-kurvenverlauf mit. jetzt ist auch das erste mal eine bat=low meldung gekommen. der schwarze peak unten bei 1.0 volt.
der heilungsbeginn könnte mit dem ausbleiben des lichtwertes (0) zusammenhängen.
(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=26813;image)
gruss frank
Hallo Frank
Ist ziemlich heiß bei dir :-)
Fast 1000 Grad Celsius
Gruß Gerd
Hallo Frank
Ist ziemlich heiß bei dir :-)
Fast 1000 Grad Celsius
Gruß Gerd
Hallo,
gibt's eigentlich schon was neues bzgl Firmware ohne Batterie Bug?
Gruß
Andreas
Hallo,
ich habe mir jetzt auch mal einen solchen Sensor gebaut.
Dann habe ich die Firmware (Hex) geflasht. Soweit schein es zu funktionieren.
Wenn ich nun einen zweiten baue habe, dann habe ich das Problem, dass die Adresse ja schon vergeben ist.
Wie ändert man via Fhem von so einem Sensor die Adresse, so dass man mehrere betreiben kann?
Muss ich dazu den Code selbst kompilieren?
Gruß
Björn
Zitat von: bjoernh am 08 Februar 2015, 19:39:23
Muss ich dazu den Code selbst kompilieren?
Nicht unbedingt. Von Dirk gibt es ein Flash-Script, wo man eine eigene Adresse angeben kann. Ist (glaube ich) im Wiki beschrieben.
Zitat von: hexenmeister am 08 Februar 2015, 19:45:38
Nicht unbedingt. Von Dirk gibt es ein Flash-Script, wo man eine eigene Adresse angeben kann. Ist (glaube ich) im Wiki beschrieben.
Mhh, ok. ich finde das Flash-Skript leider nicht. Weder im github noch im Wiki ist etwas zu finden. Im Wiki steht zwar, dass es eines gibt, aber wo ist die große Frage.
Man mag mich korrigieren, aber wenn ich mich recht erinnere, ist das Flash-Skript nicht im master enthalten im Moment. Sollte aber noch in einem anderen Branch/Tag zu finden sein.
Zitat von: vbs am 08 Februar 2015, 20:21:16
Man mag mich korrigieren, aber wenn ich mich recht erinnere, ist das Flash-Skript nicht im master enthalten im Moment. Sollte aber noch in einem anderen Branch/Tag zu finden sein.
Hab's gefunden, danke. Es ist im Tag v0.10 enthalten.
Hallo
Zitatrausnehmen bevor sie tot sind. darum 1.5 monate. du warst 2 wochen zu spät.
Mist. Jetzt hab ich's auch übersehn und tot ist er seit zwei Tagen.
Könnte es sein, daß es ein Pufferüberlauf von den millis() Aufrufen in Sensor_SHT10_BMP085_TSL2561.cpp ist? Dieser Timer läuft ja ca 50 Tage und fängt dann wieder bei 0 an. 50 Tage würden ja passen.
http://www.forward.com.au/pfod/ArduinoProgramming/TimingDelaysInArduino.html (http://www.forward.com.au/pfod/ArduinoProgramming/TimingDelaysInArduino.html)
Grüße Harald
Hallo Zusammen.
ich will mal wieder ein kleines "Lebenszeichen" senden.
Zitat von: knochenmuehle am 08 Februar 2015, 19:38:42
Hallo,
gibt's eigentlich schon was neues bzgl Firmware ohne Batterie Bug?
Da bin ich dran.
Wird aber noch etwas dauern.
Zitat von: bjoernh am 08 Februar 2015, 20:05:41
Mhh, ok. ich finde das Flash-Skript leider nicht. Weder im github noch im Wiki ist etwas zu finden. Im Wiki steht zwar, dass es eines gibt, aber wo ist die große Frage.
Der Bootloader ist inzwischen ein eigenes Projekt.
Das Flashtool dafür ist hier:
https://github.com/jabdoa2/Asksin_OTA_Bootloader/tree/master/Tools/Flash-Tool-Windows
Viele Grüße
Dirk
Zitat von: honk am 10 Februar 2015, 23:34:01
Könnte es sein, daß es ein Pufferüberlauf von den millis() Aufrufen in Sensor_SHT10_BMP085_TSL2561.cpp ist? Dieser Timer läuft ja ca 50 Tage und fängt dann wieder bei 0 an. 50 Tage würden ja passen.
Ich hab mir eben mal den AskSin Code angeschaut und da haben leider so ziemlich alle Zeit-Vergleiche ein Problem. Einen Timer wie millis() darf man nur mit Differenzen benutzen, dann heben sich die Fehler bei einem Überlauf auf. Wilkürliches Beispiel aus AskSinMain.cpp:
if((send.counter <= send.retries) && (send.timer <= mils)) { // not all sends done and timing is OK
[...]
send.timer = mils + dParm.timeOut;
}Angenommen
Mils = 0xffffff00
dParm.timeOut = 0x200
Dann ist send.timer beim nächsten Durchlauf 0x00000100 und damit jetzt schon kleiner Mils obwohl das erst in 200ms sein sollte! Man müsste den Vergleich jetzt z.B. so umschreiben:
if ((send.counter <= send.retries) && ((long)(mils - send.timer) >= 0) {
[...]
send.timer = mils + dParm.timeOut;
}Mit obigen Werten rechnet sich dass dann so:
mils send.timer Ergebnis
0xffffff00 - 0x00000100 = 0xFFFFFE00 Korrekt < 0
0x00000000 - 0x00000100 = 0xFFFFFF00 Korrekt < 0
0x00000100 - 0x00000100 = 0x00000000 Korrekt == 0
0x00000101 - 0x00000100 = 0x00000001 Korrekt > 0Aber ganz ehrlich, da krieg teilweise selbst ich ein Knoten im Hirn und ich bin seit 20 Jahren hauptberuflich Bit-Schupser. Und so genau müsste man jede einzelne Stelle dann betrachten. Sollte es keine akute Platz-Probleme im Flash geben (weiß ich gerade nicht) würde ich eher einfach auf 64-bit Arithmetik gehen, die Umstellung lässt sich recht trivial machen und ist dann für 200 Billionen Jahre oder so sicher ;-)
Zitat von: MarcelK am 11 Februar 2015, 23:01:37
Ich hab mir eben mal den AskSin Code angeschaut und da haben leider so ziemlich alle Zeit-Vergleiche ein Problem. Einen Timer wie millis() darf man nur mit Differenzen benutzen, dann heben sich die Fehler bei einem Überlauf auf. Wilkürliches Beispiel aus AskSinMain.cpp:
Ja, das hat Trillu in der neuen Lib auch korrigiert.
Und daher mirgiere ich die FW grade auch auf die neue Lib.
Wobei als schnellen Workaround hatte ich schon überlegt den Sensor nach x Tagen einfach einfach per Watchdog zu resetten.
Nicht schön. Aber würde erst mal helfen.Nein. war nur so eine Idee.
Gruß
Dirk
Zitat von: Dirk am 11 Februar 2015, 23:08:00
Ja, das hat Trillu in der neuen Lib auch korrigiert.
Und daher mirgiere ich die FW grade auch auf die neue Lib.
Super, das hatte ich schon gehofft dass das in NewAskSin jetzt besser ist, aber noch nicht selbst gecheckt. In 2 Wochen gibt's nen Monat Elternzeit, hoffentlich schaff ich dann auch endlich mal selbst damit in der Praxis rumzuspielen :-)
Viele Grüße, Marcel
Weiter vorne hat mal jemand gefragt, wie man die LED abschalten kann. Leider gab es keine Antwort. Meine Ideen wären: LED zerstören oder LED auslöten oder LED mit Lötzinn überbrücken. Was würde denn funktionieren, ohne den Sensor zu zerstören?
ZitatMeine Ideen wären: LED zerstören ...
Die arme LED :)
Du kannst auch die Beta-Firmware 0.13 auf den Sensor Flashen.
Da kann man die LED per Register ausschalten.
https://github.com/kc-GitHub/Wettersensor/blob/master/Firmware-Release/HB-UW-Sen-THPL_update_V0_13_000_141006.eq3
Bitte dann auch das passende pm-file benutzen:
https://github.com/kc-GitHub/Wettersensor/blob/master/Contrib/FHEM/HMConfig_SenTHPL.pm
Gruß
Dirk
Danke für den Tip. Aber erst bekomme ich "notInBootloader" und dann "failBlock 1". Irgendwas mag er nicht. Gibt es einen Trick, wie man ihn flasht (per OTA)?
Ich mache es aktuell so: Batterien raus, "set sensor_xxx fwUpdate Datei.eq3", Baterien rein und Config drücken.
Außerdem habe ich noch ein Problem: Wenn der Sensor sendet, so blinkt die LED immer 5x kurz und 1x lang. Habe hier irgendwo gelesen, dass der ACK von FHEM fehlt und man 2x pairen muss, damit es geht. Bei mir ändert sich allerdings nichts.
Das Flashen direkt mit FHEM funktioniert wohl aktuell nicht.
Du musst mit flash-ota flashen.
Siehe hier: http://forum.fhem.de/index.php/topic,33978.msg263398.html#msg263398
Danke, Dirk. Jetzt geht es. Bleibt einzig noch das Problem, dass die Sensoren scheinbar kein ACK aus FHEM bekommen und ihre Daten 5x schicken. Die LED leuchtet immer 5x kurz und 1x lang. Lässt sich das auch noch beheben?
Ich dokumentiere das alles parallel im Wiki.
Hallo,
also irgendwie stelle ich mich glaube so doof an.
Ich bekomme den Sensor einfach nicht richtig mit einer eigene Seriennummer zum laufen.
Folgendes habe ich jetzt probiert.
Auf den Sensor den OTA Bootloader mit usbasp gebrannt (von hier: https://github.com/jabdoa2/Asksin_OTA_Bootloader/)
Danach startet der Sensor in einer Bootloop:
AskSin OTA Bootloader V0.7.0
TX bootloader sequence
Wait for CB msg
Timeout
CRC fail, RebootSo weit kann ich es ja auch noch verstehen, schließlich ist ja keine Firmware drauf.
Anschließend habe ich hmcfgusb kompiliert und mit folgendem Kommando via meinem CUL Probiert die Firmware zu laden:
./flash-ota -c /dev/ttyUSB1 -f ../../Downloads/Wettersensor-master/Firmware-Release/HB-UW-Sen-THPL_update_V0_13_000_141006.eq3 -s KEQ0000001Aber es passiert nichts. Folgende Ausgaben kommen noch beim hmcfgusb:
HomeMatic OTA flasher version 0.097-git
Reading firmware from ../../Downloads/Wettersensor-master/Firmware-Release/HB-UW-Sen-THPL_update_V0_13_000_141006.eq3...
Firmware with 225 blocks successfully read.
Opening culfw-device at path /dev/ttyUSB1 with speed 38400
Requesting firmware-version
Unknown response from CUL: ? (`V is unknown) Use one of B C F i A Z E G M K U Y R T V W X e f l t x
culfw-device firmware version: 1.63
Entering 10k-mode
Waiting for device with serial KEQ0000001Dies sieht doch auch noch vernünfig aus.
Was ich mir vorstellen könnte, dass die Seriennummer nicht stimmt. Im Readme vom Bootloader steht
ZitatAs SERIAL_NUMBER, set your desired number in the header of bootloader.c. Defaults to KEQ0000001
Leider gibt es diese Einstellung nicht mehr in der bootloader,c Datei.
Kann mir mal bitte einer auf die Sprünge helfen?
Gruß
Björn
Hallo,
jetzt habe ich noch eine Frage.
Wie bekommt Ihr eigentlich den Sketch kompiliert?
Zum einen sind die Fehler mit den header-Dateien, sowie die fehlenden const enthalten.
Dann ist mir noch aufgefallen, dass in der AskSinMain.c die Baudrate der Seriellen Schnittstelle erneut gesetzt wird. Dies macht Probleme, bzw bringt sogar die Kommunikation zum stehen.
Wenn ich nun alle diese Fehler raus habe, stehe ich vor dem nächsten Problem.
Irgendwie funkt er nicht.
Meine Log-Ausgaben sind irgendwie verdreht:
(1624)
14 00 A2 70 FF FF FF 00 00 00 81 18 24 00 00 00 64 00 C8 04 1E (l:21)<- (167947)
14 01 A2 70 FF FF FF 00 00 00 81 1B 23 00 00 00 64 00 C8 04 3D (l:21)<-
Eigentlich müsste es aber so aussehen:
<- 14 00 A2 70 FF FF FF 00 00 00 81 16 23 00 00 00 64 00 C8 04 18 (l:21)(1574)
<- 14 01 A2 70 FF FF FF 00 00 00 81 13 20 00 00 00 64 00 C8 04 31 (l:21)(167925)
Irgendeine Idee, bzw einen Tipp wie man den Sketch richtig kompiliert?
Gruß
Björn
Hi Björn,
welche Code-Version versuchst du zu kompilieren?
Ich meine mit der Arduino-IDE gab es ein paar fehlende Includes. Such mal hier im Tread.
Eigentlich kann man da gar nicht von IDE reden. Daher Entwickle und Kompiliere ich mit Eclipse und dem Arduino-Plugin. Dort gibt es keine Fehler beim Kompilieren.
Bei der neuen Version werde ich auch darauf achten dass es mit der Arduino-SW ohne Fehler kompiliert.
Gruß
Dirk
Hallo Dirk,
ich habe es mit der 1.0er und der 1.5er probiert. Beide gehen nicht.
Source habe ich den Master vom Wettersensor sowie den referenzierten AskSin probiert.
Ich habe aber auch schon den AskSin auf den master angehoben.
Kannst Du mir vielleicht mal dein Eclipse Projekt zur Verfügung stellen?
Ich Doktor jetzt schon den ganzen Tag rum, aber irgendwie bewege ich mich im Kreis.
Bei den verkurksten Ausgaben bin ich auch etwas schauer.
Wenn z.B. folgendes drann steht:
Serial << F("1") << F("2") << F("3") << pTime();
Dann kommt: (56654) 123 raus.
Warum dies so ist, ist eigentlich logisch: An die Serial soll ja 123 + pTime gesendet werden. pTime hat aber eine eigene Serial Variable, welche dann mit der ersten im Konflikt steht.
Gruß
Björn
Hallo,
das ist doch echt zum doof.
Nun habe ich mit das Projekt in Eclipse angelegt. Includepfade gesetzt..
Nun kommt so ein Fehler:
In file included from ../WetterSensor.ino:3:0,
from ../.ino.cpp:21:
../Register.h:118:14: error: redefinition of 'HM::s_dtRegs dtRegs'
HM::s_dtRegs dtRegs = {
^
Was macht denn hier das doofe Eclipse plugin bzw. das Arduino.
Mir scheint es so, dass Arduino die ino Datei in eine .ino.cpp Datei wandelt.
Gruß
Björn
Ich habe vorhin mein Eclipse geupdatet und damit auch das Plugin.
Das hätte ich mal lieber nicht gemacht. Ich bekomme den Fehler aktuell auch :(
Der Kompiliert nicht mal mehr ein nacktes neues Arduino-Sketch mit einer Beispiel-Lib.
Also ein blink Sketch bekomme ich schon kompiliert.
Hast Du unter Filetypes das *.ino und *.pde als cpp und c eingetragen?
So, ich habs wieder zum laufen bekommen.
Ich habe jetzt das das aktuelle Plugin und dort Arduino 1.6.0 eingetragen.
füge mal bitte am Anfang der register.h nach der Zeile "#include <AskSinMain.h>" folgendes ein:
#ifndef _REGISTER_h
#define _REGISTER_h
am Ende dann noch ein
#endif
Wenn das klappt, aktualisiere ich das dann auch im Git
Zitat von: bjoernh am 23 Februar 2015, 17:53:58
Hast Du unter Filetypes das *.ino und *.pde als cpp und c eingetragen?
.ino und .cpp stehen hier als C++ Source File
.c steht als C Source File
.pde ist hier nicht eingetragen.
Gruß
Dirk
Das mit dem define passt so.
Kannst Du mir mal bitte dein Projekt exportieren, irgendwas stimmt bei mir in der Reihenfolge immer noch nicht. Jetzt bekomme ich nämlich Linkfehler :'(
Dann probier das mal.
https://www.dropbox.com/s/tubah9tjnqvbnf6/WetterSensor-Eclipse.zip?dl=0
Nimm aber doch lieber die 1.5.2er Version der Arduino-IDE
Mit dem avr-gcc 4.8.1 hatte ich jetzt auch das Problem dass memory.h nicht gefunden wird, wie schon einige Posts weiter vorne erwähnt wurden.
Gruß
Dirk
Hi Bjoern,
ich habe den Code der Beta im Github aktualisiert.
Das Ganze kompiliert jetzt auch mit der Arduino-IDE 1.6.0 ohne Fehler.
Gruß
Dirk
Hallo Dirk,
schon viel besser... Danke.
Jetzt sag mir mal noch was du für ne Asksin Lib nimmst? Ich muss da immer die memory.h, Include-Fehler (<serial.h>), twi.h, fehlende const usw beheben.
Der Serielle Output ist dann bei mir auch immer noch verdreht.
Was für einen GCC verwendet Du? Ich habe den avr-gcc (GCC) 4.8.2
Ach noch ein Problem, nach dem kompilieren scheint es ja zu laufen, tut es aber leider nicht. Der Sensor sendet keine Daten. Ich denke da passt dann etwas in der AskSin nicht.
Gruß
Björn
ZitatJetzt sag mir mal noch was du für ne Asksin Lib nimmst?
Die Lib ist im Subrepo vom Wettersensor. Oder auch hier:
https://github.com/kc-GitHub/AskSin
Auch nur diese wird damit funktionieren. Da habe ich noch einige Erweiterungen und fixes drinn.
ZitatDer Serielle Output ist dann bei mir auch immer noch verdreht.
Wie meinst du das?
ZitatWas für einen GCC verwendet Du? Ich habe den avr-gcc (GCC) 4.8.2
Bisher hatte ich den gcc aus der Arduino 1.5.2er IDE. Also 4.3.2
Aktuell benutze ich den 4.8.3er gcc aus der Arduino IDE 1.6.0
In dem Zusammenhang habe ich ebend noch einen Bug in der Lib gefixt.
Mit dem 4.8.3er gcc kompiliert, wird der CC1101 nicht mehr richtig initialisiert. Obwohl es keine Kompilerfehler gab.
Somit sendet und empfängt der CC1101 dann nichts, obwohl der Rest funktioniert.
Übrigens der aktuelle Master ist die DEV-Version.
Gruß
Dirk
Hallo Dirk,
funktioniert nun super.
Als Anhang habe ich ein Skript angehängt.
Dieses Skript bereitet die Projektumgebung unter Linux für das Arduino vor.
Vielleicht kannst Du es ja im Wiki, sowie im Repository aufnehmen.
Gruß
Björn
Zitat von: rammelsberg am 03 November 2014, 09:00:36
Hallo!
Sorry, falls ich da in der Sucxhe etwas überlesen haben sollte.
Ich hätte Interesse an dem Außensensor, gibt es die Platine (unbestückt oder bestückt) irgendwo zu bestellen?
Oder das ganze als Bausatz?
Danke!
Viele Grüße...
Darf ich diese Frage nochmal nach vorne hole? Beim Suchen habe ich nichts gefunden und bei 98 Seiten Quer lesen muss ich was überlesen haben. :-(
Hallo Dirk,
Zeile 22 in Register.h
const uint8_t devParam[] PROGMEM = {
sollte in
uint8_t devParam[] = {
geändert werden.
Sonst nimmt er die Einstellungen nicht.
Dann hatte ich noch Probleme mit dem "#define USE_ADRESS_SECTION 0".
Das doofe Arduino erwartet das define in der ino, sonst übernimmt er es nicht :-(
@RettungsTim: Ich habe meinen selber zusammengebaut. Dazu habe ich das cc1101 mit dem Arduino pro mini verheiratet, Sensor drauf und gut ist.. :-)
Ich kann ja mal bei Gelegenheit ein Bild davon machen.
Gruß
Björn
Zitat von: RettungsTim am 27 Februar 2015, 13:38:34
Darf ich diese Frage nochmal nach vorne hole?
Ich schick dir ne PM.
Zitat von: bjoernh am 27 Februar 2015, 14:00:48
Zeile 22 in Register.h
const uint8_t devParam[] PROGMEM = {
sollte in
uint8_t devParam[] = {
geändert werden.
Sonst nimmt er die Einstellungen nicht.
Ah, im else. Stimmt bei mir ist USE_ADRESS_SECTION = 1 daher hab ich das nicht gemerkt :)
ZitatDann hatte ich noch Probleme mit dem "#define USE_ADRESS_SECTION 0".
Das doofe Arduino erwartet das define in der ino, sonst übernimmt er es nicht :-(
Das muss derzeit zusätzlich noch in der AskSinMain.h gesetzt werden.
Gruß
Dirk
@Dirk,
ZitatDarf ich diese Frage nochmal nach vorne hole?
Würdest Du mir auch ein Angebot machen für einen THP?
Danke
Markus
Hi Marcus
Zitat von: blueberry63 am 28 Februar 2015, 12:48:25
Würdest Du mir auch ein Angebot machen für einen THP?
Du hast Post
Viele Grüße
Dirk
Hallo,
wann kann ich mit einer Version rechnen, die nicht mehr alle 2 Monate die Batterien killt ? Gibt es da schon Vortschritte ?
An sonsten bin ich mit den Sensoren super zufrieden.
Gruß Christoph
Neue Firmware 0.14 (Beta)
Hallo Zusammen.
Die letzten Tage habe ich an den Millis() / 49-Tage / Batterie-Bugfix gearbeitet.
Eigentlich sollte diese Version schon auf Basis der neuen Lib erstellt werden. Allerdings ist das doch noch etwas mehr Arbeit wie erwartet.
Daher habe ich die millis() Verarbeitung noch in der alten Lib gefixt.
Ansonsten ist die Funktionalität der Lib identisch mit der Version 0.13
Zusammengefasst sieht der Changelog so aus:
Neue Register (aus Version 0.13)
- transmitTryMax: Sendeversuche des Sensors ohne ACK
- lowBatLimit: Low-Battery Warnschwelle
- ledMode: LED ist beim Senden an oder aus
- altitude: Hier kann die Bezugshöhe für den Luftdruck bereits im Sensor eingestellt werden
Bugfixes:
Der millis()-Überlauf nach ca. 49 Tagen führt nicht mehr dazu das der Sensor nicht mehr in den Sleep-Mode gehen kann. Daher wird die Batterie nach 49 Tagen nicht mehr "Leergesaugt"
kleinere Änderung
Die Batteriespannung wird nur noch mit einer Kommastelle genau gemessen.
Ich hoffe ich bekomme etwas Unterstützung beim Testen.
Wer sich nicht sicher ist kann gerne mit dem Update noch etwas warten bis die ersten hoffentlich positiven Feedbacks zurück kommen.
Falls jemand einmal über den Quellcode schauen möchte würde ich mich auch freuen. Den Millis-Überlauf kann man auch gut testen indem man im .ino-File die entsprechende Zeile einkommentiert.
Der direkte Link zu den Update-Files:
EQ3-Update-File (für z.B. flash-ota)
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Firmware-Release/HB-UW-Sen-THPL_update_V0_14_001_150301.eq3
Hexfile (für den seriellen Bootloader):
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Firmware-Release/HB-UW-Sen-THPL_update_V0_14_001_150301.hex
Firmwareupdatefiles für die CCU:
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Firmware-Release/HB-UW-Sen-THPL_update_V0_14_001_150301-I.tgz
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Firmware-Release/HB-UW-Sen-THPL_update_V0_14_001_150301-O.tgz
Das komplette Packet mit Firmware:
https://github.com/kc-GitHub/Wettersensor/releases/tag/v0.14_beta
Die aktualisierte AskSin-Lib:
https://github.com/kc-GitHub/AskSin/archive/master.zip
Update:
Für diejenigen die von V0.12 updaten: Bitte auch die neue HMConfig_SenTHPL.pm ins FHEM-Verzeichniss kopieren.
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Contrib/FHEM/HMConfig_SenTHPL.pm
CCU-User die von V0.12 updaten müssen das aktuelle CCU-Addon installieren:
https://github.com/kc-GitHub/Wettersensor/raw/master/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon.tgz
Ansonsten sind die neuen Register nicht zu sehen.
Viele Grüße
Dirk
Kanns gerne auf meine beiden draufflashen, komme aber erst Dienstag dazu.
lg, Ici
Zitat von: Dirk am 01 März 2015, 21:45:25
Ich hoffe ich bekomme etwas Unterstützung beim Testen.
Sowieso... Sobald bei mir in der Wohnung nachher etwas Ruhe eingekehrt ist, werde ich die ersten damit flashen!
Thx a lot! :-)
Werde auch mittesten (ich nehmen min 1 indoor und 1 outdoor Sensor), jedoch nicht mehr heute ;)
Hallo zusammen,
ich habe soeben 3 von meinen 4 Sensoren von 0.13 auf die 0.14 geflasht.
Der Außensensor ist dann morgen drann.
Schaun wir mal ......
Gruß
Klaus
erste Info meinerseits nach dem Update:
die Batteriespannung von den drei geflashten Sensoren ist lt. Plott so um ca. 0,2V "gestiegen ???
Gruß
Klaus
Zitat von: dampf123 am 02 März 2015, 00:18:33
die Batteriespannung von den drei geflashten Sensoren ist lt. Plott so um ca. 0,2V "gestiegen ???
Stimmt. Hab ich vergessen zu erwähnen.
Ich habe den Faktor des Spannungsteilers in der Firmware verändert. Bei mir hat der ca. 0,2 V zu wenig angezeigt.
Du kannst ja mal mit einem Multimeter an den Batterien nachmessen.
Hej Dirk,
hab es einmal auf 5 meiner 6 Sensoren eingspielt.
4x die 3er-Variante und 1x die 6er.
Sensoren tun weiterhin so, wie sie es bisher auch getan haben bzw. Spannung ist eben angestiegen. :-)
Beim Einspielen am 6er hab ich allerdings sehr lange gebraucht. Ständig ist die Verbindung abgebrochen. Bin dann durch die ganze Wohnung gelaufen und immer wieder stehen geblieben, bis er irgendwann endlich durchgelaufen ist. Irgendwelche Ideen, warum das Modul mit dem Luftdrucksensor sich "so schwer" getan haben könnte? Empfangswerte im laufenden Betrieb sind jetzt je nach Funkmodul an FHEM zwischen -68 und -80... und beim Flashen war die ursprüngliche Entfernung zur Sendeeinheit ca. 5 Meter (inkl. einer tragenden Wand), hätte also passen müssen.
Eine andere Sache, die noch offen ist (die mWn schon irgendwo auf deiner Todo-Liste steht): Hast du schon eine Idee, wie die Syncproblematik bei gepeerten Thermostaten in den Griff zu bekommen ist? Zur Zeit sind sie die meiste Zeit out-of-sync (und finden sich dann immer wieder für kurze Zeit über den Tag verteilt).
Ich werd mal weiter beobachten!
Vielen Dank dafür! :-)
Hi Mr. P
Zitat von: Mr. P am 02 März 2015, 13:42:51
Beim Einspielen am 6er hab ich allerdings sehr lange gebraucht. Ständig ist die Verbindung abgebrochen. Bin dann durch die ganze Wohnung gelaufen und immer wieder stehen geblieben, bis er irgendwann endlich durchgelaufen ist. Irgendwelche Ideen, warum das Modul mit dem Luftdrucksensor sich "so schwer" getan haben könnte?
Welche Bootloaderversion hast du da drauf? Der Bootloader vor V0.7 war noch etwas buggy. Daran könnte es gelegen haben.
ZitatEine andere Sache, die noch offen ist (die mWn schon irgendwo auf deiner Todo-Liste steht): Hast du schon eine Idee, wie die Syncproblematik bei gepeerten Thermostaten in den Griff zu bekommen ist? Zur Zeit sind sie die meiste Zeit out-of-sync (und finden sich dann immer wieder für kurze Zeit über den Tag verteilt).
Das werde ich als nächstes angehen.
Viele Grüße
Dirk
Zitat von: Dirk am 02 März 2015, 14:13:49
Welche Bootloaderversion hast du da drauf? Der Bootloader vor V0.7 war noch etwas buggy. Daran könnte es gelegen haben.
Hab den besagten Sensor erst letzte Woche von dir bekommen. Steht auch am Sticker, dass die Version v0.7 drauf ist.
Zitat von: Dirk am 02 März 2015, 14:13:49
Das werde ich als nächstes angehen.
Super, danke! Hab hier 4 Stück mit den Thermostaten gepeert und stehe für div. Tests zur Verfügung! ;-)
4 Sensoren aktualisiert. Bis jetzt nichts auffälliges. 6 sind morgen dran.
2 Sensoren soeben aktualisiert, hat ohne Probleme funktioniert, laufen einwandfrei.
lg, Ici
ZitatStändig ist die Verbindung abgebrochen. Bin dann durch die ganze Wohnung gelaufen und immer wieder stehen geblieben, bis er irgendwann endlich durchgelaufen ist. Irgendwelche Ideen, warum das Modul mit dem Luftdrucksensor sich "so schwer" getan haben könnte? Empfangswerte im laufenden Betrieb sind jetzt je nach Funkmodul an FHEM zwischen -68 und -80... und beim Flashen war die ursprüngliche Entfernung zur Sendeeinheit ca. 5 Meter (inkl. einer tragenden Wand), hätte also passen müssen.
bei einem hatte ich auch schwierigkeiten mit abbrüchen. bei mir waren fast leere batterien das problem. die übertragung ist immer gestartet, und dann abgebrochen. mit neuen gebrauchten batterien klappte es dann sofort.
ich habe die sensoren immer mit den gebrauchten "lowBat"-batterien meiner hm-cc-tc versorgt. aus den letzten wochen hatten sich einige batterien angesammelt, die ich nun in die v0.14 eingelegt habe. ich habe den eindruck, dass die v0.14 mehr energie benötigt als v0.13. in 2 tagen habe ich bereits 2-3 gebrauchte sätze austauschen müssen. sonst haben die noch über wochen gehalten. ist aber bisher nur so ein gefühl.
(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=28544;image)
in diesem plot kann man es eigentlich gut erkennen. bis gestern nachmittag nahezu konstant bei 1.97 volt. dann das update mit dem sprung von +0.2 volt. anschliessend geht es rapide bergab. heute nacht dann der ausfall, bis ich vorhin erneut gebrauchte batterien eingelegt habe. auch diese zeigen einen erheblichen abfall und werden sicherlich bald aufgeben.
(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=28546;image)
hier der plot vom 2. sensor. erster spannungsabfall durch fw-update. später mit neuen gebrauchten batterien dann erfolgreiches update. hier ist der 0.2v sprung nicht zu sehen, da der batteriewechsel mit dem update erfolgt ist. danach rapider spannungsabfall und ausfall des sensors nach wenigen stunden. anschliessend ein weiterer batteriewechsel mit wiederum deutlichem spannungsabfall. auch hier erwarte ich in kürze einen erneuten batteriewechsel.
es macht mir den eindruck, als würde mit der v0.14 gar kein sleepmode mehr ausgeführt.
gruss frank
Hej frank,
ist vielleicht kein schlechter Hinweis mit den Batterien. Wobei ich vor der Tortour eine Spannung von 2,1V übermittelt bekommen habe. Als ich dann nach zig Durchgängen fertig war, bekam ich nur noch 1,5V mitgeteilt, welche sich dann aber nach einigen Minuten wieder auf 2,2V erholt hatte. Da es trotzdem einen massiven Einbruch gegeben hat, könnten vielleicht doch die Batterien daran schuld sein - werde ich auf alle Fälle im Hinterkopf behalten. :-)
Den Energie-Hunger der neuen Firmware kann ich allerdings bei keinem meiner Sensoren nachvollziehen. Selbst der Problemsensor teilt mir nach mittlerweile 36 Stunden Laufzeit immer noch kontant 2,2V mit jeder Übertragung mit. Vielleicht wirklich nur ein blöder Zufall und jeweils eine Batterie dabei, die einfach schon EOL ist?
Hallo zusammen,
da die Tage mein Aussensensor mal wieder LowBatterie angezeigt hat, dachte ich mir schaue ich dich hier mal kurz rein, inwiefern sich hier etwas getan hat.
Und siehe da. In der 0.14er FW scheint sich ja auch bzgl dem "Problem" etwas getan.
Nun würde ich gerne meinen Aussensensor (Temp, Luftdruck, Helligkeit, MAX1724) und den Innensensor (Temp, Luftfeuchte, MAX1724) auch die neue FW spendieren.
Allerdings weiss ich nun aber ehrlich gesagt nicht wirklich, wie ich mich dazu anstellen muss.
Mein Equipment besteht noch aus einem USB-UART-Adapter. Mein FHEM läuft mit einem HM-LAN Adapter, aber einen HM-USB-CFG2 habe ich mir mal irgendwann gegönnt und der liegt noch in der Ecke rum.
Leider werde ich nicht wirklich schlau, wie ich nun auf der grünen Wiese anfange, um die FW auf die Sensoren zu bekommen.
Das Posting ist ja auch schon etwas umfangreicher.
Stellt sich hier schon der erste Frage ob ich hier sogar noch löten muss? Ich meine hier mal so was gelesen zu haben.
Cool wäre, wenn einer quasi ein Kochrezept bereitstellen könnte, wie ich in einer Apple Umgebung die Sensoren aktualisiert bzw geflasht bekomme. :)
Wobei einen Windowsrechner könnte ich auch noch aus der Ecke holen, wenn es notwendig sein sollte bzw es damit einfacher geht.
Sollte das mit dem Kochrezept für einen Profi einfach sein, so wäre das vielleicht ein Ansatz, so was im Wiki zu veröffentlichen, damit auch andere davon partizipieren könnten.
ZitatWobei einen Windowsrechner könnte ich auch noch aus der Ecke holen, wenn es notwendig sein sollte bzw es damit einfacher geht.
wenn du einen ota-bootloader drauf hast, kannst du mit hmusb und dem fw-update-tool von eq3 das update mit dem eq3-file machen. tool mit sn und file starten. dann batterie raus, button drücken und gleichzeitig batterie rein. gedrückt halten bis led regelmässig blinkt.
Zitat von: frank am 03 März 2015, 12:42:35
wenn du einen ota-bootloader drauf hast, kannst du mit hmusb und dem fw-update-tool von eq3 das update mit dem eq3-file machen. tool mit sn und file starten. dann batterie raus, button drücken und gleichzeitig batterie rein. gedrückt halten bis led regelmässig blinkt.
Dirk hat mir damals einen seriellen Bootloader installiert. Das ist der OTA-Bootloader?
Wenn nein, wie stelle ich das fest, ob da der ota-bootloader drauf ist?
Zitat von: maxritti am 03 März 2015, 12:48:16
Dirk hat mir damals einen seriellen Bootloader installiert. Das ist der OTA-Bootloader?
Wenn nein, wie stelle ich das fest, ob da der ota-bootloader drauf ist?
Kann ich mir dann wohl doch selber beantworten. 8)
seriell != OTA (over the air)
Stellt sich also die Frage, wie ich feststellen kann, ob der auf den Sensoren drauf ist?
Zitat von: maxritti am 03 März 2015, 12:52:57
Stellt sich also die Frage, wie ich feststellen kann, ob der auf den Sensoren drauf ist?
Wenn du einen OTAU-Bootloader hast, sollte das auf dem Seriennummeraufkleber mit drauf stehen.
Zum Flashen mit dem Seriellen Bootloader kannst du avrdude benutzen.
Wenn du den noch nicht hast, installier dir am besten die Arduino-IDE. Die gibt es auch für Mac.
Das Flashen der Firmware über den Seriellen Bootloader funktioniert dann so:
/path/to/arduino-ide/hardware/tools/avr/bin/avrdude -C/path/to/arduino-ide/hardware/tools/avr/etc/avrdude.conf -patmega328p -carduino -P/dev/ttyUSB0 -b57600 -D -Uflash:w:U:/Path/to/HB-UW-Sen-THPL_update_V0_14_001_150301.hex:i
Die Pfade und den Com-Port (hier /dev/ttyUSB0) musst du noch anpassen.
Die Verkabelung sieht dann so aus:
Den Sensor so auf den Tisch legen, dass das Batteriefach zu dir zeigt.
Dann sind die ersten 4 Pins der unteren Pinreihe von links nach rechts mit dem USB-Serial-Adapter zu verbunden:
Der Pin 1 ist in diesem Fall ganz inks.
# Sensor USB-UART
1 TX - RX
2 RX - TX
3 Reset - DTR
4 GND - GND
Löten muss man nicht unbedingt. man kann in die 4 Löcher auch eine Pinleiste stecken und diese während des Flashens leicht verkanten.
Gruß
Dirk
Okay, ich schaue dann heute Abend mal auf die Aufkleber.
Melde mich dann oder probiere mal, ob ich den Innensensor einen einen undefinierten Zustand bekomme ::)
Den Aussensensor lasse ich erst mal so laufen. Denn der steuert meine Rollos aufgrund der Helligkeit.
Wäre unschön, wenn der es nicht mehr tun würde.
Mein Außensensor hat mit der neuen Firmware auch einen Satz neuen Batterien bekommen. Seit dem schwank batVoltage zw. 3.20 und 3.30.
Mir scheint das schon etwas zu hoch für zwei 1,5V Zellen sein.
Zitat von: hexenmeister am 03 März 2015, 14:17:25
Mein Außensensor hat mit der neuen Firmware auch einen Satz neuen Batterien bekommen. Seit dem schwank batVoltage zw. 3.20 und 3.30.
Mir scheint das schon etwas zu hoch für zwei 1,5V Zellen sein.
Das Passt schon. Die Leerlaufspannung von neuen Alkali-Mangan-Zellen liegt bei 1,57 V bis 1,63 V.
http://de.wikipedia.org/wiki/Alkali-Mangan-Zelle#Spannung
Hinzu kommen noch ein paar Rundungsfehler, da ich zum berechnen der Batteriespannung nun keine Gleitkommaoperationen mehr verwende.
Und ein paar mV Messungenauigkeit kommt da bestimmt auch noch dazu.
Wenn du ein Multimeter hast, kannst die Batteriespannung ja mal an den Batterien messen.
Ich kann die gemessene Spannung aber auch wieder um 0,1 V senken :)
Gruß
Dirk
Hi Björn,
Zitat von: bjoernh am 26 Februar 2015, 17:38:02
Der Serielle Output ist dann bei mir auch immer noch verdreht.
Das habe ich nun auch noch gefixt. Jetzt sehen die Debug-Infos auch wieder schöner aus.
Ist im Master drinn.
Gruß
Dirk
hallo dirk,
ich habe mein problem ermittelt.
mein sensor ist tatsächlich nicht in den sleepmodus gegangen. ich hatte jeweils das register burstRx=on. mit dieser einstellung fliessen minimum 50.5mA permanent. bei betätigung der konfigtaste kommen dann noch ca. 2 mA dazu. ausserdem verbleibt der sensor ewig lange im konfigmodus. bei einer messung waren es ca. 2 minuten.
nach setzen von burstRx=off, geht der sensor dann auch in den sleep-modus. dort messe ich einen pulsierenden strom von 26.0uA bis 26.5uA. jetzt wird nur noch beim senden der daten ein strom von 50mA erreicht. mit meinem analogen strommesser kann ich die 50mA natürlich nicht mehr messen, da der impuls so kurz ist, dass die nadel den wert nicht erreichen kann. aber im konfigmodus (ca. 20 sec) werden wieder ca. 52.0mA erreicht.
mit v0.13 gab es dieses verhalten nicht. ich hatte seit erscheinen von v0.13 die register auf burstRx=on eingestellt.
gruss frank
Hi Frank,
Zitat von: frank am 03 März 2015, 16:36:29
mein sensor ist tatsächlich nicht in den sleepmodus gegangen. ich hatte jeweils das register burstRx=on. mit dieser einstellung fliessen minimum 50.5mA permanent.
Ja, Burst ist noch experimentell. Daher sollte das im Produktiven betrieb nicht gesetzt sein.
Es sei denn man muss schnell ein paar Batterien entladen :)
Die 50 mA sind auch von der Spannung abhängig. Bei vollen Batterien sind das nur um die 30 mA. Mit sinkender Batteriespannung steigt der Strom dann.
Zitatmit v0.13 gab es dieses verhalten nicht. ich hatte seit erscheinen von v0.13 die register auf burstRx=on eingestellt.
In der v0.13 hat das Register noch keine Auswirkung gehabt.
Gruß
Dirk
Zitat von: Dirk am 03 März 2015, 13:10:29
Wenn du einen OTAU-Bootloader hast, sollte das auf dem Seriennummeraufkleber mit drauf stehen.
Zum Flashen mit dem Seriellen Bootloader kannst du avrdude benutzen.
Wenn du den noch nicht hast, installier dir am besten die Arduino-IDE. Die gibt es auch für Mac.
Das Flashen der Firmware über den Seriellen Bootloader funktioniert dann so:
/path/to/arduino-ide/hardware/tools/avr/bin/avrdude -C/path/to/arduino-ide/hardware/tools/avr/etc/avrdude.conf -patmega328p -carduino -P/dev/ttyUSB0 -b57600 -D -Uflash:w:U:/Path/to/HB-UW-Sen-THPL_update_V0_14_001_150301.hex:i
Die Pfade und den Com-Port (hier /dev/ttyUSB0) musst du noch anpassen.
Die Verkabelung sieht dann so aus:
Den Sensor so auf den Tisch legen, dass das Batteriefach zu dir zeigt.
Dann sind die ersten 4 Pins der unteren Pinreihe von links nach rechts mit dem USB-Serial-Adapter zu verbunden:
Der Pin 1 ist in diesem Fall ganz inks.
# Sensor USB-UART
1 TX - RX
2 RX - TX
3 Reset - DTR
4 GND - GND
Löten muss man nicht unbedingt. man kann in die 4 Löcher auch eine Pinleiste stecken und diese während des Flashens leicht verkanten.
Gruß
Dirk
Dann sieht es wohl so aus, als wenn bei mir kein OTA drauf ist. Da steht nur neben der Seriennummern bei beiden Serial 0.2.0.
Kann man den OTA noch nachrüsten?
Sorry, wenn ich so doof frage. Aber mit wenig Ahnung von der Materie wird es schwierig :)
Den Weg per serial werde ich mal ausprobieren.
Aber OTA wäre schon schick.
Zitat von: maxritti am 03 März 2015, 16:46:34
Dann sieht es wohl so aus, als wenn bei mir kein OTA drauf ist. Da steht nur neben der Seriennummern bei beiden Serial 0.2.0.
Kann man den OTA noch nachrüsten?
Ja. Wenn du einen ISP hast. Aber auch mit einem Raspberry Pi kann man das machen.
Hier gibt es dazu eine Anleitung:
http://www.lxccu.com/hb-raspberry-bootloader-update
Gruß
Dirk
Einen Rasperry PI habe ich nicht.
Was bedeutete denn ISP wieder? Bestimmt nicht Internet Service Provider? ;)
Zitat von: maxritti am 03 März 2015, 16:52:26
Einen Rasperry PI habe ich nicht.
Was bedeutete denn ISP wieder? Bestimmt nicht Internet Service Provider? ;)
ISP bedeuted In-System-Programmer. Damit lässt sich die Firmware vom Atmega ohne Bootloader aktualisieren bzw. auch den Bootloader selber.
http://de.wikipedia.org/wiki/In-System-Programmierung
Bei Ebay / Amazon gibt es solche ISP's auch für ein paar Euro. Z.B. hier:
http://www.amazon.de/Programmierer-Adapter-3-3V-USBASP-Download-Programm-ISP-AVR/dp/B00AVRHVPO/ref=sr_1_1?ie=UTF8&qid=1425398352
Aber aufpassen das dieser auch 3,3V Unterstützt.
Ansonsten probier das mit dem seriellen Bootloader. Das geht auch ganz gut.
Viele Grüße
Dirk
Zitat von: Dirk am 01 März 2015, 21:45:25
Neue Firmware 0.14 (Beta)
Ich hoffe ich bekomme etwas Unterstützung beim Testen.
Gerne
Zitat von: Dirk am 01 März 2015, 21:45:25
Firmwareupdatefiles für die CCU:
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Firmware-Release/HB-UW-Sen-THPL_update_V0_14_001_150301-I.tgz
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Firmware-Release/HB-UW-Sen-THPL_update_V0_14_001_150301-O.tgz
Hab ich auf der CCU
Zitat von: Dirk am 01 März 2015, 21:45:25
CCU-User die von V0.12 updaten müssen das aktuelle CCU-Addon installieren:
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon.tgz
Das auch.
Allerdings fehlt mir der Knopf in den Einstellungen des Gerätes um die neue Firmware zu installieren.
Auf meinem Sensor ist die FW 1.2 und der OTAO 0.7.0
Gruß,
Alfred
Hi Alfred,
Zitat von: Akwak am 03 März 2015, 18:07:27
Auf meinem Sensor ist die FW 1.2 und der OTAO 0.7.0
Ah. Das war einer der ersten Bugs mit der Firmware-Version.
Das sollte "damals" Version 0.12 sein. Deine CCU denkt also dass die aktuelle Firmware zu alt ist. Und daher zeigt die keinen Update-Button an.
Welchen Sensor hast du. Innen oder Außen?
Dann erstelle ich dir ein Updatefile mit dem das Update klappen sollte.
Gruß
Dirk
Ich hab 2 von jeder Sorte.
Ich hab 2 von jeder Sorte.
Hallo Dirk,
Zitat von: Dirk am 02 März 2015, 00:21:43
Du kannst ja mal mit einem Multimeter an den Batterien nachmessen.
ich habe mal gemessen (mit einem HP3478A) :
| Sensor_1 | Sensor_2 | Sensor_3 | Sensor_aussen |
FileLog | 3,20V | 2,90V | 3,20V | 3,00V |
gemessen | 3,061V | 2,846V | 3,054V | 2,877V |
der Sensor_2 tanzt da etwas aus der "Reihe" ?!
der ist nur so ca. 2% zu hoch, die anderen so ca. 4,5%
(nebenbei gefragt: wie bekommt man einfach Tabellen hier eingefügt ?)
Gruß
Klaus
Zitat von: Akwak am 03 März 2015, 20:45:37
Ich hab 2 von jeder Sorte.
Probier mal die Updatefiles im Anhang.
Wenn alles klappt hast du nach dem Update dann Version 0.14 auf den Sensoren.
Das nächste Mal geht das dann mit den "normalen" Updatefiles.
Gruß
Dirk
Zitat von: Dirk am 03 März 2015, 14:35:58
Das Passt schon. ...
Sicher habe ich einen Multimeter ;)
Und ich muss sagen, Du hast Recht. Es sind 3,2V ;)
Grüße,
Alexander
Hi Klaus,
ein bisschen Bauteiltoleranz ist da auch noch dabei.
Vielleicht werde ich die Berechnung beim nächsten Update um 0,1 V nach unten korrigieren.
Gruß
Dirk
Zitat von: Dirk am 03 März 2015, 21:08:03
Vielleicht werde ich die Berechnung beim nächsten Update um 0,1 V nach unten korrigieren.
Das hört sich gut an.
Somit würde ich im meinem Fall bei ca. 1% Abweichung liegen. Das sollte für so eine Batterie-Spannungsanzeige ja allemal ausreichen.
Bei höher gewünschter Genauigkeit käme man um eine Abgleichmöglichkeit kaum herum. Sei es per Trimmer oder per Software.
Und das halte ich für total überflüssig.
Gruß
Klaus
beim messen der batteriespannung kommt es sicherlich auch darauf an, in welchem "lastfall" gemessen wird. der sensor misst ja bestimmt nicht im leerlauf.
Zitat von: Dirk am 03 März 2015, 20:56:26
Probier mal die Updatefiles im Anhang.
Wenn alles klappt hast du nach dem Update dann Version 0.14 auf den Sensoren.
Das nächste Mal geht das dann mit den "normalen" Updatefiles.
Gruß
Dirk
Hi Dirk,
danke aber es klappt auch damit nicht.
Ich hab die CCU auch einmal neu gestartet. Ohne Erfolg.
Gruß,
Udo
Ah, Also hast du doh die 0.12er Version drauf.
Dann sollte das mit den Normalen Updatefiles funktionieren.
Welche Softwareversion hat denn deine CCU?
Zitat von: Dirk am 03 März 2015, 22:06:44
Welche Softwareversion hat denn deine CCU?
Hallo Dirk,
Es ist die
Aktuelle Firmwareversion: 2.11.9
Gruss,
Udo
Zitat von: Dirk am 03 März 2015, 22:06:44
Welche Softwareversion hat denn deine CCU?
Hallo Dirk,
Es ist die
Aktuelle Firmwareversion: 2.11.9
Gruss,
Alfred
Hallo,
Also ich habe heute meine mit den HM-CFG-USB auf den neuen Stand gebracht, aber die waren auch auf 0.13. Kann es sein, das die Geräte noch einen alten ( < 0.7) OTA Bootloader drauf haben ?
Gruß Christoph
Hi Christoph,
auf dem Aufkleber steht 0.7.0. Ich weiss allerdings auch nicht genau wie die CCU bestimmt ob ein Gerät per OTA zu updaten ist. Nur dann bietet sie die Updatefunktion an.
Ich schätze mal das da "nur" eine xml dahintersteckt, die die Fähigkeiten eines Gerätes beschreibt. Und dann wird die existierende mit der verfügbaren Firmware verglichen und ggf das Update angeboten.
Gruss
Alfred
Zitat von: Akwak am 03 März 2015, 23:10:39
Aktuelle Firmwareversion: 2.11.9
Das könnte evtl. das Problem sein.
Ich hatte meine Tests mit der LXCCU gemacht. Da läuft noch die Version 2.9.12.
Ich werde am Wochenende das mal updaten. Dann kann ich mehr dazu sagen.
Du könntest mir aber mal einen Ausschnitt aus dem Log der CCU schicken.
Im Zeitraum in dem du das Firmwarefile hochlädst und ggf. im Zeitraum wenn du auf die Gerätedetailseite gehst. Vielleicht kann ich da schon was erkennen.
Dann könntest du mir mal die beiden Dateien hb_uw_sen_thpl.xml und hb_uw_sen_thpl_le_v0_11.xml aus /firmware/rftypes schicken. Dann kann ich sehen ob bei der Installation des Addons alles funktioniert hat.
Zitat von: Akwak am 04 März 2015, 08:05:03
Ich schätze mal das da "nur" eine xml dahintersteckt, die die Fähigkeiten eines Gerätes beschreibt.
Ja. So ist es.
Gruß
Dirk
Zitat von: Dirk am 04 März 2015, 09:04:44
Du könntest mir aber mal einen Ausschnitt aus dem Log der CCU schicken.
Im Zeitraum in dem du das Firmwarefile hochlädst und ggf. im Zeitraum wenn du auf die Gerätedetailseite gehst. Vielleicht kann ich da schon was erkennen.
Dann könntest du mir mal die beiden Dateien hb_uw_sen_thpl.xml und hb_uw_sen_thpl_le_v0_11.xml aus /firmware/rftypes schicken. Dann kann ich sehen ob bei der Installation des Addons alles funktioniert hat.
Hallo,
erst einmal Danke für Deine Hilfe!
Ich bin ein Schritt weiter. Beim suchen der Files ist mir aufgefallen, das die hb_uw_sen_thpl_le_v0_11.xml nicht mit im firmware/rftypes Verzeichnis war.
Also habe ich einmal in das Add-On Archiv geguckt und festgestellt, das auf meiner CCU immer noch das alte Add-On installiert war :-( Obwohl ich das neue über die UI eingespielt hatte.
Ich habe dann das Add-On manuell aktualisiert und siehe da, beim Internen Sensor ist der Updatebutton vorhanden. Beim Externen Sensor fehlt der Button aber weiterhin.
Bei dem Versuch das Firmwareupdate einzuspielen, bekam ich immer die Meldung, das der Bootloader nicht gestartet werden konnte. Screenshot)
Das habe ich mehrfach versucht. Nach einem Reload der WebUI stand als Firmware 0.14 dort.
Beim zweiten Innensensor b[/quote]in ich folgendermaßen vorgegangen:
- Sensor in Bootloader gestartet
- Updatebutton gedrückt
- nach ca 40sec Fehlermeldung
- Servicemeldungen angeschaut -> Firmwareupdate steht zur Übertragung bereit
- In Bootloader gestartet
- Update wird durchgeführt
- Seinstellungsdaten stehen danach noch zur Übertragung an also Knopf auf Sensor kurz gedrückt und alles ist ok ;-)
Hier die Logs:
hmserver.log
Mar 4 10:10:47 de.eq3.lib.util.dynamics.GenericFactory INFO [main] @GenericFactory
Mar 4 10:10:48 de.eq3.lib.util.dynamics.GenericFactory INFO [main] creating instance of HMServerConfiguration with no-arg constructor
Mar 4 10:10:48 de.eq3.ccu.server.HMServer INFO [main] Creating instance of HMServer...
Mar 4 10:10:48 de.eq3.ccu.server.HMServer INFO [main] Starting HMServer at 127.0.0.1:9292
Mar 4 10:10:48 de.eq3.ccu.server.HMServer INFO [main] Read Configuration
Mar 4 10:10:55 de.eq3.ccu.server.HMServer INFO [main] Create Bidcos Dispatcher
Mar 4 10:10:57 de.eq3.ccu.server.HMServer INFO [main] InitBidCosCache
Mar 4 10:11:27 de.eq3.ccu.server.HMServer INFO [main] Create groupDefinitionProvider
Mar 4 10:11:39 de.eq3.ccu.server.HMServer INFO [main] Create VirtualDeviceHolder
Mar 4 10:11:39 de.eq3.ccu.server.HMServer INFO [main] Create VirtualDeviceHandlerRega
Mar 4 10:11:39 de.eq3.ccu.server.HMServer INFO [main] Create GroupAdministrationService
Mar 4 10:11:39 de.eq3.ccu.server.HMServer INFO [main] Create GroupDeviceDispatcher
Mar 4 10:11:39 de.eq3.ccu.server.HMServer INFO [main] Create GroupDeviceHandler
Mar 4 10:11:39 de.eq3.ccu.groupdevice.service.GroupDeviceHandler INFO [main] @GroupDeviceHandler - initializing...
Mar 4 10:11:39 de.eq3.ccu.groupdevice.service.GroupDeviceHandler INFO [main] --> created groupDeviceDispatcher (GroupDeviceService to BidCoS (via Dispatcher))
Mar 4 10:11:39 de.eq3.ccu.groupdevice.service.GroupDeviceHandler INFO [main] --> created virtualDeviceHandler (GroupDeviceService to ReGa)
Mar 4 10:11:39 de.eq3.ccu.groupdevice.service.GroupDeviceHandler INFO [main] --> got groupDefinitionProvider
Mar 4 10:11:39 de.eq3.ccu.server.HMServer INFO [main] Create BidCosGroupMemberProvider
Mar 4 10:11:40 de.eq3.ccu.server.HMServer INFO [main] Init groupAdministrationService
Mar 4 10:11:44 de.eq3.ccu.server.HMServer INFO [main] Create RrdDatalogging
Mar 4 10:11:44 de.eq3.ccu.server.HMServer INFO [main] Create MeasurementService
Mar 4 10:11:44 de.eq3.ccu.server.HMServer INFO [main] Init MeasurementService
Mar 4 10:11:46 de.eq3.ccu.server.HMServer INFO [main] Create HTTP Server
Mar 4 10:13:45 de.eq3.ccu.server.HMServer INFO [main] Create BidCos context
Mar 4 10:13:45 de.eq3.ccu.server.HMServer INFO [main] Create group context
Mar 4 10:13:46 de.eq3.ccu.server.HMServer INFO [main] Starting HMServer done
Mar 4 10:15:00 de.eq3.ccu.virtualdevice.service.internal.rega.VirtualDeviceHandlerRega INFO [pool-2-thread-3] (un)registerCallback on VirtualDeviceHandlerRega called from url: xmlrpc_bin://127.0.0.1:1999
Mar 4 10:15:07 de.eq3.ccu.virtualdevice.service.internal.rega.VirtualDeviceHandlerRega INFO [pool-2-thread-3] updateDevicesForClient -> 8 device addresses will be added
Mar 4 10:15:46 de.eq3.ccu.virtualdevice.service.internal.rega.VirtualDeviceHandlerRega INFO [pool-2-thread-3] set ready config of INT0000001
Mar 4 10:15:46 de.eq3.ccu.virtualdevice.service.internal.rega.VirtualDeviceHandlerRega INFO [pool-2-thread-3] set ready config of INT0000002
Mar 4 10:15:47 de.eq3.ccu.virtualdevice.service.internal.rega.VirtualDeviceHandlerRega INFO [pool-2-thread-3] Added InterfaceId: 17103
Mar 4 11:00:46 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [pool-2-thread-21] Error requesting method getLinks: Failure Code: -1
Mar 4 11:02:01 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [pool-2-thread-22] Error requesting method getLinks: Failure Code: -1
Mar 4 11:04:02 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [pool-2-thread-22] Error requesting method getLinks: Failure Code: -1
Mar 4 11:05:56 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [pool-2-thread-22] Error requesting method getLinks: Failure Code: -1
Mar 4 11:31:33 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [pool-2-thread-31] Error requesting method getLinks: Failure Code: -1
Mar 4 11:35:25 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [pool-2-thread-33] Error requesting method getLinks: Failure Code: -1
Messages
Mar 4 10:59:31 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS4665531 didn't start
Mar 4 10:59:40 homematic-ccu2 daemon.info cuxd[252]: INIT 'binary://192.168.168.1:2011' 'CUxD'
Mar 4 11:00:46 homematic-ccu2 user.err rfd: UWS4665531: GetLinks() for channel 1 failed
Mar 4 11:00:46 homematic-ccu2 user.err rfd: XmlRpcClient error calling updateDevice({"BidCos-RF_java","UWS4665531",0}) on http://127.0.0.1:9292/bidcos:
Mar 4 11:00:46 homematic-ccu2 user.err rfd: XmlRpc fault: [faultCode:-321,faultString:"Error requesting method getLinks: Failure Code: -1"]
Mar 4 11:00:47 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS4665531 didn't startMar 4 11:02:01 homematic-ccu2 user.err rfd: UWS4665531: GetLinks() for channel 1 failed
Mar 4 11:02:01 homematic-ccu2 user.err rfd: XmlRpcClient error calling updateDevice({"BidCos-RF_java","UWS4665531",0}) on http://127.0.0.1:9292/bidcos:
Mar 4 11:02:01 homematic-ccu2 user.err rfd: XmlRpc fault: [faultCode:-321,faultString:"Error requesting method getLinks: Failure Code: -1"]
Mar 4 11:02:02 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS4665531 didn't start
Mar 4 11:02:17 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS4665531 didn't start
Mar 4 11:02:23 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS4665531 didn't start
Mar 4 11:02:39 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS4665531 didn't startMar 4 11:02:56 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS4665531 didn't start
Mar 4 11:03:05 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS4665531 didn't startMar 4 11:04:02 homematic-ccu2 user.err rfd: UWS4665531: GetLinks() for channel 1 failed
Mar 4 11:04:02 homematic-ccu2 user.err rfd: XmlRpcClient error calling updateDevice({"BidCos-RF_java","UWS4665531",0}) on http://127.0.0.1:9292/bidcos:
Mar 4 11:04:02 homematic-ccu2 user.err rfd: XmlRpc fault: [faultCode:-321,faultString:"Error requesting method getLinks: Failure Code: -1"]
Mar 4 11:04:04 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS4665531 didn't startMar 4 11:05:13 homematic-ccu2 user.err rfd: (KEQ0102110) CCU2CommController::handleIncomingSerialFrame(): Dropped message, cuz handling of non-response msg is not implemented yet. Payload is:
Mar 4 11:05:56 homematic-ccu2 user.err rfd: UWS4665531: GetLinks() for channel 1 failed
Mar 4 11:05:56 homematic-ccu2 user.err rfd: XmlRpcClient error calling updateDevice({"BidCos-RF_java","UWS4665531",0}) on http://127.0.0.1:9292/bidcos:
Mar 4 11:05:56 homematic-ccu2 user.err rfd: XmlRpc fault: [faultCode:-321,faultString:"Error requesting method getLinks: Failure Code: -1"]
Mar 4 11:05:57 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS4665531 didn't start
Mar 4 11:06:54 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS4665531 didn't start
Mar 4 11:06:54 homematic-ccu2 user.err rfd: Pendingupdate faild!! Bootloader in device UWS4665531 didn't start Mar 4 11:07:36 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Mar 4 11:07:36 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]Mar 4 11:08:25 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Mar 4 11:08:25 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]Mar 4 10:12:07 homematic-ccu2 auth.info sshd[6622]: Accepted password for root from 192.168.168.225 port 49866 ssh2
Mar 4 11:26:14 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 0 0x00 [1] 0 0x00 [2] 0 0x00 [3] 0 0x00 [4] 0 0x00 [../Platform/DOM/iseESPexec.cpp (11622)]Mar 4 11:29:28 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Mar 4 11:29:28 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Mar 4 11:30:13 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Mar 4 11:30:13 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c [../Platform/DOM/iseESPexec.cpp (11622)]
Mar 4 11:30:26 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS6402661 didn't start
Mar 4 11:30:41 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS6402661 didn't start
Mar 4 11:30:41 homematic-ccu2 user.err rfd: Pendingupdate faild!! Bootloader in device UWS6402661 didn't start
Mar 4 11:30:42 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS6402661 didn't start
Mar 4 11:30:42 homematic-ccu2 user.err rfd: Pendingupdate faild!! Bootloader in device UWS6402661 didn't start
Mar 4 11:31:33 homematic-ccu2 user.err rfd: UWS6402661: GetLinks() for channel 1 failed
Mar 4 11:31:33 homematic-ccu2 user.err rfd: XmlRpcClient error calling updateDevice({"BidCos-RF_java","UWS6402661",0}) on http://127.0.0.1:9292/bidcos:
Mar 4 11:31:33 homematic-ccu2 user.err rfd: XmlRpc fault: [faultCode:-321,faultString:"Error requesting method getLinks: Failure Code: -1"]
Mar 4 11:31:35 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS6402661 didn't startMar 4 11:33:07 homematic-ccu2 user.err rfd: Firmware update faild! Bootloader in device UWS6402661 didn't start
Mar 4 11:33:07 homematic-ccu2 user.err rfd: Pendingupdate faild!! Bootloader in device UWS6402661 didn't start
Mar 4 11:35:25 homematic-ccu2 user.err rfd: UWS6402661: GetLinks() for channel 1 failed
Mar 4 11:35:26 homematic-ccu2 user.err rfd: XmlRpcClient error calling updateDevice({"BidCos-RF_java","UWS6402661",0}) on http://127.0.0.1:9292/bidcos:
Mar 4 11:35:26 homematic-ccu2 user.err rfd: XmlRpc fault: [faultCode:-321,faultString:"Error requesting method getLinks: Failure Code: -1"]
Gruß,
Alfred
Zitat von: Dirk am 03 März 2015, 17:02:47
Ansonsten probier das mit dem seriellen Bootloader. Das geht auch ganz gut.
Viele Grüße
Dirk
Heute Nachmittag wird es spannend.
Ich habe mir mal die Sachen mit auf die Arbeit genommen und gerade mal das beschrieben durchgeführt.
Dafür habe ich mir extra mal ein Ubuntu auf einer Maschine installiert, dann arduino 1.6.0 installiert und den Aufruf entsprechend angpasst.
Als Ausgabe kam dann irgendwann dies hier:
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xff
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
avrdude done. Thank you.
Die LED auf dem USB-UART-Adapter als auch auf dem Sensor haben fleissig geblinkt.
Hört sich nicht wirklich so an, als wenn es funktioniert hätte oder?
Der Aufruf sieht angepasst so aus:
Nachdem ich den USB Adapter angeschlossen habe, kam unter /dev das ttyUSB0 hinzu. Sollte also passen.
/fhem/arduino-1.6.0/hardware/tools/avr/bin/avrdude -C/fhem/arduino-1.6.0/hardware/tools/avr/etc/avrdude.conf -patmega328p -c arduino -P/dev/ttyUSB0 -b57600 -D -Uflash:w:U:/fhem/HB-UW-Sen-THPL_update_V0_14_001_150301.hex:i
Zitat von: Akwak am 04 März 2015, 11:56:57
Also habe ich einmal in das Add-On Archiv geguckt und festgestellt, das auf meiner CCU immer noch das alte Add-On installiert war :-( Obwohl ich das neue über die UI eingespielt hatte.
Guter Hinweis.
Dann schau ich mal warum das Update mit dem Addon nicht klappt.
ZitatBei dem Versuch das Firmwareupdate einzuspielen, bekam ich immer die Meldung, das der Bootloader nicht gestartet werden konnte. Screenshot)
Der Bootloader vom Sensor kann von der CCu aus nicht automatisch gestartet werden.
Wenn diese Meldung kommt muss man den Sensor manuell in den Bootloader-Mode versetzen. Batterie raus, Configtaste gedrückt halten, Batterie wieder rein. Dann startet das Firmwareupdate. Ich meine das sollte so auch im Changelog stehen die man in der CCU zum Updatefile findet.
ZitatIch habe dann das Add-On manuell aktualisiert und siehe da, beim Internen Sensor ist der Updatebutton vorhanden. Beim Externen Sensor fehlt der Button aber weiterhin.
Lösche den Sensor bittte mal aus der CCU und lerne den neu an. Dann sollte der Updatebutton da sein.
Zitat von: maxritti am 04 März 2015, 12:32:40
Die LED auf dem USB-UART-Adapter als auch auf dem Sensor haben fleissig geblinkt.
Das ist eigentlich ein Anzeichen dafür, dass das Update grade läuft. Daher kann ich mir die Fehlermeldung nicht erklären.
Welche Firmware hat denn der Sensor jetzt?
Gruß
Dirk
Zitat von: Dirk am 04 März 2015, 12:56:46
Das ist eigentlich ein Anzeichen dafür, dass das Update grade läuft. Daher kann ich mir die Fehlermeldung nicht erklären.
Welche Firmware hat denn der Sensor jetzt?
Gruß
Dirk
Das schaue ich heute Nachmittag mal.
Wenn es geklappt hat, dann müsste dies bei dem Sensor in FHEM direkt ersichtlich werden oder ist dort ein "getConfig" notwendig?
Zitat von: maxritti am 04 März 2015, 13:01:14
Wenn es geklappt hat, dann müsste dies bei dem Sensor in FHEM direkt ersichtlich werden oder ist dort ein "getConfig" notwendig?
Einmal die Configtaste drücken sollte reichen. In der folgenden Device-Info-Message übertragt der Sensor dann auch die Firmwareversion an FHEM.
Gruß
Dirk
Zitat von: Dirk am 04 März 2015, 12:56:46
Lösche den Sensor bittte mal aus der CCU und lerne den neu an. Dann sollte der Updatebutton da sein.
Hi,
das hat leider auch nicht geholfen. Der Update Button fehlt trotzdem.
Gruß,
Alfred
Zitat von: Akwak am 04 März 2015, 13:27:04
das hat leider auch nicht geholfen. Der Update Button fehlt trotzdem.
Gut, dann muss ich am WE mal schauen woran das liegen kann.
Gruß
Dirk
Hallo Dirk,
Danke!
Gruss
Alfred
Zitat von: Dirk am 04 März 2015, 13:05:57
Einmal die Configtaste drücken sollte reichen. In der folgenden Device-Info-Message übertragt der Sensor dann auch die Firmwareversion an FHEM.
Gruß
Dirk
Schade. Der Zeit in den Events noch die Version 0.12.
Da muss ich wohl noch mal ran an das flashen.
Wenn Du/Ihr noch Ideen habt, wo es hängen kann, gerne her damit. :)
/EDIT:
Ich habe während des Flashens die Batterien aus dem Sensor genommen.
Ist doch korrekt oder?
Bevor hier noch Rauchwölkchen raus kommen.
Bin gerade etwas am Verzweifeln: Ich versuche gerade vergeblich, einen Sensor mit FW 0.12 und seriellem Bootloader auf einen OTA-Bootloader umzustellen. Der Plan ist, den OTA-Bootloader mittles AVRStudio via ISP mit einem AVR-Dragon zu flashen.
Erste Frage kann: Kann es sein, dass die BootSize-Fuse von dem ATMega von 1024 auf 2048 Bytes vergrößert werden muss, wenn man auf den OTA-Bootloader wechselt? Wenn ich das nicht mache, dann bootet der AVR nach dem Flashen gar nicht mehr scheinbar.
Beim Flashen des OTA-Bootloader-Hex-Files wird ja normalerweise auch der Rest des Flashes gelöscht. Hat man eine Chance per OTA dann initial eine neue Firmware aufzuspielen? Ich hab das Gefühl, dass man per OTA nur updaten kann, weil das Gerät schon eine gültige Seriennummer haben muss. Stimmt das so?
Ich würde eigentlich gerne von einem funktionierenden Stand (seriell-Bootloader + 0.12) nur den Bootloader upgraden und dann per OTA auf 0.14 wechseln. Wenn ich jedoch versuche, den OTA-Bootloader zu flashen, ohne dabei den Rest des Flashes zu löschen, schlägt immer das Verify fail mit einer Meldung:
Getting ISP frequency parameters.. SD=0x06 .. OKOK
Reading FLASH input file.. OK
Setting device parameters.. OK!
Entering programming mode.. OK!
Programming FLASH .. OK!
Reading FLASH .. OK!
WARNING: FLASH byte address 0x7800 is 0x00 (should be 0x80).. FAILED!
Leaving programming mode.. OK!
Ist die Idee generell blöd oder hat jemand eine Idee, was ich falsch mache? Danke!
Hallo zusammen.
Ich interessiere mich ebenfalls sehr für Euer Projekt und würde gerne mitmachen. Leider ist es mir bis heute nicht gelungen meine Entwicklungsumgebung so einzurichten, dass sich die Software fehlerfrei compilieren läßt.
Eigentlich hatte ich mir eingebildet, dass ich zumindest ein wenig Ahnung vom Programmieren habe, aber dieses Projekt läßt mich stark daran zweifeln. Ich lese bereits seit einigen Wochen in dem bereits recht umfangreichen Forum und habe es mit unterschiedlichen AskSin- und Arduino-Versionen probiert, aber es ist mir bisher nicht gelungen die Software fehlerfrei zu compilieren.
Nun hatte ich gehofft, endlich eine funktionierende Version gefunden zu haben, aber auch diese produziert bei mir nur Fehlermeldungen.
Zitat von: Dirk am 01 März 2015, 21:45:25
Neue Firmware 0.14 (Beta)
Hallo Zusammen.
Die letzten Tage habe ich an den Millis() / 49-Tage / Batterie-Bugfix gearbeitet.
Eigentlich sollte diese Version schon auf Basis der neuen Lib erstellt werden. Allerdings ist das doch noch etwas mehr Arbeit wie erwartet.
Daher habe ich die millis() Verarbeitung noch in der alten Lib gefixt.
Ansonsten ist die Funktionalität der Lib identisch mit der Version 0.13
Zusammengefasst sieht der Changelog so aus:
Neue Register (aus Version 0.13)
- transmitTryMax: Sendeversuche des Sensors ohne ACK
- lowBatLimit: Low-Battery Warnschwelle
- ledMode: LED ist beim Senden an oder aus
- altitude: Hier kann die Bezugshöhe für den Luftdruck bereits im Sensor eingestellt werden
.......
Das komplette Packet mit Firmware:
https://github.com/kc-GitHub/Wettersensor/releases/tag/v0.14_beta
Die aktualisierte AskSin-Lib:
https://github.com/kc-GitHub/AskSin/archive/master.zip
........
Ich wäre Euch sehr dankbar, wenn sich jemand die Zeit nehmen könnte, um mir zu helfen die Software so einzurichten, dass auch ich mir einen Wettersensor nachbauen kann.
Danke
Helmut
Zitat von: vbs am 04 März 2015, 16:50:00
Kann es sein, dass die BootSize-Fuse von dem ATMega von 1024 auf 2048 Bytes vergrößert werden muss.
Ja. Der serielle Bootloader kommt mit 2k Boot-Flash aus. der OTAU-Bootloader braucht 4k.
ZitatBeim Flashen des OTA-Bootloader-Hex-Files wird ja normalerweise auch der Rest des Flashes gelöscht. Hat man eine Chance per OTA dann initial eine neue Firmware aufzuspielen? Ich hab das Gefühl, dass man per OTA nur updaten kann, weil das Gerät schon eine gültige Seriennummer haben muss.
Beim Flashen des Bootloaders wird alles gelöscht. Die Seriennummer und HM-ID kann beim Flashen mit dem Flashscript gesetzt werden.
Ohne das Setzen hat der Sensor dann die Defaultseriennummer die im Quellcode steht.
Die Fuses sollten so aussehen: lfuse: 0xE2, hfuse: 0xD0, efuse: 0x06
Im Git ist auch ein kleines flashscript. Aktuell leider nur für Windows.
https://github.com/kc-GitHub/Asksin_OTA_Bootloader/tree/master/Tools/Flash-Tool-Windows
Bullshit hatte aber auch eins für perl gebaut. Das findest du hier:
http://www.lxccu.com/hb-raspberry-bootloader-update
Hier ist auch eine Anleitung wie mal den Bootloader mit einem Raspberry Pi flash. Das sollte aber übertragbar sein.
Gruß
Dirk
Hi Helmut,
Zitat von: Poquito am 04 März 2015, 17:12:03
Ich lese bereits seit einigen Wochen in dem bereits recht umfangreichen Forum und habe es mit unterschiedlichen AskSin- und Arduino-Versionen probiert, aber es ist mir bisher nicht gelungen die Software fehlerfrei zu compilieren.
Was bekommst du denn für Fehlermeldungen?
Den aktuellen Code kann ich mit der Arduino-IDE 1.6.0 fehlerfrei kompilieren.
Alternativ kannst du auch das fertige Hexfile auf deinen Sensor flashen.
Entweder mit dem OTAU- oder dem seriellen Bootloader.
Gruß
Dirk
Hallo Dirk,
mit der Arduino-Version 1.6 wird dem exampel "HM_WDS10_TH_O" aus der AskSin-Library die Datei "Sensor_SHT10_BMP085.h" nicht gefunden, da in der Library nur "Sensor_SHT10_BMP085_TSL2561.h" vorhanden ist. Die anderen Fehlermeldungen die ich mit den vorherigen Versionen bekam kann ich hier nicht mehr sehen, da das Compilieren hier abgebrochen wird.
Gruß
Helmut
Jetzt bin ich vielleicht schon mal ein Stück weiter.
Als erstes habe ich mir das hex-File noch mal von github.com geholt.
Und siehe da. Das ist auf einmal grösser als die Datei, welche ich hatte.
Nämlich 244443 Bytes.
Dann hatte sich wohl in dem Parameter -U noch der Laufwerksbuchstabe U: eingeschlichen.
Denn wenn ich nun mit dem Befehl hier versuche zu flashen, kommt etwas anderes.
/fhem/arduino-1.6.0/hardware/tools/avr/bin/avrdude -C/fhem/arduino-1.6.0/hardware/tools/avr/etc/avrdude.conf -patmega328p -carduino -P/dev/ttyUSB0 -b57600 -D -Uflash:w:/fhem/HB-UW-Sen-THPL_update_V0_14_001_150301.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "/fhem/HB-UW-Sen-THPL_update_V0_14_001_150301.hex"
avrdude: ERROR: No valid record found in Intel Hex file "/fhem/HB-UW-Sen-THPL_update_V0_14_001_150301.hex"
avrdude: read from file '/fhem/HB-UW-Sen-THPL_update_V0_14_001_150301.hex' failed
avrdude: safemode: Fuses OK (H:00, E:00, L:00)
avrdude done. Thank you.
Ich hoffe mal, dass die Meldungen einem etwas sagen.
Sollte das HEX File daran schuld sein?
Das habe ich mir einfach mal via
wget https://github.com/kc-GitHub/Wettersensor/blob/v0.14_beta/Firmware-Release/HB-UW-Sen-THPL_update_V0_14_001_150301.hex
gezogen.
Zitat von: Poquito am 04 März 2015, 17:42:41
mit der Arduino-Version 1.6 wird dem exampel "HM_WDS10_TH_O" aus der AskSin-Library die Datei "Sensor_SHT10_BMP085.h" nicht gefunden, da in der Library nur "Sensor_SHT10_BMP085_TSL2561.h" vorhanden ist. Die anderen Fehlermeldungen die ich mit den vorherigen Versionen bekam kann ich hier nicht mehr sehen, da das Compilieren hier abgebrochen wird.
Ah, um die Examples geht es. Ja diese wurden nach den Patches der Lib nicht weiter gepflegt.
Daher hatte ich auch schon überlegt diese Examples zu löschen.
Ich denke das einfachste wird es sein wenn du dir den Code vom Sensor anschaust.
Zitat von: maxritti am 04 März 2015, 17:42:54
Nämlich 244443 Bytes.
Die Größe stimmt nicht.
Das hier:
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Firmware-Release/HB-UW-Sen-THPL_update_V0_14_001_150301.hex
ist 68.124 kBytes groß.
Daher auch die Fehlermeldung "No valid record found"
Zitatwget https://github.com/kc-GitHub/Wettersensor/blob/v0.14_beta/Firmware-Release/HB-UW-Sen-THPL_update_V0_14_001_150301.hex
schau mal in dein Hexfile rein. Da ist HTML-Code drinn.
Gruß
Dirk
Hallo Dirk,
wenn ich es mit "Wettersensor-0.14_beta.zip" versuche sieht es bei mir folgendermaßen aus:
ZitatArduino: 1.6.0 (Windows 7), Platine: "Arduino Pro or Pro Mini, ATmega328 (3.3V, 8 MHz)"
WetterSensor.ino: In function 'void cmdReset(uint8_t*, uint8_t)':
WetterSensor.ino:102:48: error: too few arguments to function 'void pHex(uint8_t*, uint8_t, uint8_t)'
In file included from D:\Users\Admin\Documents\Arduino\libraries\AskSin/AskSinMain.h:35:0,
from Register.h:1,
from WetterSensor.ino:2:
D:\Users\Admin\Documents\Arduino\libraries\AskSin/utility/Serial.h:68:6: note: declared here
void pHex(uint8_t *buf, uint8_t len, uint8_t mode); // print a couple of bytes in HEX format
^
WetterSensor.ino: In function 'void cmdConfigChanged(uint8_t*, uint8_t)':
WetterSensor.ino:141:54: error: too few arguments to function 'void pHex(uint8_t*, uint8_t, uint8_t)'
In file included from D:\Users\Admin\Documents\Arduino\libraries\AskSin/AskSinMain.h:35:0,
from Register.h:1,
from WetterSensor.ino:2:
D:\Users\Admin\Documents\Arduino\libraries\AskSin/utility/Serial.h:68:6: note: declared here
void pHex(uint8_t *buf, uint8_t len, uint8_t mode); // print a couple of bytes in HEX format
^
WetterSensor.ino: In function 'void cmdStatusRequest(uint8_t*, uint8_t)':
WetterSensor.ino:152:56: error: too few arguments to function 'void pHex(uint8_t*, uint8_t, uint8_t)'
In file included from D:\Users\Admin\Documents\Arduino\libraries\AskSin/AskSinMain.h:35:0,
from Register.h:1,
from WetterSensor.ino:2:
D:\Users\Admin\Documents\Arduino\libraries\AskSin/utility/Serial.h:68:6: note: declared here
void pHex(uint8_t *buf, uint8_t len, uint8_t mode); // print a couple of bytes in HEX format
^
WetterSensor.ino: In function 'void HM_Remote_Event(uint8_t*, uint8_t)':
WetterSensor.ino:157:54: error: too few arguments to function 'void pHex(uint8_t*, uint8_t, uint8_t)'
In file included from D:\Users\Admin\Documents\Arduino\libraries\AskSin/AskSinMain.h:35:0,
from Register.h:1,
from WetterSensor.ino:2:
D:\Users\Admin\Documents\Arduino\libraries\AskSin/utility/Serial.h:68:6: note: declared here
void pHex(uint8_t *buf, uint8_t len, uint8_t mode); // print a couple of bytes in HEX format
^
Fehler beim Kompilieren.
Dieser Report hätte mehr Informationen mit
"Ausführliche Ausgabe während der Kompilierung"
aktiviert in Datei > Einstellungen
Gruß Helmut
Ok, vielleicht sollte ich die Lib auch taggen.
Da hab ich natürlich schon weiterentwickelt.
Daher müsstest du auch den Sensorcode vom Master nehmen.
Oder diesen Link hier:
https://github.com/kc-GitHub/AskSin/archive/c7c2910944212bea6dd199e9c3ace6c02ce29347.zip
Der Code passt auch zur getaggten Version 0.14.
Ich habe den Link aber mal in die Releasnote eingefügt.
Gruß
Dirk
Zitat von: vbs am 04 März 2015, 16:50:00
Ich hab das Gefühl, dass man per OTA nur updaten kann, weil das Gerät schon eine gültige Seriennummer haben muss. Stimmt das so?
Nein, die Seriennummer steht bereits im Boot-Loader und die Software holt sie sich dann von da.
Gruss Marcel
Zitat von: Dirk am 01 März 2015, 21:45:25Falls jemand einmal über den Quellcode schauen möchte würde ich mich auch freuen.
Ich hab mir das soweit zeitlich möglich war mal angeschaut und hab auf den ersten Blick keine Probleme gefunden (ausser dass StartTime nicht initialisiert wird, aber das sollte ja IIRC implizit von der libc auf 0 gesetzt werden). Bin durch die Logik des Power-Management Code aber auch noch nicht komplett durchgestiegen.
Gibt es nen Grund wieso Du jetzt doch noch einen Hot-Fix veröffentlichst und nicht gleich auf NewAskSin umgeschwenkt bist? Ist die Umstellung so aufwendig?
Grüße Marcel
Hi Marcel,
Zitat von: MarcelK am 04 März 2015, 18:29:14
Gibt es nen Grund wieso Du jetzt doch noch einen Hot-Fix veröffentlichst und nicht gleich auf NewAskSin umgeschwenkt bist?
Ja, weil die Umstellung doch etwas Aufwendiger wie gedacht ist und noch nicht alles fertig ist.
Ich werde hier Trillu bei der weiteren Entwicklung so weit wie es geht unterstützen. Da ich da aber noch seine Unterstützung brauche möchte ich da keinen unnötigen "Druck" aufbauen.
Daher geht es erst mal mit der "alten" Lib weiter.
Gruß
Dirk
Zitat von: Dirk am 04 März 2015, 18:00:02
Die Größe stimmt nicht.
Das hier:
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Firmware-Release/HB-UW-Sen-THPL_update_V0_14_001_150301.hex
ist 68.124 kBytes groß.
Daher auch die Fehlermeldung "No valid record found"
schau mal in dein Hexfile rein. Da ist HTML-Code drinn.
Gruß
Dirk
Tausend Dank, da hatte ich wohl etwas mit den Links durcheinander geworfen.
Nun läuft der Innensensor schon mal unter 0.14. :D
Wie schaut denn die Belegung der Kontakte bei dem Aussensensor aus?
Wenn ich den so lege wie auf dem Bild ist das dann auch die untere Leiste beginnend von links?
Ja.
Bei beiden ist das Funkmodul immer rechts. Beim Innensensor halt auf der Platinenunterseite.
Prima. Dann sind beide Sensoren nun up-to-date.
Noch mal vielen Dank für Deine klasse Arbeit.
Hallo Dirk,
vielen Dank für den Link.
Zitat von: Dirk am 04 März 2015, 18:18:47
https://github.com/kc-GitHub/AskSin/archive/c7c2910944212bea6dd199e9c3ace6c02ce29347.zip
Damit lässt sich es sich fehlerfrei compilieren und ich kann endlich meine Hardware testen.
Viele Grüße
Helmut
Ich versuche weiterhin den OTA-Bootloader auf meinen Sensor zu flashen (mit mäßigem Erfolg):
Zitat von: Dirk am 04 März 2015, 17:15:17
Im Git ist auch ein kleines flashscript. Aktuell leider nur für Windows.
https://github.com/kc-GitHub/Asksin_OTA_Bootloader/tree/master/Tools/Flash-Tool-Windows
Bullshit hatte aber auch eins für perl gebaut. Das findest du hier:
http://www.lxccu.com/hb-raspberry-bootloader-update
Ok, danke. Ich hab jetzt kapiert, dass man nicht einfach den OTA-Bootloader als Hex-File per AVRStudio flashen kann, da erst noch Seriennummer und co. eingetragen werden muss. Ich hab das Ganze nun sowohl mit dem OTA-Flash-Tool für Windows und auch mit der Perl-Variante mit meinem AVRDragon per ISP zum Laufen bekommen. Es sieht nun für mich aus, als würde der Bootloader korrekt geflasht geflasht werden. Jedoch reagiert der Sensor nahezu überhaupt nicht. Nach meinem Verständnis, sollte ja die LED blinken, wenn ich bei gedrücktem Taster die Batterien einlege. Aber da tut sich gar nix.
Aus dem seriellen Port kommen zwar ein paar Zeichen raus, jedoch egal welche COM-Settings ich wähle (9600,57600,115200, Flusskontrolle aus/XON), es kommt nur Kauderwelsch.
So langsam aber sicher, nähere ich mich der mittelschweren Verzweiflung. :(
So habe ich geflasht, sieht da jemand ein Problem?
E:\Users\devkid\Projects\Asksin_OTA_Bootloader\Tools\Flash-Tool-Windows>flash.cmd dragon_isp Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex F1:01 86:C4:0D UWS5426622
E:\Users\devkid\Projects\Asksin_OTA_Bootloader\Tools\Flash-Tool-Windows>bin\sed -b -e "s/\(\x12\x34\)\(HB0Default\)\(\xAB\xCD\xEF\)/\xF1\x01UWS5426622\x86\xC4\x0D/" Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin 1>Bootloader-AskSin-OTA-HB_UW_Sen_THPL.tmp
12:34 HB0Default AB:CD:EF
Start flashing device with HM-TYPE: F1:01, HM-ID: 86:C4:0D and serial number: UWS5426622
****************************************
* Set fusebits with bitClock 187,5 KHz *
****************************************
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.18s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: erasing chip
avrdude.exe: reading input file "0xE2"
avrdude.exe: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.06s
avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0xE2:
avrdude.exe: load data lfuse data from input file 0xE2:
avrdude.exe: input file 0xE2 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.06s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0xD0"
avrdude.exe: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.06s
avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0xD0:
avrdude.exe: load data hfuse data from input file 0xD0:
avrdude.exe: input file 0xD0 contains 1 bytes
avrdude.exe: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.06s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of hfuse verified
avrdude.exe: reading input file "0x06"
avrdude.exe: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.06s
avrdude.exe: 1 bytes of efuse written
avrdude.exe: verifying efuse memory against 0x06:
avrdude.exe: load data efuse data from input file 0x06:
avrdude.exe: input file 0x06 contains 1 bytes
avrdude.exe: reading on-chip efuse data:
Reading | ################################################## | 100% 0.06s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of efuse verified
avrdude.exe: safemode: Fuses OK
avrdude.exe done. Thank you.
*************************************************************************
* Write bootloader, application and set lock bits with bitClock 1,5 MHz *
*************************************************************************
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.18s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin"
avrdude.exe: writing flash (4096 bytes):
Writing | ################################################## | 100% 3.07s
avrdude.exe: 4096 bytes of flash written
avrdude.exe: verifying flash memory against Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin:
avrdude.exe: load data flash data from input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin:
avrdude.exe: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin contains 4096 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 2.19s
avrdude.exe: verifying ...
avrdude.exe: 4096 bytes of flash verified
avrdude.exe: reading input file "0x3F"
avrdude.exe: writing lock (1 bytes):
Writing | ################################################## | 100% 0.06s
avrdude.exe: 1 bytes of lock written
avrdude.exe: verifying lock memory against 0x3F:
avrdude.exe: load data lock data from input file 0x3F:
avrdude.exe: input file 0x3F contains 1 bytes
avrdude.exe: reading on-chip lock data:
Reading | ################################################## | 100% 0.06s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lock verified
avrdude.exe: safemode: Fuses OK
avrdude.exe done. Thank you.
E:\Users\devkid\Projects\Asksin_OTA_Bootloader\Tools\Flash-Tool-Windows>
Zitat von: vbs am 05 März 2015, 00:50:38
Ich versuche weiterhin den OTA-Bootloader auf meinen Sensor zu flashen (mit mäßigem Erfolg):
Ok, danke. Ich hab jetzt kapiert, dass man nicht einfach den OTA-Bootloader als Hex-File per AVRStudio flashen kann, da erst noch Seriennummer und co. eingetragen werden muss.
Du kannst das schon machen. Dann musst du aber im Bootloader deine Seriennummer eintragen und neu kompilieren.
Schau da mal nach HM_SERIAL und HM_ID in /devices/HB-UW-Sen-THPL.h
ZitatAus dem seriellen Port kommen zwar ein paar Zeichen raus, jedoch egal welche COM-Settings ich wähle (9600,57600,115200, Flusskontrolle aus/XON), es kommt nur Kauderwelsch.
Die Comport-Einstellungen müssen so aussehen: Baudrate: 57600, Databits: 8, Parity: none, Stopbits: 1
ZitatSo habe ich geflasht, sieht da jemand ein Problem?
Das sieht erst einmal ok aus. Nur dass diese Zeilen hier kommen wundert mich:
E:\Users\devkid\Projects\Asksin_OTA_Bootloader\Tools\Flash-Tool-Windows>bin\sed -b -e "s/\(\x12\x34\)\(HB0Default\)\(\xAB\xCD\xEF\)/\xF1\x01UWS5426622\x86\xC4\x0D/" Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin 1>Bootloader-AskSin-OTA-HB_UW_Sen_THPL.tmp
12:34 HB0Default AB:CD:EF
Das würde aber ggf. nur die Manipulation der Seriennummer und HM-ID betreffen.
Starten sollte der Bootloader aber trotzdem.
Blinkt der Sensor ohne gedrückten Taster?
Hier sollte er dann wenigstens die Bootloaderversion zeigen: 7mal kurzes Blinken
Gruß
Dirk
Zitat von: Dirk am 05 März 2015, 12:03:07
Blinkt der Sensor ohne gedrückten Taster?
Hier sollte er dann wenigstens die Bootloaderversion zeigen: 7mal kurzes Blinken
Nee, also ob mit oder ohne Taster: da blinkt nix. Ich hatte auch schon genau die von dir beschriebenen COM-Settings benutzt, aber wirklich nur Kauderwelsch :(
Wenn ich jedoch per AVRStudio das unmodifizierte Hex-File flashe, dann blinkt er brav und ich kann auch auf dem COM-Port diese Ausgaben sehen:
AskSin OTA Bootloader V0.7.0
TX bootloader sequence
Wait for CB msg
Timeout
CRC fail, Reboot
Scheint so, als würde bei dem Flashen per avrdude irgendwas schief gehen? Oder läuft vielleicht sed Amok und verändert irgendwas in dem Bin-File, wo es nichts ändern sollte? Ich werde mal die sed-Aufrufe auskommentieren und gucken, was dann passiert...
Nee, also auch wenn ich sie sed-Aufrufe weglasse (bzw. durch ein simples "copy %fileBasename%.bin %fileBasename%.tmp" ersetze) tut sich einfach gar nichts nach dem Flashen. Jedoch habe ich gemerkt, dass irgendwas dauerhaft ganz leise fiept, wenn ich die Batterien einsetze.
Zitat von: vbs am 05 März 2015, 12:16:34
Scheint so, als würde bei dem Flashen per avrdude irgendwas schief gehen? Oder läuft vielleicht sed Amok und verändert irgendwas in dem Bin-File, wo es nichts ändern sollte? Ich werde mal die sed-Aufrufe auskommentieren und gucken, was dann passiert...
So sieht es aus.
Ich schaue mir heute Abend das Script noch mal an. nicht dass sich hier ein Fehler eingeschlichen hat.
Zitat von: vbs am 05 März 2015, 12:20:38
Jedoch habe ich gemerkt, dass irgendwas dauerhaft ganz leise fiept, wenn ich die Batterien einsetze.
Das ist die Spule vom Schaltregler die das immer mal macht.
Gruß
Dirk
Ich hab jetzt etwas rausfinden können: Und zwar scheint bei mir die hex2bin-Konvertierung das Problem zu sein.
Wenn ich das "unbehandelte" HEX-File so mit avrdude flashe, dann lebt der Bootloader hinterher:
E:\Users\devkid\Projects\Asksin_OTA_Bootloader\Tools\Flash-Tool-Windows>bin\avrdude.exe -patmega328p -cdragon_isp -Pusb -Uflash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex -B10
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.17s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex"
avrdude.exe: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex auto detected as Intel Hex
avrdude.exe: writing flash (32768 bytes):
Writing | ################################################## | 100% 3.90s
avrdude.exe: 32768 bytes of flash written
avrdude.exe: verifying flash memory against Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:
avrdude.exe: load data flash data from input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:
avrdude.exe: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex auto detected as Intel Hex
avrdude.exe: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex contains 32768 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 22.94s
avrdude.exe: verifying ...
avrdude.exe: 32768 bytes of flash verified
avrdude.exe: safemode: Fuses OK
avrdude.exe done. Thank you.
Wenn ich jedoch das HEX-File nach BIN konvertiere:
bin\hex2bin.exe -c Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex
Und das dann flashe, dann fiept er nur:
E:\Users\devkid\Projects\Asksin_OTA_Bootloader\Tools\Flash-Tool-Windows>bin\avrdude.exe -patmega328p -cdragon_isp -Pusb -Uflash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin -B10
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.17s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin"
avrdude.exe: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin auto detected as raw binary
avrdude.exe: writing flash (4096 bytes):
Writing | ################################################## | 100% 3.65s
avrdude.exe: 4096 bytes of flash written
avrdude.exe: verifying flash memory against Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin:
avrdude.exe: load data flash data from input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin:
avrdude.exe: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin auto detected as raw binary
avrdude.exe: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin contains 4096 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 2.92s
avrdude.exe: verifying ...
avrdude.exe: 4096 bytes of flash verified
avrdude.exe: safemode: Fuses OK
avrdude.exe done. Thank you.
Sagt das jemandem etwas?
Zitat von: Dirk am 04 März 2015, 13:32:30
Gut, dann muss ich am WE mal schauen woran das liegen kann.
Gruß
Dirk
Das kann ich Dir ersparen ;-) Ich habs gefunden. Im XML des Addons fehlt die Angabe für den Ausßensensor, das er updateable ist.
<?xml version="1.0" encoding="iso-8859-1"?>
<device version="2" rx_modes="CONFIG,WAKEUP,LAZY_CONFIG" cyclic_timeout="600">
<supported_types>
<type name="HB-UW-Sen-THPL-I" id="HB-UW-Sen-THPL-I" updatable="true">
<parameter index="9.0" size="1.0" cond_op="GE" const_value="12" />
<parameter index="10.0" size="2.0" const_value="0xF101" />
</type>
<type name="HB-UW-Sen-THPL-O" id="HB-UW-Sen-THPL-O" updatable="true"> <!---^hier fehlt in dem Addon das "updatable="true" -->
<parameter index="9.0" size="1.0" cond_op="GE" const_value="12" />
<parameter index="10.0" size="2.0" const_value="0xF102"></parameter>
</type>
</supported_types>
Nachdem ich das ergänzt habe, ließen sich auch die Außensensoren problemlos updaten.
Nun habe ich nur noch das Problem, das einer meiner Innensensoren der Meinung ist, er bräuchte neue Batterien, obwohl ich ihm ganz frische eingelegt habe.
Gruß,
Alfred
Zitat von: Akwak am 05 März 2015, 12:38:23
Das kann ich Dir ersparen ;-) Ich habs gefunden. Im XML des Addons fehlt die Angabe für den Ausßensensor, das er updateable ist.
Wo hattest du die Datei her?
im Git stimmt die:
https://github.com/kc-GitHub/Wettersensor/blob/v0.14_beta/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon-src/firmware/rftypes/hb_uw_sen_thpl.xml
ZitatNun habe ich nur noch das Problem, das einer meiner Innensensoren der Meinung ist, er bräuchte neue Batterien, obwohl ich ihm ganz frische eingelegt habe.
Was sagt die Spannung?
Schau mal ob in den Einstellungen Burst an ist. Das sollte aus sein. Das ist noch experimentell und lässt den Sensor nicht mehr in den Standby gehen.
Gruß
Dirk
Hallo Dirk,
Die Datei hatte ich über den Link aus Post #1467 geladen.
Die Spannung an den Batterien beträgt 3,2V
Den Burstmode kann ich bei der CCU nicht einstellen oder?
Gruss
Alfred
Zitat von: Akwak am 05 März 2015, 13:22:47
Die Datei hatte ich über den Link aus Post #1467 geladen.
Ah, mist. Ich hatte das Ausführen des Buildscriptes vergessen.
Ich habe den Link in dem Post aktualisiert. Hier ist das korrigierte Addon:
https://github.com/kc-GitHub/Wettersensor/raw/master/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon.tgz
ZitatDie Spannung an den Batterien beträgt 3,2V
Den Burstmode kann ich bei der CCU nicht einstellen oder?
Doch. Das heist in der CCU "Wake-On-Radio". Und schau mal bitte wie "Low-Bat.-Schwelle" bei dir eingestellt ist.
Gruß
Dirk
Zitat von: Dirk am 05 März 2015, 13:35:18
Doch. Das heist in der CCU "Wake-On-Radio". Und schau mal bitte wie "Low-Bat.-Schwelle" bei dir eingestellt ist.
Ok, Wake-On-Radio ist aus und Low-Bat.-Schwelle ist auf 1.0.
Gruß,
Alfred
So, ich hab jetzt den OTA-Bootloader geflasht bekommen. Die mit hex2bin erzeugten BIN-Dateien laufen bei mir nach dem Flashen nicht. Im Endeffekt konnte ich dann folgendermaßen ein funktionierendes BIN-File erzeugen (evtl. weiss jemand, wie man das schöner machen könnte):
- per avrdude die unbehandelte HEX-Datei geflasht (ohne angepasste Seriennummer und co)
- per avrdude die gerade geflashte Datei wieder als BIN (Format 'r') auslesen
- aus dem flash.cmd den hex2bin-Aufruf rausnehmen und stattdessen dem Script das ausgelesene BIN-File unterschieben
Das klappt jetzt alles auch soweit. Also 0.14 wird angezeigt und ich sehe auch die Register usw. Wenn ich jedoch getConfig mache, dann bekomme ich resndFail und dann als state
state RESPONSE TIMEOUT:PeerListDas Ganze reproduzierbar bei beiden Sensoren, die ich habe.
@vbs
hast du auch die fhem-datei getauscht? v0.13/v0.14 benötigen eine andere.
Ja, ich hab die HMConfig_SenTHPL.pm aus dem 0.14-Beta-Tag.
auch mal ein fhem restart gemacht? vorher noch set clear all beim sensor?
neu anlernen natürlich auch.
Ja, hab ich alles gemacht und gerade nochmal überprüft.
dann schau dir mal die raw-messages an.
Das sieht dann so aus:
2015.03.05 18:36:17 3: CUL_HM set ku_fridge getConfig
2015.03.05 18:36:21 5: HMLAN/RAW: /E86C40D,0000,0106DE73,FF,FFB9,7DA20086C40DF155440EF1015557533534323636323270030100
2015.03.05 18:36:21 5: HMLAN_Parse: HMLAN0 R:E86C40D stat:0000 t:0106DE73 d:FF r:FFB9 m:7D A200 86C40D F15544 0EF1015557533534323636323270030100
2015.03.05 18:36:21 5: HMLAN0 dispatch A1A7DA20086C40DF155440EF1015557533534323636323270030100::-71:HMLAN0
2015.03.05 18:36:21 3: Device ku_fridge added to ActionDetector with 000:10 time
2015.03.05 18:36:21 5: HMLAN: Skip ACK
2015.03.05 18:36:21 5: HMLAN_Send: HMLAN0 S:+86C40D,00,01,00
2015.03.05 18:36:21 5: HMLAN_Send: HMLAN0 S:SEB0273D1 stat: 00 t:00000000 d:01 r:EB0273D1 m:2F A001 F15544 86C40D 00040000000000
2015.03.05 18:36:22 5: HMLAN/RAW: /E86C40D,0000,0106E0DA,FF,FFBA,2FA01086C40DF1554402010005640AF10B550C44121014032400
2015.03.05 18:36:22 5: HMLAN_Parse: HMLAN0 R:E86C40D stat:0000 t:0106E0DA d:FF r:FFBA m:2F A010 86C40D F15544 02010005640AF10B550C44121014032400
2015.03.05 18:36:22 5: HMLAN0 dispatch A1A2FA01086C40DF1554402010005640AF10B550C44121014032400::-70:HMLAN0
2015.03.05 18:36:22 5: HMLAN: Skip ACK
2015.03.05 18:36:22 5: HMLAN/RAW: /REB0273D1,0001,0106E0DF,FF,FFBA,2FA01086C40DF1554402010005640AF10B550C44121014032400
2015.03.05 18:36:22 5: HMLAN_Parse: HMLAN0 R:REB0273D1 stat:0001 t:0106E0DF d:FF r:FFBA m:2F A010 86C40D F15544 02010005640AF10B550C44121014032400
2015.03.05 18:36:22 5: HMLAN0 dispatch A1A2FA01086C40DF1554402010005640AF10B550C44121014032400::-70:HMLAN0
2015.03.05 18:36:23 5: HMLAN/RAW: /REB0273D1,0001,0106E0DF,FF,FFBA,2FA01086C40DF1554402010005640AF10B550C44121014032400
2015.03.05 18:36:23 5: HMLAN_Parse: HMLAN0 R:REB0273D1 stat:0001 t:0106E0DF d:FF r:FFBA m:2F A010 86C40D F15544 02010005640AF10B550C44121014032400
2015.03.05 18:36:23 5: HMLAN0 dispatch A1A2FA01086C40DF1554402010005640AF10B550C44121014032400::-70:HMLAN0
2015.03.05 18:36:23 5: HMLAN: Skip ACK
2015.03.05 18:36:23 5: HMLAN/RAW: /E86C40D,0000,0106E168,FF,FFB7,30A01086C40DF155440225000000
2015.03.05 18:36:23 5: HMLAN_Parse: HMLAN0 R:E86C40D stat:0000 t:0106E168 d:FF r:FFB7 m:30 A010 86C40D F15544 0225000000
2015.03.05 18:36:23 5: HMLAN0 dispatch A0E30A01086C40DF155440225000000::-73:HMLAN0
2015.03.05 18:36:23 5: HMLAN: Skip ACK
2015.03.05 18:36:23 5: HMLAN_Send: HMLAN0 S:+86C40D,00,01,00
2015.03.05 18:36:23 5: HMLAN_Send: HMLAN0 S:SEB027C98 stat: 00 t:00000000 d:01 r:EB027C98 m:30 A001 F15544 86C40D 0103
2015.03.05 18:36:24 5: HMLAN/RAW: /E306FC5,0000,0106EB3F,FF,FFAE,BB865A306FC500000088AF2C
2015.03.05 18:36:24 5: HMLAN_Parse: HMLAN0 R:E306FC5 stat:0000 t:0106EB3F d:FF r:FFAE m:BB 865A 306FC5 000000 88AF2C
2015.03.05 18:36:24 5: HMLAN0 dispatch A0CBB865A306FC500000088AF2C::-82:HMLAN0
2015.03.05 18:36:24 5: HMLAN/RAW: /REB027C98,0008,00000000,FF,7FFF,30A001F1554486C40D0103
2015.03.05 18:36:24 5: HMLAN_Parse: HMLAN0 R:REB027C98 stat:0008 t:00000000 d:FF r:7FFF m:30 A001 F15544 86C40D 0103
2015.03.05 18:36:24 5: HMLAN_Parse: HMLAN0 no ACK from 86C40D
2015.03.05 18:36:26 5: HMLAN/RAW: /E261725,0000,0106F394,FF,FFBD,1D865A261725000000A8D820
2015.03.05 18:36:26 5: HMLAN_Parse: HMLAN0 R:E261725 stat:0000 t:0106F394 d:FF r:FFBD m:1D 865A 261725 000000 A8D820
2015.03.05 18:36:26 5: HMLAN0 dispatch A0C1D865A261725000000A8D820::-67:HMLAN0
2015.03.05 18:36:28 5: HMLAN_Send: HMLAN0 S:SEB029136 stat: 00 t:00000000 d:01 r:EB029136 m:30 A001 F15544 86C40D 0103
2015.03.05 18:36:29 5: HMLAN/RAW: /REB029136,0008,00000000,FF,7FFF,30A001F1554486C40D0103
2015.03.05 18:36:29 5: HMLAN_Parse: HMLAN0 R:REB029136 stat:0008 t:00000000 d:FF r:7FFF m:30 A001 F15544 86C40D 0103
2015.03.05 18:36:29 5: HMLAN_Parse: HMLAN0 no ACK from 86C40D
2015.03.05 18:36:30 5: HMLAN_Send: HMLAN0 I:K
2015.03.05 18:36:30 5: HMLAN/RAW: /HHM-LAN-IF,03C7,LEQ0659500,2CC53A,F15544,0107065D,0017
2015.03.05 18:36:30 5: HMLAN_Parse: HMLAN0 V:03C7 sNo:LEQ0659500 d:2CC53A O:F15544 t:0107065D IDcnt:0017
2015.03.05 18:36:31 4: HMLAN_ack: timeout - clear queue
2015.03.05 18:36:33 4: HMLAN_ack: timeout - clear queue
2015.03.05 18:36:33 5: HMLAN_Send: HMLAN0 S:SEB02A5DC stat: 00 t:00000000 d:01 r:EB02A5DC m:30 A001 F15544 86C40D 0103
2015.03.05 18:36:34 5: HMLAN/RAW: /E306FC5,0000,01071250,FF,FFB3,1C8410306FC50000000B88AF0E40
2015.03.05 18:36:34 5: HMLAN_Parse: HMLAN0 R:E306FC5 stat:0000 t:01071250 d:FF r:FFB3 m:1C 8410 306FC5 000000 0B88AF0E40
2015.03.05 18:36:34 5: HMLAN0 dispatch A0E1C8410306FC50000000B88AF0E40::-77:HMLAN0
2015.03.05 18:36:34 5: HMLAN/RAW: /REB02A5DC,0008,00000000,FF,7FFF,30A001F1554486C40D0103
2015.03.05 18:36:34 5: HMLAN_Parse: HMLAN0 R:REB02A5DC stat:0008 t:00000000 d:FF r:7FFF m:30 A001 F15544 86C40D 0103
2015.03.05 18:36:34 5: HMLAN_Parse: HMLAN0 no ACK from 86C40D
2015.03.05 18:36:38 5: HMLAN_Send: HMLAN0 S:SEB02B65E stat: 00 t:00000000 d:01 r:EB02B65E m:30 A001 F15544 86C40D 0103
2015.03.05 18:36:38 4: HMLAN_ack: timeout - clear queue
2015.03.05 18:36:39 5: HMLAN/RAW: /REB02B65E,0008,00000000,FF,7FFF,30A001F1554486C40D0103
2015.03.05 18:36:39 5: HMLAN_Parse: HMLAN0 R:REB02B65E stat:0008 t:00000000 d:FF r:7FFF m:30 A001 F15544 86C40D 0103
2015.03.05 18:36:39 5: HMLAN_Parse: HMLAN0 no ACK from 86C40D
2015.03.05 18:36:43 4: HMLAN_ack: timeout - clear queue
2015.03.05 18:36:44 5: HMLAN/RAW: /E306FC5,0000,0107395E,FF,FFB2,BB8470306FC500000000AF2C
2015.03.05 18:36:44 5: HMLAN_Parse: HMLAN0 R:E306FC5 stat:0000 t:0107395E d:FF r:FFB2 m:BB 8470 306FC5 000000 00AF2C
2015.03.05 18:36:44 5: HMLAN0 dispatch A0CBB8470306FC500000000AF2C::-78:HMLAN0
2015.03.05 18:36:46 5: HMLAN/RAW: /E261725,0000,010741B4,FF,FFBE,1D847026172500000000D820
2015.03.05 18:36:46 5: HMLAN_Parse: HMLAN0 R:E261725 stat:0000 t:010741B4 d:FF r:FFBE m:1D 8470 261725 000000 00D820
2015.03.05 18:36:46 5: HMLAN0 dispatch A0C1D847026172500000000D820::-66:HMLAN0
HMID des Sensor ist 86C40D. Bin da kein Experte aber spontan wundere ich mich über "HMLAN0 no ACK from 86C40D". Ich hoffe, euch sagt das mehr.
du drückst auch den taster am sensor, damit der sensor die befehle empfangen kann? wenn sich zentrale und sensor unterhalten, sollte während des gleichmässigen config-blinkens ein zusätzliches flackern auftauchen.
zumindestens senden kann er. ;)
Ja, in diesem Fall hab ich den Taster gedrückt. So wie ich das verstehe, kann ich damit (nach getConfig) eine sofortige Kommunikation forcieren ohne 2-3 Minuten warten zu müssen, bis sich der Sensor freiwillig meldet.
Wenn ich den Taster drücke, dann flackert die LED auch kurz ganz wild. Danach sehe ich aber in FHEM noch für viele Sekunden (im Log zu sehen), wie der reSnd-Counter immer wieder inkrementiert und dann irgendwann mit resnd-Fail aufgibt.
Generell funktioniert aber die Kommunikation: Ich bekomme regelmäßig Readings und auch die Register-Liste habe ich korrekt bekommen.
Zitat von: vbs am 05 März 2015, 19:52:24
Ja, in diesem Fall hab ich den Taster gedrückt. So wie ich das verstehe, kann ich damit (nach getConfig) eine sofortige Kommunikation forcieren ohne 2-3 Minuten warten zu müssen, bis sich der Sensor freiwillig meldet.
Damit Configdaten übertragen werden muss aktuell immer der Config-Taster gedrückt werden.
Das so genannte Lazy-Config. Also das automatische verarbeiten von Configdaten bei der kommenden Konfiguration klappt noch nicht zuverlässig.
Hab aber noch nicht rausgefunden warum.
Gruß
Dirk
Ok, habe das mit dem Wissen nochmal getestet. Vorab: getConfig läuft ohne Fehler durch, wenn ich den Taster später nochmals drücke.
Bei mir ist das so:
- in FHEM getConfig machen (führt zu 2 CMDs_pending)
- Taster am Sensor betätigen
- LED blinkt kurz wild und das "2 CMDs_pending" verschwindet. Jedoch bleibt "protState CMDs_processing..." stehen
- Wenn ich jetzt nichts weiter mache, dann steigt protResnd nach und nach um 3 an und resultiert dann in protResndFail
Wenn ich nach Punkt 3 jedoch nochmal den Taster drücke, dann hört das protResnd auf und es erscheint auch kein protResndFail und protState wechselt auf "CMDs_done". Also ich muss im Endeffekt zweimal den Taster drücken bei getConfig.
ZitatAlso ich muss im Endeffekt zweimal den Taster drücken bei getConfig.
bei mir auch. das muss aber neu sein.
Zitat von: frank am 05 März 2015, 20:39:18
bei mir auch. das muss aber neu sein.
Ja, das hab ich letztens auch festgestellt. Der Sensor wartet wohl nicht so lange bis alle Configtelegramme abgearbeitet wurden und geht schon mal schlafen.
ZitatJa, das hab ich letztens auch festgestellt. Der Sensor wartet wohl nicht so lange bis alle Configtelegramme abgearbeitet wurden und geht schon mal schlafen.
aber ist er dann nicht falsch in cul_hm konfiguriert? wenn er als config-device läuft, müssten die cmds doch pending bleiben, bis man wieder den configtaster drückt. wenn man jetzt aber nur einmal drückt, versucht fhem rücksichtslos das command zu senden. erfolg ist cmds_error.
Ich weis nicht genau wie das in cul_hm geregelt ist. In der ccu bleibt die Info "Konfigdaten stehen zur Übertragungan" so lange stehen bis alles übertragen wurde.
nach meinem verständnis mit dem rxt-type.
#rxt - receivetype of the device------
# l: receive on lazy config - no idea how this works so far.....
# c: receive on config
# w: receive in wakeup
# b: receive on burst
# f: receive on burst if enabled
$HMConfig::culHmModel{'F101'} = {name => 'HB-UW-Sen-THPL-I', st => 'THPLSensor', cyc => '00:10', rxt => 'c:f', lst => 'p', chn => '',};
$HMConfig::culHmModel{'F102'} = {name => 'HB-UW-Sen-THPL-O', st => 'THPLSensor', cyc => '00:10', rxt => 'c:f', lst => 'p', chn => '',};
vielleicht hat die burst option "f" ein eigenleben? oder man müsste hier etwas ändern?
$HMConfig::culHmRegModel{'HB-UW-Sen-THPL-I'} = {
'burstRx' => 1,
Zitat von: frank am 05 März 2015, 21:18:56
nach meinem verständnis mit dem rxt-type.
#rxt - receivetype of the device------
# l: receive on lazy config - no idea how this works so far.....
# c: receive on config
# w: receive in wakeup
# b: receive on burst
# f: receive on burst if enabled
Ich habe hier in meiner pm-datei "l" schon mal eingebaut. das hat aber noch nicht so richtig funktioniert. Daher ist das so noch nicht im repo.
Ich habe aber mal einchecken. Ist im master.
Hallo allerseits
Ich habe heute auf die neue Version upgedated und es ging auf Anhieb :-)
Es tut mir jetzt schon fast leid, so eine triviale Frage hier dazwischen zu drücken aber ich glaub es ist ein Bug, oder besser ein buggelchen.
Readings:
2015-03-05 22:07:33 Activity alive
2015-03-05 22:07:33 CommandAccepted yes
2015-03-05 22:07:33 D-firmware 0.14
2015-03-05 22:07:33 D-serialNr UWS5439349
2015-03-05 22:07:34 PairedTo 0x23A776
2015-03-05 22:07:34 R-altitude 645 m
2015-03-05 22:05:58 R-burstRx off
2015-03-05 22:05:58 R-ledMode on
2015-03-05 22:05:58 R-lowBatLimitTHPL 1.6 V
2015-03-05 22:05:58 R-pairCentral 0x23A776
2015-03-05 22:05:58 R-transmDevTryMax 3
2015-03-05 22:07:34 RegL_00: 01:00 05:64 0A:23 0B:A7 0C:76 12:10 14:03 24:02 25:85 00:00
2015-03-05 22:12:09 batVoltage 3.10
2015-03-05 22:12:09 battery ok
2015-03-05 22:12:09 dewpoint 8.0
2015-03-05 22:12:09 humidity 36
2015-03-05 22:12:09 luminosity 4.33
2015-03-05 22:12:09 pressure 1030.6
2015-03-05 22:07:08 pressure-nn 1030.7
2015-03-05 22:05:57 recentStateType info
2015-03-05 22:12:09 state T: 24.0 H: 36 L: 4.33 P: 1030.6
2015-03-05 22:12:09 temperature 24.0
pressure ist 1030,6 und über NNull nur um 0,1 mehr? Ich habe die Höhe von 645 Metern angegeben. Laut Wetterbericht ist der wert über NN 1035 hPa. Dieser Wert wüde also passen. Aber der berechnete Wert müsste so um 1120 hPa liegen.
lg Harald
@ Mr. P
Zitat von: Mr. P am 02 März 2015, 13:42:51
Hast du schon eine Idee, wie die Syncproblematik bei gepeerten Thermostaten in den Griff zu bekommen ist? Zur Zeit sind sie die meiste Zeit out-of-sync (und finden sich dann immer wieder für kurze Zeit über den Tag verteilt).
Ich habe da noch eine Idee:
hast du zufällig einen Sensor mit Helligkeitssensor mit dem Thermostat gepeert?
Kannst du da ggf. zu den Syncproblemen eine Verbindung zur Helligkeit erkennen?
Denn, wenn es hell ist, dann braucht der Helligkeitssensor ca. 500ms um den Messwert zu sampeln. wenn es dunkel ist braucht der nur um die 230ms.
Gruß
Dirk
Zitat von: honk am 05 März 2015, 22:30:48
pressure ist 1030,6 und über NNull nur um 0,1 mehr? Ich habe die Höhe von 645 Metern angegeben. Laut Wetterbericht ist der wert über NN 1035 hPa. Dieser Wert wüde also passen. Aber der berechnete Wert müsste so um 1120 hPa liegen.
Ich glaube hier liegt eine Kollission mit der Höhe in FHEM vor.
Schau mal ob du in FHEM das globale Attribute altitude gesetzt hast.
Die Höhe im Sensor hatte ich bisher hauptsächlich für CCU-User gedacht, da dort nicht so einfach der reduzierte Luftruck berechnet werden kann.
Bei FHEM braucht du das Register "R-altitude" also nicht setzen. Die Berechnung macht FHEM dann.
Ich werde in das Modul aber noch einbauen, dass die Höhe von FHEM nicht benutzt wird, wenn R-altitude im Sensor gesetzt ist.
Gruß
Dirk
Zitat von: Dirk am 05 März 2015, 23:01:34
@ Mr. PIch habe da noch eine Idee:
hast du zufällig einen Sensor mit Helligkeitssensor mit dem Thermostat gepeert?
Kannst du da ggf. zu den Syncproblemen eine Verbindung zur Helligkeit erkennen?
Denn, wenn es hell ist, dann braucht der Helligkeitssensor ca. 500ms um den Messwert zu sampeln. wenn es dunkel ist braucht der nur um die 230ms.
Hej Dirk,
zufällig sind alle meine gepeerten Sensoren mit einem Helligkeitssensor ausgestattet (alles 03er-Modelle).
Ich werde einmal schnell einen Tagesplot generieren, wo man Temperatur- & Helligkeit vom Sensor plus die Temperatur vom gepeerten RT vergleichen kann. :-)
Edit:
Und da ist auch schon das passende Plot-File von gestern. Allzu viel Zusammenspiel zwischen Helligkeit und vorkommenden Temperaturschwankungen kann ich allerdings leider nicht erkennen.
Hallo Dirk
Zitat von: Dirk am 05 März 2015, 23:40:06
Ich glaube hier liegt eine Kollission mit der Höhe in FHEM vor.
Schau mal ob du in FHEM das globale Attribute altitude gesetzt hast.
Ja genau so ist es. Ich hab natürlich die altitude in FHEM gesetzt. Register gelöscht und schon gehts.
lg Harald
Hallo zusammen,
ich habe da mal eine Frage dazu, bitte nicht schlagen aber 105 seiten Lesen fehlt mir dann doch die Zeit.
Ist der Innen sensor mit dem HM-CC-RT-DN koppelbar. Also als Temperatursensor?
Hallo zusammen,
ich habe da auch noch mal ne Frage zum flashen, ich habe einen Sensor mit OTA-Bootloader,
habe aber kein HM-USB Adapter.
Ich habe einen HM-LAN Adapter und auch einen CUL, den ich nutzen könnte.
Kann man mittels CUL flashen ?? Und wenn ja, welches Programm muss ich dazu nutzen?
Danke
Adam
Ja, mit dem CUL kannst du flashen.
Und egal ob mit dem hm-cfg-usb oder dem cul: in beiden Fällen ist flash-ota die Antwort. :-)
Zitat von: Mr. P am 05 März 2015, 23:58:34
Allzu viel Zusammenspiel zwischen Helligkeit und vorkommenden Temperaturschwankungen kann ich allerdings leider nicht erkennen.
Ich lasse seit gestern Abend auch mal die Temperaturen von gepeeren Sensor und Thermostat mitplotten. Aktuell habe ich hier keine Auffälligkeiten. Die Themperatur vom Thermostat zieht innerhalb von ein paar Minuten mit der Temperatur vom Sensor gleich. Ist dein Plot schon mit FW 0.14 gemacht?
Zitat von: RettungsTim am 06 März 2015, 07:22:07
Ist der Innen sensor mit dem HM-CC-RT-DN koppelbar. Also als Temperatursensor?
Ja. Allerdings klappt das peering hier nich nicht zuverlässig. Siehe oben. Das muss ich noch fixen.
Gruß
Dirk
Hallo Dirk,
ich interessiere mich auch für die Sensoren (Luftfeuchte-Messung ist doch auch möglich?). Kannst Du mir bitte bitte eine PN dazu schreiben?
Vielen Dank
Jens
mal eine Frage zu Erfahrungswerten da ich mir eine Readingsgroup erstellen möchte.
Hat jemand die Helligkeit von euch in einer Readingsgroup definiert..?
Wenn ja welche Werte habt ihr genommen, also unter welchem Wert er z.b. Rot zeigt bei welchem Wert Orange und Grün..?
Vorallem wird hier die Helligkeit in lux angegeben..?
Hallo Dirk,
ich habe gerade gesehen, das der Sensor im WebUI der CCU ja auch die Spannung anzeigt.
Das ist eigenartig:
Gemessene Volt an den Batterieklemmen: 3,2
Volt im UI: 0,4
Kein Wunder das die CCU behauptet die Batterie sei leer.
Bei meinen anderen Sensoren stimmen die Werte im UI mit den Werten an den BAtterieklemmen überein.
Hast Du eine Idee, woran das liegen kann?
Gruß,
Alfred
@Jens,
Du hast Post.
Zitat von: Akwak am 06 März 2015, 16:04:48
Gemessene Volt an den Batterieklemmen: 3,2
Volt im UI: 0,4
Ok, das könnte ein Hardwareproblem sein. Ggf. muss ich den tauschen / reparieren.
Du hast eine PM.
Viele grüße
Dirk
Zitat von: Dirk am 06 März 2015, 09:55:50
Ich lasse seit gestern Abend auch mal die Temperaturen von gepeeren Sensor und Thermostat mitplotten. Aktuell habe ich hier keine Auffälligkeiten. Die Themperatur vom Thermostat zieht innerhalb von ein paar Minuten mit der Temperatur vom Sensor gleich. Ist dein Plot schon mit FW 0.14 gemacht?
Ja, mein Beispiel ist bereits mit der 0.14er-Firmware.
Wobei bei mir die Probleme auch erst mit der Zeit angefangen hatten. Ich kann mich noch gut erinnern, wo andere hier im Thread bereits bemängelt haben, dass sich die beiden Geräte ständig verlieren, ich damals aber noch besten Gewissens behaupten konnte, dass bei mir alles so funktioniert, wie man es sich erwartet.
Edit: Weil es mir gerade wieder aufgefallen ist: Seitdem du die Spannungsmessung auf 1 Kommastelle beschnitten hast, habe ich zwei bis dreimal am Tag gleich 0,2V Sprünge. Tut nicht wirklich weh, aber dürfte wohl eine Ungenauigkeit vorliegen.
2015-03-07_12:23:54 sensorOutdoor batVoltage: 2.2
2015-03-07_12:27:05 sensorOutdoor batVoltage: 2.0
2015-03-07_12:29:57 sensorOutdoor batVoltage: 2.2
Zitat von: Mr. P am 07 März 2015, 16:13:21
Wobei bei mir die Probleme auch erst mit der Zeit angefangen hatten. Ich kann mich noch gut erinnern, wo andere hier im Thread bereits bemängelt haben, dass sich die beiden Geräte ständig verlieren, ich damals aber noch besten Gewissens behaupten konnte, dass bei mir alles so funktioniert, wie man es sich erwartet.
Mist, wieder so ein unspezifisches Fehlerbild.
Bei mir sind beide Kurven noch so ziemlich Deckungsgleich.
ZitatEdit: Weil es mir gerade wieder aufgefallen ist: Seitdem du die Spannungsmessung auf 1 Kommastelle beschnitten hast, habe ich zwei bis dreimal am Tag gleich 0,2V Sprünge. Tut nicht wirklich weh, aber dürfte wohl eine Ungenauigkeit vorliegen.
Müsste man mal weiter beobachten. Es gibt halt Rundungsfehler, da die Berechnung nun nicht mehr mit Flieskommaberechnung durchgeführt wird.
Hallo Dirk,
ich habe eine Panstamp - bei dem Schwankt die Batteriespannung auch immer etwas (0.15 V). Das kommt anscheinend immer auf den Zeitpunkt der Messung an - eben wieviel Strom der Prozessor gerade zieht.
Für mich ist das genau genug - es soll ja eingentlich nur genutzt werden um zu sehen, wann die Batterie alle ist.
Gruß Christoph
Hallo zusammen,
habe versucht mittels CUL und FHEM eine FWUPDATE durchzuführen.
leider Ohne Erfolg, ich bekomme immer wieder den Status :
CUL_HM_HB_UW_Sen_THPL_O_C943F8 2015-03-08 10:08:17 fwUpdate fail:Block1
Jemand eine Idee?
Habe einen Aussensensor nur mit Helligkeit (OTAU 0.6.1)
Gruß
Adam
Ich meine gelesen zu haben, dass FW-Updates nur mit flash-ota oder dem Homematic-Tool funktionieren.
Hallo Adam,
Du musst leider Löten - der OTAU 0.6.1 hatte einen Bug auch wenn man das HM Update Tool genommen hat brach der bei ca. 80% ab.
Der OTAU muss auf Version 0.7.0 upgedatet werden, dann sollte ein OTA Update gehen. ich habe das mit dem Raspi und avrdude gemacht - hat gut funktioniert.
Gruß Christoph
Zitat von: vbs am 08 März 2015, 12:00:36
Ich meine gelesen zu haben, dass FW-Updates nur mit flash-ota oder dem Homematic-Tool funktionieren.
Und mit der CCU. Mit FHEM direkt klappt es aus irgend einem Grund noch nicht.
Zitat von: Bennemannc am 08 März 2015, 12:43:44
Du musst leider Löten - der OTAU 0.6.1 hatte einen Bug auch wenn man das HM Update Tool genommen hat brach der bei ca. 80% ab.
Mit flash-ota sollte das Flashen auch mit der 0.6.1er Version vom Bootloader klappen. Der Abstand zwischen CUL und Sensor sollte > 0,5m sein. Andere 868 Mhz Sender stören das Update beim alten Bootloader deutlich mehr als mit der Version 0.7.0. Daher kann es sein dass man mehrere Anläufe braucht.
Ein Update des Bootloaders mit einem Raspberry Pi ist aber auch nicht so schwierig:
http://www.lxccu.com/hb-raspberry-bootloader-update
Gruß
Dirk
Danke für die Hinweise !!
Ich habe nur leider kein Rpi und kein HM USB Adapter :'(
Da ich auf Windows unterwegs bin, hatte ich gehofft, das es mit meinem CUL über FHEM geht.
Vielleicht muss ich mir doch mal so ein HM USB Adapter kaufen.
Du könntest dir ein Linux in einer VM von z.B. Virtualbox installieren.
Damit lässt sich der FW-Update auch mit CUL und Windows erledigen.
Warum das Update mit CUL und FHEM aktuell nicht funktioniert hab ich noch nicht rausgefunden.
Vielleicht hat der eine oder andere dazu ja eine Idee.
Gruß
Dirk
ZitatWarum das Update mit CUL und FHEM aktuell nicht funktioniert hab ich noch nicht rausgefunden.
Vielleicht hat der eine oder andere dazu ja eine Idee.
das eigentliche fhem problem ist, dass der bootloader auf die cb-message wartet, aber fhem keine sendet.
ich hatte mal angefangen, das einzubauen. im prinzip hat das flashen über fhem dann funktioniert. es gab aber noch ein grösseres problem, zumindestens bei mir. und zwar bekommt fhem für das senden der ersten blöcke keine ack. jedenfalls nicht rechtzeitig, sondern stark verzögert. die ack oder nack kommen dann en block später. wenn die übertragung am anfang korrekt war, also alles ack, dann laüft alles weitere prima. ich habe auch nack eingebaut, somit werden ziehmlich viele übertragungsfehler durch wiederholen der blöcke "repariert".
hier mal ein paar logs von verschiedenen übertragungsfehlern:
################################################################################################################################
# übertragungsfehler, die erkannt und behoben wurden:
#
# 1. info 00ca-msg fehlt
# 2. normale 00ca-msg fehlt
#(3.) 20ca-msg (ackreq) fehlt
# 4. 20ca-msg wurde wiederholt
# 5. fehlende 00ca-msg in auf einander folgenden pages
# 6. info- und ackreq-msg fehlen
# 7. fhem startet block nach timeout neu
# 8. normale 00ca-msg fehlt und 20ca-msg wird wiederholt
################################################################################################################################
AskSin OTA Bootloader V0.7.2<\n>
<\n>
TX bootloader sequence<\n>
TX: 14 00 00 10 26 6E 75 00 00 00 00 4B 45 51 31 31 30 39 37 39 37 <\n>
Wait for CB msg<\n>
RX: 0F 0B 00 CB 1A CE 1F 26 6E 75 10 5B 11 F8 15 47 <\n>
Got CB msg<\n>
Switch to 100k mode<\n>
Wait for CB msg<\n>
RX: 27 0D 00 CA 1A CE 1F 26 6E 75 01 00 0C 94 B5 07 0C 94 59 39 0C 94 86 39 0C 94 B3 39 0C 94 94 37 0C 94 93 0B 0C 94 6E 0B <\n>
Got CA msg<\n>
Receive firmware<\n>
RX: 27 0E 00 CA 1A CE 1F 26 6E 75 0C 94 49 0B 0C 94 F8 08 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 <\n>
RX: 27 0F 00 CA 1A CE 1F 26 6E 75 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 E0 39 0C 94 DD 07 0C 94 22 3D 0C 94 70 3D <\n>
RX: 27 10 00 CA 1A CE 1F 26 6E 75 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 29 0A 00 28 00 29 <\n>
RX: 27 11 00 CA 1A CE 1F 26 6E 75 00 20 28 6C 3A 00 4B 6E 6F 77 6E 20 63 6F 6D 6D 61 6E 64 73 3A 00 20 62 79 74 65 73 00 4E <\n>
RX: 27 12 00 CA 1A CE 1F 26 6E 75 6F 74 20 65 6E 6F 75 67 68 20 64 61 74 61 2C 20 6E 65 65 64 20 00 55 6E 72 65 63 6F 67 6E <\n>
RX: 27 13 00 CA 1A CE 1F 26 6E 75 69 7A 65 64 20 63 68 61 72 61 63 74 65 72 3A 20 00 2C 20 6E 78 74 53 3A 00 52 4C 3A 61 64 <\n>
RX: 27 14 00 CA 1A CE 1F 26 6E 75 6A 52 6C 79 2C 20 63 75 72 53 3A 00 2C 20 4F 66 66 54 69 6D 65 3A 00 2C 20 4F 66 66 44 6C <\n>
RX: 1B 15 20 CA 1A CE 1F 26 6E 75 79 3A 00 2C 20 4F 6E 54 69 6D 65 3A 00 2C 20 4F 6E 44 <\n>
.TX ACK<\n>
RX: 1B 1E 20 CA 1A CE 1F 26 6E 75 00 20 6F 66 20 00 0A 67 65 74 4C 69 73 74 46 6F 72 4D <\n>
block(s) missed<\n>
TX NACK<\n>
RX: 27 0B 00 CA 1A CE 1F 26 6E 75 01 00 6C 79 3A 00 2C 20 6E 78 74 53 3A 00 52 4C 3A 74 72 69 67 67 65 72 34 30 2C 20 63 75 <\n>
prevID:, pageNbr:80 00 EA 0F 81 Wrong MsgId!<\n>
RX: 27 0C 00 CA 1A CE 1F 26 6E 75 72 53 3A 00 2C 20 64 75 72 61 54 3A 00 2C 20 72 61 6D 70 54 3A 00 2C 20 6E 78 74 53 3A 00 <\n>
prevID:, pageNbr:FF 00 EA 0F 81 Wrong MsgId!<\n>
blockLen differ pageSize<\n>
RX: 27 0D 00 CA 1A CE 1F 26 6E 75 52 4C 3A 74 72 69 67 67 65 72 31 31 2C 20 76 61 6C 3A 00 2C 20 70 49 64 78 32 3A 20 00 2C <\n>
prevID:, pageNbr:FF 00 EA 0F 81 Wrong MsgId!<\n>
blockLen differ pageSize<\n>
RX: 27 0E 00 CA 1A CE 1F 26 6E 75 20 70 49 64 78 31 3A 20 00 72 65 6D 6F 76 65 50 65 65 72 46 72 6F 6D 4D 73 67 2C 20 63 6E <\n>
prevID:, pageNbr:FF 00 EA 0F 81 Wrong MsgId!<\n>
blockLen differ pageSize<\n>
RX: 27 0F 00 CA 1A CE 1F 26 6E 75 6C 3A 20 00 61 64 64 50 65 65 72 46 72 6F 6D 4D 73 67 2C 20 63 6E 6C 3A 20 00 61 64 64 50 <\n>
prevID:, pageNbr:FF 00 EA 0F 81 Wrong MsgId!<\n>
blockLen differ pageSize<\n>
RX: 27 10 00 CA 1A CE 1F 26 6E 75 65 65 72 46 72 6F 6D 4D 73 67 2C 20 63 6E 6C 3A 20 00 2C 20 64 61 74 61 3A 20 00 73 65 74 <\n>
prevID:, pageNbr:FF 00 EA 0F 81 Wrong MsgId!<\n>
blockLen differ pageSize<\n>
RX: 27 11 00 CA 1A CE 1F 26 6E 75 4C 69 73 74 46 72 6F 6D 4D 73 67 2C 20 6C 65 6E 3A 20 00 2C 20 64 61 74 61 3A 20 00 67 65 <\n>
prevID:, pageNbr:FF 00 EA 0F 81 Wrong MsgId!<\n>
blockLen differ pageSize<\n>
RX: 27 12 00 CA 1A CE 1F 26 6E 75 74 4C 69 73 74 46 6F 72 4D 73 67 32 2C 20 6C 65 6E 3A 20 00 2C 20 73 6C 63 50 74 72 3A 20 <\n>
prevID:, pageNbr:FF 00 EA 0F 81 Wrong MsgId!<\n>
blockLen differ pageSize<\n>
RX: 1B 13 20 CA 1A CE 1F 26 6E 75 00 20 6F 66 20 00 0A 67 65 74 4C 69 73 74 46 6F 72 4D <\n>
prevID:, pageNbr:FF 00 EA 0F 81 Wrong MsgId!<\n>
block(s) missed<\n>
TX NACK<\n>
Timeout
################################################################################################################################
# fehler:
#
################################################################################################################################
RX: 27 EF 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F0 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F1 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F2 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F3 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F4 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F5 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F6 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B F7 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
.TX ACK<\n>
RX: 27 F8 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B F7 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 27 FA 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
blockLen differ pageSize<\n>
RX: 27 FB 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B F7 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 27 FD 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
blockLen differ pageSize<\n>
RX: 27 FE 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FF 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B 00 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 27 F8 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F9 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FA 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FB 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FC 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FD 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FE 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FF 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B 00 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
.TX ACK
################################################################################################################################
# fehler: hier fehlen mehrere blöcke mit hmusb - kann man wohl nichts machen
#
################################################################################################################################
AskSin OTA Bootloader V0.7.2<\n>
<\n>
TX bootloader sequence<\n>
TX: 14 00 00 10 26 6E 75 00 00 00 00 4B 45 51 31 31 30 39 37 39 37 <\n>
Wait for CB msg<\n>
RX: 0A 0A 30 11 1A CE 1F 26 6E 75 CA <\n>
TX NACK<\n>
Data not for us<\n>
Timeout<\n>
CRC fail, Reboot<\n>
<\n>
<\n>
AskSin OTA Bootloader V0.7.2<\n>
<\n>
TX bootloader sequence<\n>
TX: 14 00 00 10 26 6E 75 00 00 00 00 4B 45 51 31 31 30 39 37 39 37 <\n>
Wait for CB msg<\n>
RX: 0F 0B 00 CB 1A CE 1F 26 6E 75 10 5B 11 F8 15 47 <\n>
Got CB msg<\n>
Switch to 100k mode<\n>
Wait for CB msg<\n>
RX: 27 0D 00 CA 1A CE 1F 26 6E 75 01 00 0C 94 B5 07 0C 94 59 39 0C 94 86 39 0C 94 B3 39 0C 94 94 37 0C 94 93 0B 0C 94 6E 0B <\n>
Got CA msg<\n>
Receive firmware<\n>
RX: 27 0E 00 CA 1A CE 1F 26 6E 75 0C 94 49 0B 0C 94 F8 08 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 <\n>
RX: 27 0F 00 CA 1A CE 1F 26 6E 75 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 E0 39 0C 94 DD 07 0C 94 22 3D 0C 94 70 3D <\n>
RX: 27 10 00 CA 1A CE 1F 26 6E 75 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 29 0A 00 28 00 29 <\n>
RX: 27 11 00 CA 1A CE 1F 26 6E 75 00 20 28 6C 3A 00 4B 6E 6F 77 6E 20 63 6F 6D 6D 61 6E 64 73 3A 00 20 62 79 74 65 73 00 4E <\n>
RX: 27 12 00 CA 1A CE 1F 26 6E 75 6F 74 20 65 6E 6F 75 67 68 20 64 61 74 61 2C 20 6E 65 65 64 20 00 55 6E 72 65 63 6F 67 6E <\n>
RX: 27 13 00 CA 1A CE 1F 26 6E 75 69 7A 65 64 20 63 68 61 72 61 63 74 65 72 3A 20 00 2C 20 6E 78 74 53 3A 00 52 4C 3A 61 64 <\n>
RX: 27 14 00 CA 1A CE 1F 26 6E 75 6A 52 6C 79 2C 20 63 75 72 53 3A 00 2C 20 4F 66 66 54 69 6D 65 3A 00 2C 20 4F 66 66 44 6C <\n>
RX: 1B 15 20 CA 1A CE 1F 26 6E 75 79 3A 00 2C 20 4F 6E 54 69 6D 65 3A 00 2C 20 4F 6E 44 <\n>
.TX ACK<\n>
RX: 27 ED 00 CA 1A CE 1F 26 6E 75 01 00 73 67 32 2C 20 6D 73 67 50 74 72 3A 20 00 2C 20 70 65 65 72 3A 20 00 4C 6F 61 64 69 <\n>
RX: 27 EE 00 CA 1A CE 1F 26 6E 75 6E 67 20 6C 69 73 74 33 20 66 6F 72 20 63 6E 6C 3A 20 00 2C 20 64 61 74 61 3A 20 00 67 65 <\n>
RX: 27 EF 00 CA 1A CE 1F 26 6E 75 74 52 65 67 2C 20 6C 65 6E 3A 20 00 2C 20 70 65 65 72 49 64 78 3A 20 00 2C 20 70 68 79 4C <\n>
RX: 27 F0 00 CA 1A CE 1F 26 6E 75 65 6E 3A 20 00 2C 20 70 68 79 41 64 64 72 3A 20 00 2C 20 73 6C 63 4C 65 6E 3A 20 00 67 65 <\n>
RX: 27 F1 00 CA 1A CE 1F 26 6E 75 74 53 6C 69 63 65 44 65 74 61 69 6C 2C 20 73 6C 63 50 74 72 3A 20 00 2C 20 73 69 7A 65 20 <\n>
RX: 27 F2 00 CA 1A CE 1F 26 6E 75 6F 66 3A 20 00 4C 6F 61 64 69 6E 67 20 50 65 65 72 44 42 2C 20 73 74 61 72 74 73 3A 20 00 <\n>
RX: 27 F3 00 CA 1A CE 1F 26 6E 75 64 6F 6E 65 0A 00 66 69 72 73 74 20 73 74 61 72 74 20 64 65 74 65 63 74 65 64 2C 20 66 6F <\n>
RX: 27 F4 00 CA 1A CE 1F 26 6E 75 72 6D 61 74 69 6E 67 20 65 65 70 72 6F 6D 2E 2E 2E 0A 00 0A 0A 00 55 6E 6B 6E 6F 77 6E 20 <\n>
RX: 1B F5 20 CA 1A CE 1F 26 6E 75 4D 65 73 73 61 67 65 2C 20 70 6C 65 61 73 65 20 72 65 <\n>
.TX ACK
################################################################################################################################
# fehler: jetzt fehlt ein ganzer block mit hmusb - kann man wohl nichts machen
#
################################################################################################################################
Wait for CB msg<\n>
RX: 27 0D 00 CA 1A CE 1F 26 6E 75 01 00 0C 94 B5 07 0C 94 59 39 0C 94 86 39 0C 94 B3 39 0C 94 94 37 0C 94 93 0B 0C 94 6E 0B <\n>
Got CA msg<\n>
Receive firmware<\n>
RX: 27 0E 00 CA 1A CE 1F 26 6E 75 0C 94 49 0B 0C 94 F8 08 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 <\n>
RX: 27 0F 00 CA 1A CE 1F 26 6E 75 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 E0 39 0C 94 DD 07 0C 94 22 3D 0C 94 70 3D <\n>
RX: 27 10 00 CA 1A CE 1F 26 6E 75 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 29 0A 00 28 00 29 <\n>
RX: 27 11 00 CA 1A CE 1F 26 6E 75 00 20 28 6C 3A 00 4B 6E 6F 77 6E 20 63 6F 6D 6D 61 6E 64 73 3A 00 20 62 79 74 65 73 00 4E <\n>
RX: 27 12 00 CA 1A CE 1F 26 6E 75 6F 74 20 65 6E 6F 75 67 68 20 64 61 74 61 2C 20 6E 65 65 64 20 00 55 6E 72 65 63 6F 67 6E <\n>
RX: 27 13 00 CA 1A CE 1F 26 6E 75 69 7A 65 64 20 63 68 61 72 61 63 74 65 72 3A 20 00 2C 20 6E 78 74 53 3A 00 52 4C 3A 61 64 <\n>
RX: 27 14 00 CA 1A CE 1F 26 6E 75 6A 52 6C 79 2C 20 63 75 72 53 3A 00 2C 20 4F 66 66 54 69 6D 65 3A 00 2C 20 4F 66 66 44 6C <\n>
RX: 1B 15 20 CA 1A CE 1F 26 6E 75 79 3A 00 2C 20 4F 6E 54 69 6D 65 3A 00 2C 20 4F 6E 44 <\n>
.TX ACK<\n>
RX: 27 1F 00 CA 1A CE 1F 26 6E 75 01 00 73 67 32 2C 20 6D 73 67 50 74 72 3A 20 00 2C 20 70 65 65 72 3A 20 00 4C 6F 61 64 69 <\n>
RX: 27 20 00 CA 1A CE 1F 26 6E 75 6E 67 20 6C 69 73 74 33 20 66 6F 72 20 63 6E 6C 3A 20 00 2C 20 64 61 74 61 3A 20 00 67 65 <\n>
RX: 27 21 00 CA 1A CE 1F 26 6E 75 74 52 65 67 2C 20 6C 65 6E 3A 20 00 2C 20 70 65 65 72 49 64 78 3A 20 00 2C 20 70 68 79 4C <\n>
RX: 27 22 00 CA 1A CE 1F 26 6E 75 65 6E 3A 20 00 2C 20 70 68 79 41 64 64 72 3A 20 00 2C 20 73 6C 63 4C 65 6E 3A 20 00 67 65 <\n>
RX: 27 23 00 CA 1A CE 1F 26 6E 75 74 53 6C 69 63 65 44 65 74 61 69 6C 2C 20 73 6C 63 50 74 72 3A 20 00 2C 20 73 69 7A 65 20 <\n>
RX: 27 24 00 CA 1A CE 1F 26 6E 75 6F 66 3A 20 00 4C 6F 61 64 69 6E 67 20 50 65 65 72 44 42 2C 20 73 74 61 72 74 73 3A 20 00 <\n>
RX: 27 25 00 CA 1A CE 1F 26 6E 75 64 6F 6E 65 0A 00 66 69 72 73 74 20 73 74 61 72 74 20 64 65 74 65 63 74 65 64 2C 20 66 6F <\n>
RX: 27 26 00 CA 1A CE 1F 26 6E 75 72 6D 61 74 69 6E 67 20 65 65 70 72 6F 6D 2E 2E 2E 0A 00 0A 0A 00 55 6E 6B 6E 6F 77 6E 20 <\n>
RX: 1B 27 20 CA 1A CE 1F 26 6E 75 4D 65 73 73 61 67 65 2C 20 70 6C 65 61 73 65 20 72 65 <\n>
.TX ACK
################################################################################################################################
# fehler: hier fehlen mehrere blöcke mit hmusb - kann man wohl nichts machen, aber wurde erkannt und timeout
#
################################################################################################################################
Wait for CB msg<\n>
RX: 27 0D 00 CA 1A CE 1F 26 6E 75 01 00 0C 94 B5 07 0C 94 59 39 0C 94 86 39 0C 94 B3 39 0C 94 94 37 0C 94 93 0B 0C 94 6E 0B <\n>
Got CA msg<\n>
Receive firmware<\n>
RX: 27 0E 00 CA 1A CE 1F 26 6E 75 0C 94 49 0B 0C 94 F8 08 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 <\n>
RX: 27 0F 00 CA 1A CE 1F 26 6E 75 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 E0 39 0C 94 DD 07 0C 94 22 3D 0C 94 70 3D <\n>
RX: 27 10 00 CA 1A CE 1F 26 6E 75 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 29 0A 00 28 00 29 <\n>
RX: 27 11 00 CA 1A CE 1F 26 6E 75 00 20 28 6C 3A 00 4B 6E 6F 77 6E 20 63 6F 6D 6D 61 6E 64 73 3A 00 20 62 79 74 65 73 00 4E <\n>
RX: 27 12 00 CA 1A CE 1F 26 6E 75 6F 74 20 65 6E 6F 75 67 68 20 64 61 74 61 2C 20 6E 65 65 64 20 00 55 6E 72 65 63 6F 67 6E <\n>
RX: 27 13 00 CA 1A CE 1F 26 6E 75 69 7A 65 64 20 63 68 61 72 61 63 74 65 72 3A 20 00 2C 20 6E 78 74 53 3A 00 52 4C 3A 61 64 <\n>
RX: 27 14 00 CA 1A CE 1F 26 6E 75 6A 52 6C 79 2C 20 63 75 72 53 3A 00 2C 20 4F 66 66 54 69 6D 65 3A 00 2C 20 4F 66 66 44 6C <\n>
RX: 1B 15 20 CA 1A CE 1F 26 6E 75 79 3A 00 2C 20 4F 6E 54 69 6D 65 3A 00 2C 20 4F 6E 44 <\n>
.TX ACK<\n>
RX: 1B 27 20 CA 1A CE 1F 26 6E 75 4D 65 73 73 61 67 65 2C 20 70 6C 65 61 73 65 20 72 65 <\n>
a block is missing<\n>
TX NACK<\n>
RX: 27 0B 00 CA 1A CE 1F 26 6E 75 01 00 73 67 32 2C 20 6D 73 67 50 74 72 3A 20 00 2C 20 70 65 65 72 3A 20 00 4C 6F 61 64 69 <\n>
Wrong MsgId!<\n>
RX: 27 0C 00 CA 1A CE 1F 26 6E 75 6E 67 20 6C 69 73 74 33 20 66 6F 72 20 63 6E 6C 3A 20 00 2C 20 64 61 74 61 3A 20 00 67 65 <\n>
Wrong MsgId!<\n>
RX: 27 0D 00 CA 1A CE 1F 26 6E 75 74 52 65 67 2C 20 6C 65 6E 3A 20 00 2C 20 70 65 65 72 49 64 78 3A 20 00 2C 20 70 68 79 4C <\n>
Wrong MsgId!<\n>
RX: 27 0E 00 CA 1A CE 1F 26 6E 75 65 6E 3A 20 00 2C 20 70 68 79 41 64 64 72 3A 20 00 2C 20 73 6C 63 4C 65 6E 3A 20 00 67 65 <\n>
Wrong MsgId!<\n>
RX: 27 0F 00 CA 1A CE 1F 26 6E 75 74 53 6C 69 63 65 44 65 74 61 69 6C 2C 20 73 6C 63 50 74 72 3A 20 00 2C 20 73 69 7A 65 20 <\n>
Wrong MsgId!<\n>
RX: 27 10 00 CA 1A CE 1F 26 6E 75 6F 66 3A 20 00 4C 6F 61 64 69 6E 67 20 50 65 65 72 44 42 2C 20 73 74 61 72 74 73 3A 20 00 <\n>
Wrong MsgId!<\n>
RX: 27 11 00 CA 1A CE 1F 26 6E 75 64 6F 6E 65 0A 00 66 69 72 73 74 20 73 74 61 72 74 20 64 65 74 65 63 74 65 64 2C 20 66 6F <\n>
Wrong MsgId!<\n>
RX: 27 12 00 CA 1A CE 1F 26 6E 75 72 6D 61 74 69 6E 67 20 65 65 70 72 6F 6D 2E 2E 2E 0A 00 0A 0A 00 55 6E 6B 6E 6F 77 6E 20 <\n>
Wrong MsgId!<\n>
RX: 1B 13 20 CA 1A CE 1F 26 6E 75 4D 65 73 73 61 67 65 2C 20 70 6C 65 61 73 65 20 72 65 <\n>
Wrong MsgId!<\n>
RX: 1B 13 20 CA 1A CE 1F 26 6E 75 4D 65 73 73 61 67 65 2C 20 70 6C 65 61 73 65 20 72 65 <\n>
Wrong MsgId!<\n>
RX: 1B 13 20 CA 1A CE 1F 26 6E 75 4D 65 73 73 61 67 65 2C 20 70 6C 65 61 73 65 20 72 65 <\n>
Wrong MsgId!<\n>
Timeout<\n>
CRC OK<\n>
Start App<\n>
2014.10.29 12:35:25.205 5: CUL_HM fwUpdate write block 154 of 224: 9 messages
2014.10.29 12:35:25.298 4: CUL_send: cul868As 27 6E 00CA 1ACE1F 266E75 0100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.325 4: CUL_send: cul868As 27 6F 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.351 4: CUL_send: cul868As 27 70 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.377 4: CUL_send: cul868As 27 71 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.404 4: CUL_send: cul868As 27 72 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.430 4: CUL_send: cul868As 27 73 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.457 4: CUL_send: cul868As 27 74 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.483 4: CUL_send: cul868As 27 75 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.509 4: CUL_send: cul868As 1B 76 20CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.553 4: CUL_Parse: cul868 A 0A 76 8002 266E75 1ACE1F 003C -44
2014.10.29 12:35:25.562 5: CUL_HM fwUpdate write block 155 of 224: 9 messages
2014.10.29 12:35:25.656 4: CUL_send: cul868As 27 77 00CA 1ACE1F 266E75 0100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.682 4: CUL_send: cul868As 27 78 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.709 4: CUL_send: cul868As 27 79 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.735 4: CUL_send: cul868As 27 7A 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.761 4: CUL_send: cul868As 27 7B 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.787 4: CUL_send: cul868As 27 7C 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.813 4: CUL_send: cul868As 27 7D 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.840 4: CUL_send: cul868As 27 7E 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:25.865 4: CUL_send: cul868As 1B 7F 20CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:30.903 5: CUL_HM fwUpdate write block 155 of 224: 9 messages
2014.10.29 12:35:30.908 4: CUL_send: cul868As 27 77 00CA 1ACE1F 266E75 0100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:30.933 4: CUL_send: cul868As 27 78 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:30.960 4: CUL_send: cul868As 27 79 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:30.986 4: CUL_send: cul868As 27 7A 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:31.013 4: CUL_send: cul868As 27 7B 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:31.043 4: CUL_send: cul868As 27 7C 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:31.069 4: CUL_send: cul868As 27 7D 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:31.096 4: CUL_send: cul868As 27 7E 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:31.123 4: CUL_send: cul868As 1B 7F 20CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:31.177 4: CUL_Parse: cul868 A 0A 7F 8002 266E75 1ACE1F 803B -44.5
2014.10.29 12:35:36.160 5: CUL_HM fwUpdate write block 155 of 224: 9 messages
2014.10.29 12:35:36.165 4: CUL_send: cul868As 27 77 00CA 1ACE1F 266E75 0100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:36.192 4: CUL_send: cul868As 27 78 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:36.217 4: CUL_send: cul868As 27 79 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:36.244 4: CUL_send: cul868As 27 7A 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:36.270 4: CUL_send: cul868As 27 7B 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:36.296 4: CUL_send: cul868As 27 7C 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:36.323 4: CUL_send: cul868As 27 7D 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:36.349 4: CUL_send: cul868As 27 7E 00CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:36.376 4: CUL_send: cul868As 1B 7F 20CA 1ACE1F 266E75 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2014.10.29 12:35:36.433 4: CUL_Parse: cul868 A 0A 7F 8002 266E75 1ACE1F 003B -44.5
################################################################################################################################
# 1. info 00ca msg (F5) mit block size info fehlt
#
################################################################################################################################
RX: 27 EC 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 ED 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 EE 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 EF 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F0 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F1 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F2 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F3 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B F4 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
.TX ACK
RX: 27 F6 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
blockLen differ pageSize<\n>
RX: 27 F7 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F8 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F9 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FA 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FB 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FC 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B FD 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 27 F5 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F6 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F7 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F8 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 F9 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FA 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FB 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 FC 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B FD 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
.TX ACK
################################################################################################################################
# 2. normale 00ca msg (AB) fehlt.
#
################################################################################################################################
RX: 27 9F 00 CA 1A CE 1F 26 6E 75 01 00 E1 1D F9 1F 63 9F B0 0D E1 1D F9 1F BD 01 CF 01 11 24 08 95 A1 E2 1A 2E AA 1B BB 1B <\n>
RX: 27 A0 00 CA 1A CE 1F 26 6E 75 FD 01 0D C0 AA 1F BB 1F EE 1F FF 1F A2 17 B3 07 E4 07 F5 07 20 F0 A2 1B B3 0B E4 0B F5 0B <\n>
RX: 27 A1 00 CA 1A CE 1F 26 6E 75 66 1F 77 1F 88 1F 99 1F 1A 94 69 F7 60 95 70 95 80 95 90 95 9B 01 AC 01 BD 01 CF 01 08 95 <\n>
RX: 27 A2 00 CA 1A CE 1F 26 6E 75 97 FB 09 2E 05 26 0E D0 57 FD 04 D0 D7 DF 0A D0 00 1C 38 F4 50 95 40 95 30 95 21 95 3F 4F <\n>
RX: 27 A3 00 CA 1A CE 1F 26 6E 75 4F 4F 5F 4F 08 95 F6 F7 90 95 80 95 70 95 61 95 7F 4F 8F 4F 9F 4F 08 95 EE 0F FF 1F 05 90 <\n>
RX: 27 A4 00 CA 1A CE 1F 26 6E 75 F4 91 E0 2D 09 94 2F 92 3F 92 4F 92 5F 92 6F 92 7F 92 8F 92 9F 92 AF 92 BF 92 CF 92 DF 92 <\n>
RX: 27 A5 00 CA 1A CE 1F 26 6E 75 EF 92 FF 92 0F 93 1F 93 CF 93 DF 93 CD B7 DE B7 CA 1B DB 0B 0F B6 F8 94 DE BF 0F BE CD BF <\n>
RX: 27 A6 00 CA 1A CE 1F 26 6E 75 09 94 2A 88 39 88 48 88 5F 84 6E 84 7D 84 8C 84 9B 84 AA 84 B9 84 C8 84 DF 80 EE 80 FD 80 <\n>
RX: 1B A7 20 CA 1A CE 1F 26 6E 75 0C 81 1B 81 AA 81 B9 81 CE 0F D1 1D 0F B6 F8 94 DE BF <\n>
.TX ACK<\n>
RX: 27 A8 00 CA 1A CE 1F 26 6E 75 01 00 0F BE CD BF ED 01 08 95 F8 94 FF CF 00 6C 6F 61 64 44 65 66 61 75 6C 74 52 65 67 73 <\n>
RX: 27 A9 00 CA 1A CE 1F 26 6E 75 65 74 3A 20 63 6E 6C 3D 00 20 64 75 61 6C 3A 20 00 20 72 65 67 43 68 61 6E 5F 6C 65 6E 3A <\n>
RX: 27 AA 00 CA 1A CE 1F 26 6E 75 20 00 20 6C 73 74 3A 20 00 20 69 64 78 3A 20 00 2C 20 72 65 74 3A 20 00 2C 20 73 6C 63 45 <\n>
RX: 27 AC 00 CA 1A CE 1F 26 6E 75 6F 6E 20 70 72 65 73 73 2C 20 63 6E 6C 3A 20 00 2C 20 6C 6F 6E 67 20 70 72 65 73 73 3A 20 <\n>
RX: 27 AD 00 CA 1A CE 1F 26 6E 75 00 0A 0A 00 63 3A 00 20 63 53 3A 00 20 6E 53 3A 00 69 3A 00 2C 20 73 3A 00 63 74 72 3A 00 <\n>
RX: 27 AE 00 CA 1A CE 1F 26 6E 75 2C 20 62 6F 6F 74 3A 00 01 00 00 00 01 CC 05 D3 05 D6 05 D7 05 DA 05 DB 05 DC 05 F2 05 F3 <\n>
RX: 27 AF 00 CA 1A CE 1F 26 6E 75 05 80 00 C6 06 00 00 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 01 00 0A 00 32 00 64 <\n>
RX: 1B B0 20 CA 1A CE 1F 26 6E 75 00 58 02 B8 0B 70 17 A0 8C 00 00 00 00 06 06 06 05 01 <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 27 A8 00 CA 1A CE 1F 26 6E 75 01 00 0F BE CD BF ED 01 08 95 F8 94 FF CF 00 6C 6F 61 64 44 65 66 61 75 6C 74 52 65 67 73 <\n>
RX: 27 A9 00 CA 1A CE 1F 26 6E 75 65 74 3A 20 63 6E 6C 3D 00 20 64 75 61 6C 3A 20 00 20 72 65 67 43 68 61 6E 5F 6C 65 6E 3A <\n>
RX: 27 AA 00 CA 1A CE 1F 26 6E 75 20 00 20 6C 73 74 3A 20 00 20 69 64 78 3A 20 00 2C 20 72 65 74 3A 20 00 2C 20 73 6C 63 45 <\n>
RX: 27 AB 00 CA 1A CE 1F 26 6E 75 6E 64 3A 20 00 0A 0A 00 70 6C 3A 20 00 0A 77 72 69 74 65 3A 20 00 3A 00 20 00 62 75 74 74 <\n>
RX: 27 AC 00 CA 1A CE 1F 26 6E 75 6F 6E 20 70 72 65 73 73 2C 20 63 6E 6C 3A 20 00 2C 20 6C 6F 6E 67 20 70 72 65 73 73 3A 20 <\n>
RX: 27 AD 00 CA 1A CE 1F 26 6E 75 00 0A 0A 00 63 3A 00 20 63 53 3A 00 20 6E 53 3A 00 69 3A 00 2C 20 73 3A 00 63 74 72 3A 00 <\n>
RX: 27 AE 00 CA 1A CE 1F 26 6E 75 2C 20 62 6F 6F 74 3A 00 01 00 00 00 01 CC 05 D3 05 D6 05 D7 05 DA 05 DB 05 DC 05 F2 05 F3 <\n>
RX: 27 AF 00 CA 1A CE 1F 26 6E 75 05 80 00 C6 06 00 00 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 01 00 0A 00 32 00 64 <\n>
RX: 1B B0 20 CA 1A CE 1F 26 6E 75 00 58 02 B8 0B 70 17 A0 8C 00 00 00 00 06 06 06 05 01 <\n>
.TX ACK
################################################################################################################################
# 3. 20ca-msg fehlt
#
################################################################################################################################
################################################################################################################################
# 4. wiederholung 20ca-msg (CC)
#
################################################################################################################################
RX: 27 C4 00 CA 1A CE 1F 26 6E 75 01 00 41 E2 50 E1 9B 01 22 0F 33 1F 87 FD 21 60 77 FD 02 C0 B9 01 03 C0 B9 01 64 27 75 27 <\n>
RX: 27 C5 00 CA 1A CE 1F 26 6E 75 9F 5F 98 30 11 F0 88 0F EF CF CB 01 08 95 CF 93 DF 93 6F EF 7F EF C0 E0 D0 E0 FE 01 84 91 <\n>
RX: 27 C6 00 CA 1A CE 1F 26 6E 75 0E 94 7F 71 BC 01 21 96 FF ED CE 3F DF 07 B1 F7 80 E0 0E 94 7F 71 BC 01 80 E0 0E 94 7F 71 <\n>
RX: 27 C7 00 CA 1A CE 1F 26 6E 75 FE 01 25 91 34 91 40 E0 28 17 39 07 09 F4 41 E0 84 2F DF 91 CF 91 08 95 50 E0 A0 ED B7 E0 <\n>
RX: 27 C8 00 CA 1A CE 1F 26 6E 75 19 C0 28 9A 20 E0 30 E0 05 C0 FD 01 31 97 F1 F7 2F 5F 3F 4F 28 17 39 07 C0 F3 28 98 20 E0 <\n>
RX: 27 C9 00 CA 1A CE 1F 26 6E 75 30 E0 05 C0 FD 01 31 97 F1 F7 2F 5F 3F 4F 26 17 37 07 C0 F3 5F 5F 54 17 28 F3 08 95 1F 92 <\n>
RX: 27 CA 00 CA 1A CE 1F 26 6E 75 0F 92 0F B6 0F 92 11 24 8F 93 9F 93 16 BC 80 91 1D 01 90 91 1E 01 01 96 90 93 1E 01 80 93 <\n>
RX: 27 CB 00 CA 1A CE 1F 26 6E 75 1D 01 9F 91 8F 91 0F 90 0F BE 0F 90 1F 90 18 95 1F 92 0F 92 0F B6 0F 92 11 24 2F 93 3F 93 <\n>
RX: 1B CC 20 CA 1A CE 1F 26 6E 75 4F 93 5F 93 6F 93 7F 93 8F 93 9F 93 AF 93 BF 93 EF 93 <\n>
.TX ACK<\n>
RX: 1B CC 20 CA 1A CE 1F 26 6E 75 4F 93 5F 93 6F 93 7F 93 8F 93 9F 93 AF 93 BF 93 EF 93 <\n>
Retransmit, reflash!<\n>
TX ACK<\n>
RX: 27 CD 00 CA 1A CE 1F 26 6E 75 01 00 FF 93 F8 94 81 EB 91 E0 0E 94 56 76 88 23 19 F0 81 E0 80 93 1A 01 78 94 FF 91 EF 91 <\n>
RX: 27 CE 00 CA 1A CE 1F 26 6E 75 BF 91 AF 91 9F 91 8F 91 7F 91 6F 91 5F 91 4F 91 3F 91 2F 91 0F 90 0F BE 0F 90 1F 90 18 95 <\n>
RX: 27 CF 00 CA 1A CE 1F 26 6E 75 EC EF FF ED 85 91 94 91 81 51 97 44 89 F4 86 E8 91 EE 0E 94 EA 77 80 E0 9A EF 01 97 F1 F7 <\n>
RX: 27 D0 00 CA 1A CE 1F 26 6E 75 82 E3 90 E0 62 E3 70 E0 4A E0 0E 94 B8 71 0E 94 80 7F 8B E7 91 EE 0E 94 EA 77 80 E0 9A EF <\n>
RX: 27 D1 00 CA 1A CE 1F 26 6E 75 01 97 F1 F7 5F 98 28 98 F8 94 85 B7 98 2F 91 60 95 BF 8D 7F 85 BF E0 E0 F0 E0 09 95 08 95 <\n>
RX: 27 D2 00 CA 1A CE 1F 26 6E 75 0E 94 95 71 88 23 29 F0 81 EC 91 EE 0E 94 EA 77 08 95 80 ED 97 E0 61 E0 70 E0 41 E0 0E 94 <\n>
RX: 27 D3 00 CA 1A CE 1F 26 6E 75 B8 71 8F EA 91 EE 0E 94 EA 77 A8 95 2E E0 88 E1 90 E0 0F B6 F8 94 A8 95 80 93 60 00 0F BE <\n>
RX: 27 D4 00 CA 1A CE 1F 26 6E 75 20 93 60 00 FF CF 80 91 1D 01 90 91 1E 01 81 53 95 47 40 F0 82 E7 91 EE 0E 94 EA 77 0E 94 <\n>
RX: 1B D5 20 CA 1A CE 1F 26 6E 75 4A 72 0E 94 1D 72 08 95 1F 93 CF 93 DF 93 DA 01 61 30 <\n>
.TX ACK
################################################################################################################################
# 5. in 2 aufeinander folgenden blöcken fehlt jeweils eine 00ca-msg (63,60)
#
################################################################################################################################
RX: 27 55 00 CA 1A CE 1F 26 6E 75 01 00 70 65 65 72 3A 20 00 43 4F 4E 46 49 47 5F 50 45 45 52 5F 52 45 4D 4F 56 45 3B 20 63 <\n>
RX: 27 56 00 CA 1A CE 1F 26 6E 75 6E 6C 3A 20 00 2C 20 70 43 6E 6C 42 3A 20 00 2C 20 70 43 6E 6C 41 3A 20 00 2C 20 70 65 65 <\n>
RX: 27 57 00 CA 1A CE 1F 26 6E 75 72 3A 20 00 43 4F 4E 46 49 47 5F 50 45 45 52 5F 41 44 44 3B 20 63 6E 6C 3A 20 00 2C 20 6E <\n>
RX: 27 58 00 CA 1A CE 1F 26 6E 75 61 3A 20 00 2C 20 70 43 6E 6C 42 3A 20 00 2C 20 70 43 6E 6C 41 3A 20 00 20 20 20 20 20 20 <\n>
RX: 27 59 00 CA 1A CE 1F 26 6E 75 20 20 20 20 20 20 20 20 2C 20 63 6C 61 73 73 3A 20 00 2C 20 73 65 72 69 61 6C 3A 20 00 2C <\n>
RX: 27 5A 00 CA 1A CE 1F 26 6E 75 20 74 79 70 65 3A 20 00 44 45 56 49 43 45 5F 49 4E 46 4F 3B 20 66 77 3A 20 00 20 20 20 00 <\n>
RX: 27 5B 00 CA 1A CE 1F 26 6E 75 53 2D 20 00 20 73 74 61 72 74 20 77 61 74 63 68 64 6F 67 0A 00 14 F0 A9 4B 45 51 31 31 30 <\n>
RX: 27 5C 00 CA 1A CE 1F 26 6E 75 39 37 39 37 10 41 01 00 20 20 20 77 72 69 74 65 20 64 61 74 61 2C 20 62 75 74 20 6E 6F 74 <\n>
RX: 1B 5D 20 CA 1A CE 1F 26 6E 75 20 69 6E 20 63 6F 6E 66 69 67 20 6D 6F 64 65 0A 00 2D <\n>
.TX ACK<\n>
RX: 27 5E 00 CA 1A CE 1F 26 6E 75 01 00 3E 20 4E 41 20 00 3C 2D 20 00 0A 55 4E 4B 4E 4F 57 4E 20 4D 45 53 53 41 47 45 2C 20 <\n>
RX: 27 5F 00 CA 1A CE 1F 26 6E 75 50 4C 45 41 53 45 20 52 45 50 4F 52 54 21 0A 0A 00 20 20 20 62 6F 6F 74 20 63 6D 64 20 69 <\n>
RX: 27 60 00 CA 1A CE 1F 26 6E 75 73 20 69 67 6E 6F 72 65 64 0A 00 6E 6F 74 20 72 65 63 65 69 76 65 64 20 62 65 66 6F 72 65 <\n>
RX: 27 61 00 CA 1A CE 1F 26 6E 75 2E 2E 2E 0A 00 61 6C 72 65 61 64 79 20 72 65 63 65 69 76 65 64 20 2D 20 73 6B 69 70 0A 00 <\n>
RX: 27 62 00 CA 1A CE 1F 26 6E 75 20 20 20 72 65 70 65 61 74 65 64 20 6D 65 73 73 61 67 65 3B 20 00 6C 3E 20 00 62 3E 20 00 <\n>
RX: 27 64 00 CA 1A CE 1F 26 6E 75 41 64 64 72 09 70 68 79 4C 65 6E 09 6C 69 73 74 09 70 65 65 72 0A 00 20 62 79 74 65 0A 00 <\n>
RX: 27 65 00 CA 1A CE 1F 26 6E 75 0A 50 65 65 72 20 44 61 74 61 62 61 73 65 2C 20 73 69 7A 65 3A 20 00 63 6E 6C 09 6C 73 74 <\n>
RX: 1B 66 20 CA 1A CE 1F 26 6E 75 09 73 6C 63 50 74 72 09 73 6C 63 45 6E 64 09 70 68 79 <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 27 5E 00 CA 1A CE 1F 26 6E 75 01 00 3E 20 4E 41 20 00 3C 2D 20 00 0A 55 4E 4B 4E 4F 57 4E 20 4D 45 53 53 41 47 45 2C 20 <\n>
RX: 27 5F 00 CA 1A CE 1F 26 6E 75 50 4C 45 41 53 45 20 52 45 50 4F 52 54 21 0A 0A 00 20 20 20 62 6F 6F 74 20 63 6D 64 20 69 <\n>
RX: 27 61 00 CA 1A CE 1F 26 6E 75 2E 2E 2E 0A 00 61 6C 72 65 61 64 79 20 72 65 63 65 69 76 65 64 20 2D 20 73 6B 69 70 0A 00 <\n>
RX: 27 63 00 CA 1A CE 1F 26 6E 75 2D 3E 20 00 63 6E 6C 09 70 49 64 78 09 73 6C 63 50 74 72 09 73 6C 63 45 6E 64 09 70 68 79 <\n>
RX: 27 64 00 CA 1A CE 1F 26 6E 75 41 64 64 72 09 70 68 79 4C 65 6E 09 6C 69 73 74 09 70 65 65 72 0A 00 20 62 79 74 65 0A 00 <\n>
RX: 27 65 00 CA 1A CE 1F 26 6E 75 0A 50 65 65 72 20 44 61 74 61 62 61 73 65 2C 20 73 69 7A 65 3A 20 00 63 6E 6C 09 6C 73 74 <\n>
RX: 1B 66 20 CA 1A CE 1F 26 6E 75 09 73 6C 63 50 74 72 09 73 6C 63 45 6E 64 09 70 68 79 <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 27 5E 00 CA 1A CE 1F 26 6E 75 01 00 3E 20 4E 41 20 00 3C 2D 20 00 0A 55 4E 4B 4E 4F 57 4E 20 4D 45 53 53 41 47 45 2C 20 <\n>
RX: 27 5F 00 CA 1A CE 1F 26 6E 75 50 4C 45 41 53 45 20 52 45 50 4F 52 54 21 0A 0A 00 20 20 20 62 6F 6F 74 20 63 6D 64 20 69 <\n>
RX: 27 60 00 CA 1A CE 1F 26 6E 75 73 20 69 67 6E 6F 72 65 64 0A 00 6E 6F 74 20 72 65 63 65 69 76 65 64 20 62 65 66 6F 72 65 <\n>
RX: 27 61 00 CA 1A CE 1F 26 6E 75 2E 2E 2E 0A 00 61 6C 72 65 61 64 79 20 72 65 63 65 69 76 65 64 20 2D 20 73 6B 69 70 0A 00 <\n>
RX: 27 62 00 CA 1A CE 1F 26 6E 75 20 20 20 72 65 70 65 61 74 65 64 20 6D 65 73 73 61 67 65 3B 20 00 6C 3E 20 00 62 3E 20 00 <\n>
RX: 27 63 00 CA 1A CE 1F 26 6E 75 2D 3E 20 00 63 6E 6C 09 70 49 64 78 09 73 6C 63 50 74 72 09 73 6C 63 45 6E 64 09 70 68 79 <\n>
RX: 27 64 00 CA 1A CE 1F 26 6E 75 41 64 64 72 09 70 68 79 4C 65 6E 09 6C 69 73 74 09 70 65 65 72 0A 00 20 62 79 74 65 0A 00 <\n>
RX: 27 65 00 CA 1A CE 1F 26 6E 75 0A 50 65 65 72 20 44 61 74 61 62 61 73 65 2C 20 73 69 7A 65 3A 20 00 63 6E 6C 09 6C 73 74 <\n>
RX: 1B 66 20 CA 1A CE 1F 26 6E 75 09 73 6C 63 50 74 72 09 73 6C 63 45 6E 64 09 70 68 79 <\n>
.TX ACK
################################################################################################################################
# 6. worst case: 1. 00ca msg (55) mit block size info fehlt und 20ca msg (5D) fehlt auch.
# ??? eigentlich würde ich eine wiederholung der 20ca msg erwarten.
################################################################################################################################
RX: 27 4C 00 CA 1A CE 1F 26 6E 75 01 00 53 5F 52 45 51 55 45 53 54 2C 20 63 6E 6C 3A 20 00 50 41 49 52 5F 53 45 52 49 41 4C <\n>
RX: 27 4D 00 CA 1A CE 1F 26 6E 75 2C 20 73 65 72 69 61 6C 3A 20 00 43 4F 4E 46 49 47 5F 53 45 52 49 41 4C 5F 52 45 51 00 2C <\n>
RX: 27 4E 00 CA 1A CE 1F 26 6E 75 20 64 61 74 61 3A 20 00 43 4F 4E 46 49 47 5F 57 52 49 54 45 5F 49 4E 44 45 58 3B 20 63 6E <\n>
RX: 27 4F 00 CA 1A CE 1F 26 6E 75 6C 3A 20 00 43 4F 4E 46 49 47 5F 45 4E 44 3B 20 63 6E 6C 3A 20 00 2C 20 6C 73 74 3A 20 00 <\n>
RX: 27 50 00 CA 1A CE 1F 26 6E 75 2C 20 70 43 6E 6C 3A 20 00 2C 20 70 65 65 72 3A 20 00 43 4F 4E 46 49 47 5F 53 54 41 52 54 <\n>
RX: 27 51 00 CA 1A CE 1F 26 6E 75 3B 20 63 6E 6C 3A 20 00 2C 20 6C 73 74 3A 20 00 2C 20 70 43 6E 6C 3A 20 00 2C 20 70 65 65 <\n>
RX: 27 52 00 CA 1A CE 1F 26 6E 75 72 3A 20 00 43 4F 4E 46 49 47 5F 50 41 52 41 4D 5F 52 45 51 3B 20 63 6E 6C 3A 20 00 43 4F <\n>
RX: 27 53 00 CA 1A CE 1F 26 6E 75 4E 46 49 47 5F 50 45 45 52 5F 4C 49 53 54 5F 52 45 51 3B 20 63 6E 6C 3A 20 00 2C 20 70 43 <\n>
RX: 1B 54 20 CA 1A CE 1F 26 6E 75 6E 6C 42 3A 20 00 2C 20 70 43 6E 6C 41 3A 20 00 2C 20 <\n>
.TX ACK<\n>
RX: 27 56 00 CA 1A CE 1F 26 6E 75 6E 6C 3A 20 00 2C 20 70 43 6E 6C 42 3A 20 00 2C 20 70 43 6E 6C 41 3A 20 00 2C 20 70 65 65 <\n>
blockLen differ pageSize<\n>
RX: 27 57 00 CA 1A CE 1F 26 6E 75 72 3A 20 00 43 4F 4E 46 49 47 5F 50 45 45 52 5F 41 44 44 3B 20 63 6E 6C 3A 20 00 2C 20 6E <\n>
RX: 27 58 00 CA 1A CE 1F 26 6E 75 61 3A 20 00 2C 20 70 43 6E 6C 42 3A 20 00 2C 20 70 43 6E 6C 41 3A 20 00 20 20 20 20 20 20 <\n>
RX: 27 59 00 CA 1A CE 1F 26 6E 75 20 20 20 20 20 20 20 20 2C 20 63 6C 61 73 73 3A 20 00 2C 20 73 65 72 69 61 6C 3A 20 00 2C <\n>
RX: 27 5A 00 CA 1A CE 1F 26 6E 75 20 74 79 70 65 3A 20 00 44 45 56 49 43 45 5F 49 4E 46 4F 3B 20 66 77 3A 20 00 20 20 20 00 <\n>
RX: 27 5B 00 CA 1A CE 1F 26 6E 75 53 2D 20 00 20 73 74 61 72 74 20 77 61 74 63 68 64 6F 67 0A 00 14 F0 A9 4B 45 51 31 31 30 <\n>
RX: 27 5C 00 CA 1A CE 1F 26 6E 75 39 37 39 37 10 41 01 00 20 20 20 77 72 69 74 65 20 64 61 74 61 2C 20 62 75 74 20 6E 6F 74 <\n>
RX: 27 55 00 CA 1A CE 1F 26 6E 75 01 00 70 65 65 72 3A 20 00 43 4F 4E 46 49 47 5F 50 45 45 52 5F 52 45 4D 4F 56 45 3B 20 63 <\n>
RX: 27 56 00 CA 1A CE 1F 26 6E 75 6E 6C 3A 20 00 2C 20 70 43 6E 6C 42 3A 20 00 2C 20 70 43 6E 6C 41 3A 20 00 2C 20 70 65 65 <\n>
To many data for pageSize<\n>
RX: 27 57 00 CA 1A CE 1F 26 6E 75 72 3A 20 00 43 4F 4E 46 49 47 5F 50 45 45 52 5F 41 44 44 3B 20 63 6E 6C 3A 20 00 2C 20 6E <\n>
blockLen differ pageSize<\n>
RX: 27 58 00 CA 1A CE 1F 26 6E 75 61 3A 20 00 2C 20 70 43 6E 6C 42 3A 20 00 2C 20 70 43 6E 6C 41 3A 20 00 20 20 20 20 20 20 <\n>
RX: 27 59 00 CA 1A CE 1F 26 6E 75 20 20 20 20 20 20 20 20 2C 20 63 6C 61 73 73 3A 20 00 2C 20 73 65 72 69 61 6C 3A 20 00 2C <\n>
RX: 27 5A 00 CA 1A CE 1F 26 6E 75 20 74 79 70 65 3A 20 00 44 45 56 49 43 45 5F 49 4E 46 4F 3B 20 66 77 3A 20 00 20 20 20 00 <\n>
RX: 27 5B 00 CA 1A CE 1F 26 6E 75 53 2D 20 00 20 73 74 61 72 74 20 77 61 74 63 68 64 6F 67 0A 00 14 F0 A9 4B 45 51 31 31 30 <\n>
RX: 27 5C 00 CA 1A CE 1F 26 6E 75 39 37 39 37 10 41 01 00 20 20 20 77 72 69 74 65 20 64 61 74 61 2C 20 62 75 74 20 6E 6F 74 <\n>
RX: 1B 5D 20 CA 1A CE 1F 26 6E 75 20 69 6E 20 63 6F 6E 66 69 67 20 6D 6F 64 65 0A 00 2D <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 27 55 00 CA 1A CE 1F 26 6E 75 01 00 70 65 65 72 3A 20 00 43 4F 4E 46 49 47 5F 50 45 45 52 5F 52 45 4D 4F 56 45 3B 20 63 <\n>
RX: 27 56 00 CA 1A CE 1F 26 6E 75 6E 6C 3A 20 00 2C 20 70 43 6E 6C 42 3A 20 00 2C 20 70 43 6E 6C 41 3A 20 00 2C 20 70 65 65 <\n>
RX: 27 57 00 CA 1A CE 1F 26 6E 75 72 3A 20 00 43 4F 4E 46 49 47 5F 50 45 45 52 5F 41 44 44 3B 20 63 6E 6C 3A 20 00 2C 20 6E <\n>
RX: 27 58 00 CA 1A CE 1F 26 6E 75 61 3A 20 00 2C 20 70 43 6E 6C 42 3A 20 00 2C 20 70 43 6E 6C 41 3A 20 00 20 20 20 20 20 20 <\n>
RX: 27 59 00 CA 1A CE 1F 26 6E 75 20 20 20 20 20 20 20 20 2C 20 63 6C 61 73 73 3A 20 00 2C 20 73 65 72 69 61 6C 3A 20 00 2C <\n>
RX: 27 5A 00 CA 1A CE 1F 26 6E 75 20 74 79 70 65 3A 20 00 44 45 56 49 43 45 5F 49 4E 46 4F 3B 20 66 77 3A 20 00 20 20 20 00 <\n>
RX: 27 5B 00 CA 1A CE 1F 26 6E 75 53 2D 20 00 20 73 74 61 72 74 20 77 61 74 63 68 64 6F 67 0A 00 14 F0 A9 4B 45 51 31 31 30 <\n>
RX: 27 5C 00 CA 1A CE 1F 26 6E 75 39 37 39 37 10 41 01 00 20 20 20 77 72 69 74 65 20 64 61 74 61 2C 20 62 75 74 20 6E 6F 74 <\n>
RX: 1B 5D 20 CA 1A CE 1F 26 6E 75 20 69 6E 20 63 6F 6E 66 69 67 20 6D 6F 64 65 0A 00 2D <\n>
.TX ACK<\n>
################################################################################################################################
# 7. fhem hat ohne antwort auf ackreq den block neu gestartet. ergebnis erfolgreich (5sec timeout durch cul_hm)
#
################################################################################################################################
RX: 27 6E 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 6F 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 70 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 71 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 72 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 73 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 74 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 75 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B 76 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
.TX ACK<\n>
RX: 27 77 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 78 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 79 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7A 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7B 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7C 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7D 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7E 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 77 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
To many data for pageSize<\n>
RX: 27 78 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
blockLen differ pageSize<\n>
RX: 27 79 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7A 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7B 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7C 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7D 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7E 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B 7F 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 27 77 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 78 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 79 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7A 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7B 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7C 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7D 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 7E 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B 7F 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
.TX ACK
################################################################################################################################
# 8. 00ca-msg (A0) fehlt und 20ca-msg (A6) wird wiederholt
#
################################################################################################################################
RX: 27 95 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 96 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 97 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 98 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 99 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 9A 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 9B 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 9C 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B 9D 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
.TX ACK<\n>
RX: 27 9E 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 9F 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 A1 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 A2 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 A3 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 A4 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 A5 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B A6 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 1B A6 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
block(s) missed<\n>
TX NACK<\n>
RX: 27 9E 00 CA 1A CE 1F 26 6E 75 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 9F 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 A0 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 A1 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 A2 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 A3 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 A4 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 27 A5 00 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
RX: 1B A6 20 CA 1A CE 1F 26 6E 75 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\n>
.TX ACK
################################################################################################################################
# 9. block 2 hat gefehlt, fhem wiederholt block mit neuen msg-nummern. !!! update war erfolgreich, crc=ok. io=hmusb.
#
################################################################################################################################
RX: 27 0D 00 CA 1A CE 1F 26 6E 75 01 00 0C 94 B5 07 0C 94 59 39 0C 94 86 39 0C 94 B3 39 0C 94 94 37 0C 94 93 0B 0C 94 6E 0B <\n>
Got CA msg<\n>
Receive firmware<\n>
RX: 27 0E 00 CA 1A CE 1F 26 6E 75 0C 94 49 0B 0C 94 F8 08 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 <\n>
RX: 27 0F 00 CA 1A CE 1F 26 6E 75 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 E0 39 0C 94 DD 07 0C 94 22 3D 0C 94 70 3D <\n>
RX: 27 10 00 CA 1A CE 1F 26 6E 75 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 0C 94 DD 07 29 0A 00 28 00 29 <\n>
RX: 27 11 00 CA 1A CE 1F 26 6E 75 00 20 28 6C 3A 00 4B 6E 6F 77 6E 20 63 6F 6D 6D 61 6E 64 73 3A 00 20 62 79 74 65 73 00 4E <\n>
RX: 27 12 00 CA 1A CE 1F 26 6E 75 6F 74 20 65 6E 6F 75 67 68 20 64 61 74 61 2C 20 6E 65 65 64 20 00 55 6E 72 65 63 6F 67 6E <\n>
RX: 27 13 00 CA 1A CE 1F 26 6E 75 69 7A 65 64 20 63 68 61 72 61 63 74 65 72 3A 20 00 2C 20 6E 78 74 53 3A 00 52 4C 3A 61 64 <\n>
RX: 27 14 00 CA 1A CE 1F 26 6E 75 6A 52 6C 79 2C 20 63 75 72 53 3A 00 2C 20 4F 66 66 54 69 6D 65 3A 00 2C 20 4F 66 66 44 6C <\n>
RX: 1B 15 20 CA 1A CE 1F 26 6E 75 79 3A 00 2C 20 4F 6E 54 69 6D 65 3A 00 2C 20 4F 6E 44 <\n>
.TX ACK<\n>
RX: 1B 1E 20 CA 1A CE 1F 26 6E 75 00 20 6F 66 20 00 0A 67 65 74 4C 69 73 74 46 6F 72 4D <\n>
block(s) missed<\n>
TX NACK<\n>
RX: 27 57 00 CA 1A CE 1F 26 6E 75 01 00 6C 79 3A 00 2C 20 6E 78 74 53 3A 00 52 4C 3A 74 72 69 67 67 65 72 34 30 2C 20 63 75 <\n>
RX: 27 58 00 CA 1A CE 1F 26 6E 75 72 53 3A 00 2C 20 64 75 72 61 54 3A 00 2C 20 72 61 6D 70 54 3A 00 2C 20 6E 78 74 53 3A 00 <\n>
RX: 27 59 00 CA 1A CE 1F 26 6E 75 52 4C 3A 74 72 69 67 67 65 72 31 31 2C 20 76 61 6C 3A 00 2C 20 70 49 64 78 32 3A 20 00 2C <\n>
RX: 27 5A 00 CA 1A CE 1F 26 6E 75 20 70 49 64 78 31 3A 20 00 72 65 6D 6F 76 65 50 65 65 72 46 72 6F 6D 4D 73 67 2C 20 63 6E <\n>
RX: 27 5B 00 CA 1A CE 1F 26 6E 75 6C 3A 20 00 61 64 64 50 65 65 72 46 72 6F 6D 4D 73 67 2C 20 63 6E 6C 3A 20 00 61 64 64 50 <\n>
RX: 27 5C 00 CA 1A CE 1F 26 6E 75 65 65 72 46 72 6F 6D 4D 73 67 2C 20 63 6E 6C 3A 20 00 2C 20 64 61 74 61 3A 20 00 73 65 74 <\n>
RX: 27 5D 00 CA 1A CE 1F 26 6E 75 4C 69 73 74 46 72 6F 6D 4D 73 67 2C 20 6C 65 6E 3A 20 00 2C 20 64 61 74 61 3A 20 00 67 65 <\n>
RX: 27 5E 00 CA 1A CE 1F 26 6E 75 74 4C 69 73 74 46 6F 72 4D 73 67 32 2C 20 6C 65 6E 3A 20 00 2C 20 73 6C 63 50 74 72 3A 20 <\n>
RX: 1B 5F 20 CA 1A CE 1F 26 6E 75 00 20 6F 66 20 00 0A 67 65 74 4C 69 73 74 46 6F 72 4D <\n>
.TX ACK<\n>
RX: 27 60 00 CA 1A CE 1F 26 6E 75 01 00 73 67 32 2C 20 6D 73 67 50 74 72 3A 20 00 2C 20 70 65 65 72 3A 20 00 4C 6F 61 64 69 <\n>
RX: 27 62 00 CA 1A CE 1F 26 6E 75 74 52 65 67 2C 20 6C 65 6E 3A 20 00 2C 20 70 65 65 72 49 64 78 3A 20 00 2C 20 70 68 79 4C <\n>
RX: 27 64 00 CA 1A CE 1F 26 6E 75 74 53 6C 69 63 65 44 65 74 61 69 6C 2C 20 73 6C 63 50 74 72 3A 20 00 2C 20 73 69 7A 65 20 <\n>
RX: 27 65 00 CA 1A CE 1F 26 6E 75 6F 66 3A 20 00 4C 6F 61 64 69 6E 67 20 50 65 65 72 44 42 2C 20 73 74 61 72 74 73 3A 20 00 <\n>
RX: 27 66 00 CA 1A CE 1F 26 6E 75 64 6F 6E 65 0A 00 66 69 72 73 74 20 73 74 61 72 74 20 64 65 74 65 63 74 65 64 2C 20 66 6F <\n>
RX: 27 67 00 CA 1A CE 1F 26 6E 75 72 6D 61 74 69 6E 67 20 65 65 70 72 6F 6D 2E 2E 2E 0A 00 0A 0A 00 55 6E 6B 6E 6F 77 6E 20 <\n>
RX: 1B 68 20 CA 1A CE 1F 26 6E 75 4D 65 73 73 61 67 65 2C 20 70 6C 65 61 73 65 20 72 65 <\n>
pageSize and blockPos differ<\n>
TX NACK<\n>
RX: 27 60 00 CA 1A CE 1F 26 6E 75 01 00 73 67 32 2C 20 6D 73 67 50 74 72 3A 20 00 2C 20 70 65 65 72 3A 20 00 4C 6F 61 64 69 <\n>
RX: 27 61 00 CA 1A CE 1F 26 6E 75 6E 67 20 6C 69 73 74 33 20 66 6F 72 20 63 6E 6C 3A 20 00 2C 20 64 61 74 61 3A 20 00 67 65 <\n>
RX: 27 62 00 CA 1A CE 1F 26 6E 75 74 52 65 67 2C 20 6C 65 6E 3A 20 00 2C 20 70 65 65 72 49 64 78 3A 20 00 2C 20 70 68 79 4C <\n>
RX: 27 63 00 CA 1A CE 1F 26 6E 75 65 6E 3A 20 00 2C 20 70 68 79 41 64 64 72 3A 20 00 2C 20 73 6C 63 4C 65 6E 3A 20 00 67 65 <\n>
RX: 27 64 00 CA 1A CE 1F 26 6E 75 74 53 6C 69 63 65 44 65 74 61 69 6C 2C 20 73 6C 63 50 74 72 3A 20 00 2C 20 73 69 7A 65 20 <\n>
RX: 27 65 00 CA 1A CE 1F 26 6E 75 6F 66 3A 20 00 4C 6F 61 64 69 6E 67 20 50 65 65 72 44 42 2C 20 73 74 61 72 74 73 3A 20 00 <\n>
RX: 27 66 00 CA 1A CE 1F 26 6E 75 64 6F 6E 65 0A 00 66 69 72 73 74 20 73 74 61 72 74 20 64 65 74 65 63 74 65 64 2C 20 66 6F <\n>
RX: 27 67 00 CA 1A CE 1F 26 6E 75 72 6D 61 74 69 6E 67 20 65 65 70 72 6F 6D 2E 2E 2E 0A 00 0A 0A 00 55 6E 6B 6E 6F 77 6E 20 <\n>
RX: 1B 68 20 CA 1A CE 1F 26 6E 75 4D 65 73 73 61 67 65 2C 20 70 6C 65 61 73 65 20 72 65 <\n>
.TX ACK
############################### fhem.log #####################################
2014.10.30 12:37:50.810 2: CUL_HM fwUpdate started for SwitchPBU02
2014.10.30 12:37:50.816 0: HMLAN_Send: hmusb1 S:+266E75,00,01,00
2014.10.30 12:37:50.818 0: HMLAN_Send: hmusb1 S:S60D8F326 stat: 00 t:00000000 d:01 r:60D8F326 m:0A 3011 1ACE1F 266E75 CA
2014.10.30 12:37:50.910 3: CUL_HM set SwitchPBU02 fwUpdate fwUpdates/switchpbu02/HM_LC_Sw1PBU_FM_2014-10-24_1v4.eq3 20
2014.10.30 12:37:51.325 0: HMLAN_Parse: hmusb1 R:R60D8F326 stat:0001 t:044ED2DE d:FF r:FFBE m:0A 8002 266E75 1ACE1F 80
2014.10.30 12:37:59.418 2: CUL_HM fwUpdate SwitchPBU02 entered mode. IO-speed: fast
2014.10.30 12:37:59.510 0: HMLAN_Send: hmusb1 S:S60D914C6 stat: 00 t:00000000 d:01 r:60D914C6 m:0B 00CB 1ACE1F 266E75 105B11F81547
2014.10.30 12:37:59.602 5: CUL_HM fwUpdate write block 1 of 224: 9 messages
2014.10.30 12:37:59.606 0: HMLAN_Send: hmusb1 S:S60D9157E stat: 00 t:00000000 d:01 r:60D9157E m:0D 00CA 1ACE1F 266E75 01000C94B5070C9459390C9486390C94B3390C9494370C94930B0C946E0B
2014.10.30 12:37:59.623 0: HMLAN_Send: hmusb1 S:S60D9158F stat: 00 t:00000000 d:01 r:60D9158F m:0E 00CA 1ACE1F 266E75 0C94490B0C94F8080C94DD070C94DD070C94DD070C94DD070C94DD070C94
2014.10.30 12:37:59.640 0: HMLAN_Send: hmusb1 S:S60D9159F stat: 00 t:00000000 d:01 r:60D9159F m:0F 00CA 1ACE1F 266E75 DD070C94DD070C94DD070C94DD070C94E0390C94DD070C94223D0C94703D
2014.10.30 12:37:59.660 0: HMLAN_Send: hmusb1 S:S60D915B3 stat: 00 t:00000000 d:01 r:60D915B3 m:10 00CA 1ACE1F 266E75 0C94DD070C94DD070C94DD070C94DD070C94DD070C94DD07290A00280029
2014.10.30 12:37:59.677 0: HMLAN_Send: hmusb1 S:S60D915C5 stat: 00 t:00000000 d:01 r:60D915C5 m:11 00CA 1ACE1F 266E75 0020286C3A004B6E6F776E20636F6D6D616E64733A00206279746573004E
2014.10.30 12:37:59.694 0: HMLAN_Send: hmusb1 S:S60D915D6 stat: 00 t:00000000 d:01 r:60D915D6 m:12 00CA 1ACE1F 266E75 6F7420656E6F75676820646174612C206E6565642000556E7265636F676E
2014.10.30 12:37:59.711 0: HMLAN_Send: hmusb1 S:S60D915E6 stat: 00 t:00000000 d:01 r:60D915E6 m:13 00CA 1ACE1F 266E75 697A6564206368617261637465723A20002C206E7874533A00524C3A6164
2014.10.30 12:37:59.728 0: HMLAN_Send: hmusb1 S:S60D915F7 stat: 00 t:00000000 d:01 r:60D915F7 m:14 00CA 1ACE1F 266E75 6A526C792C20637572533A002C204F666654696D653A002C204F6666446C
2014.10.30 12:37:59.746 0: HMLAN_Send: hmusb1 S:S60D91609 stat: 00 t:00000000 d:01 r:60D91609 m:15 20CA 1ACE1F 266E75 793A002C204F6E54696D653A002C204F6E44
2014.10.30 12:37:59.784 0: HMLAN_Parse: hmusb1 R:E266E75 stat:0000 t:044EF278 d:FF r:FFC0 m:00 0010 266E75 000000 004B455131313039373937
2014.10.30 12:37:59.793 5: CUL_HM fwUpdate write block 2 of 224: 9 messages
2014.10.30 12:37:59.888 0: HMLAN_Delay: hmusb1 266E75
2014.10.30 12:37:59.905 0: HMLAN_Delay: hmusb1 266E75
2014.10.30 12:37:59.923 0: HMLAN_Delay: hmusb1 266E75
2014.10.30 12:37:59.938 0: HMLAN_Delay: hmusb1 266E75
Hi Frank,
Zitat von: frank am 10 März 2015, 17:19:56
das eigentliche fhem problem ist, dass der bootloader auf die cb-message wartet, aber fhem keine sendet.
Klingt nach einem FHEM-Problem?
ZitatAskSin 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?
Zitat# 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
ZitatKlingt nach einem FHEM-Problem?
nee, leider nicht. kurz gesagt, martin sagte einmal:
Zitat von: martinp876 am 14 Mai 2014, 10:25:16
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 (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.
ZitatWas hat sich in 0.7.2 gegenüber 0.7.0 noch verändert?
das ist meine private version. :) aus deiner hervorgegangen.
Zitat von: frank am 10 März 2015, 20:34:55
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?
Zitatdas 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
ZitatNur warum?
homematic-philosophie. ausserdem klappt es ja mit allen anderen fw-updates über fhem. lies den thread. ;)
ZitatAllerdings hatte ich da 0.7.1 erwartet
du warst damals so schnell mit updates, da dachte ich, da habe ich mehr zeit. :)
ZitatAlso 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
Zitat von: frank am 10 März 2015, 21:15:36
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
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
Zitat
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
Hallo Helmut,
Zitat von: Poquito am 12 März 2015, 12:04:07
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
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?
Zitat von: betateilchen am 12 März 2015, 21:06:40
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
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:
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.
Zitat von: Gernott am 12 März 2015, 22:46:08
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
Zitat von: Dirk am 12 März 2015, 23:04:10
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.
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.
Probier mal, das Knöpchen mehrfach zu drücken, nach dem getConfig gestartet wurde.
Zitat von: vbs am 13 März 2015, 00:34:35
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.
Hi,
irgendwann hier wurden mal die passenden CC1101-Module vpon Aliexpress hier verlinkt - die ohne Stiftleiste - direkt zum auflöten.
Irgendwie finde ich die nicht mehr. Ich finde zwar jede Menge CC1101 Module bei Ali aber keine explizit angegebenen für 868MHZ ohne Stiftleiste.
Andernfalls, kann ich dieses hier nehmen?
http://www.aliexpress.com/item/5pcs-lot-CC1101-868MHz-wireless-module-distance-for-300m-Free-shipping/1104732817.html
Dieses hier ist wohl nicht auf 868MHZ optimiert:
http://www.aliexpress.com/item/5PCS-LOT-CC1101-wireless-module-Frequency-range-300-1000-MHz-free-shipping/1095240213.html
Das hier:
http://www.aliexpress.com/item/2PCS-LOT-CC1101-868MHz-wireless-module-free-shipping/1282890043.html (http://www.aliexpress.com/item/2PCS-LOT-CC1101-868MHz-wireless-module-free-shipping/1282890043.html)
hi,
den hatte ich auch schon, aber der ist für stiftleisten und nicht für direktes Auflöten ala SMD geeignet. Siehe Link vorher, der hat lötstellen zum SMD-Löten
Zitat von: Tobias am 13 März 2015, 08:45:47
irgendwann hier wurden mal die passenden CC1101-Module vpon Aliexpress hier verlinkt - die ohne Stiftleiste - direkt zum auflöten.
Das hier:
http://www.aliexpress.com/item/2pcs-lot-CC1101-868MHz-wireless-RF-module-Free-shipping/1104646176.html
Gruß
Dirk
ok, danke euch beiden... Ich bestell mal welche und versuch die ohne Stiftleiste direkt durch die Löcher direkt als SMD aufzulöten... Geht natürlich nur falls die Unterseite des Moduls plan ist und keine Bauteile dort liegen ;)
Zitat von: Tobias am 13 März 2015, 12:38:32
Geht natürlich nur falls die Unterseite des Moduls plan ist und keine Bauteile dort liegen ;)
Ja, das passt. So mach ich das bei den Sensoren :)
Das Bild passt nicht exakt zu den gelieferten Modulen. Die Löcher für die Stiftleisten waren halbiert. Lassen sich also wunderbar auch SMD bestücken.
Zitat von: Dirk am 12 März 2015, 17:04:57
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
Hallo Dirk,
ich verstehe die Sache so:
- serieller Bootloader (aktueller Bootloader hier https://github.com/kc-GitHub/Wettersensor/tree/v0.12/Tools/Bootloader/Arduino_Serial
Hier wird HM-ID und Seriennummer mit dem Flash-Skript in die HEX-Datei des Sensors geschrieben und danach die (modifizierte) Firmware geflasht.
- OTA Bootlader (aktuell die V0.7.0 siehe https://github.com/kc-GitHub/Asksin_OTA_Bootloader/tree/master/Tools/Flash-Tool-Windows)
Hier wird im Bootloader die HM-ID und die Seriennummer (auch wieder mit dem Flash-Skript) geschrieben, die Firmware wird ohne Änderung (bis auf die Umwandlung in eq3) über 868 MHz geflasht.
Ist das so richtig? Meine Sensoren haben auch noch den seriellen Bootloader, aber ich werde demnächst mal auf OTA umsteigen, falls das OTA Flashen mit CUL funktioniert.
Danke + Gruß
Peter
Zitat von: Dirk am 12 März 2015, 21:15:09
Wenn ich mich recht erinnere hast du noch den seriellen BL?
Bis dahin ist das Script noch im 0.12er Zweig zu finden:
Das 0.14er Hexfile ist im 0.14er Firmware-Release:
Das heißt, ich kann das bisherige 0.12 Skript einfach zusammen mit dem hexFile der 0.14 verwenden? Prima, dann probier ich das mal.
Hallo Dirk,
ich weiß nicht mehr weiter. Wieder einen ganzen Tag am Rechner verbracht, ohne einen Schritt weiter gekommen zu sein.
Das Programm auf dem Sensor scheint korrekt zu laufen. Soweit ich das beurteilen kann stimmen die Ausgaben über die serielle Schnittstelle, aber ich kann den Sensor nicht im FHEM einbinden.
Zitat von: Dirk am 12 März 2015, 17:04:57
Hast du auch die HMConfig_SenTHPL.pm ins FHEM-Verzeichniss kopiert?
Die Datei habe ich ins Verzeichnis
/opt/fhem/FHEM kopiert und auch verschiedene Versionen ausprobiert, aber immer mit dem selben Ergebnis, dass
firmware, model, serialNr und subType falsch interpretiert werden.
Aktuell sehen die Einträge unter Attributes so aus:
Zitat
IODev CUL_1
autoReadReg 4_reqStatus
expert 2_full
firmware 0.10
model HM-LC-BL1-PB-FM
serialNr tarting sk
subType blindActuator
Ist noch irgend etwas anderes an FHEM zu ändern oder einzubinden, das ich übersehen habe oder sollte doch etwas an der Hardware nicht funktionieren?
Gruß
Helmut
Bei mir wird der Sensor nun mit der 0.14 Firmware auch als völlig falsches Gerät in fhem angezeigt...
Es fängt schon damit an, dass die HMId in DEF falsch angezeigt wird - ich hatte beim flashen die B4:88:98 verwendet und nicht 00:01:02
Irgendwas muss da mächtig schiefgegangen sein.
Internals:
CFGFN
DEF 000102
IODev fl_HMUSB
LASTInputDev wz_HMUSB
MSGCNT 2
NAME CUL_HM_HM_LC_SW1_PL_OM54_000102
NR 359
STATE ???
TYPE CUL_HM
fl_HMUSB_MSGCNT 1
fl_HMUSB_RAWMSG E000102,0000,192C1306,FF,FFC0,07A2000001020000000E000102030405060708090A0B70030100
fl_HMUSB_RSSI -64
fl_HMUSB_TIME 2015-03-13 19:13:48
lastMsg No:07 - t:00 s:000102 d:000000 0E000102030405060708090A0B70030100
protLastRcv 2015-03-13 19:13:48
protResnd 3 last_at:2015-03-13 19:14:05
protSnd 1 last_at:2015-03-13 19:13:52
protState CMDs_processing...
rssi_at_fl_HMUSB avg:-64 min:-64 max:-64 lst:-64 cnt:1
rssi_at_wz_HMUSB avg:-42 min:-42 max:-42 lst:-42 cnt:1
wz_HMUSB_MSGCNT 1
wz_HMUSB_RAWMSG E000102,0000,01BBC480,FF,FFD6,07A2000001020000000E000102030405060708090A0B70030100
wz_HMUSB_RSSI -42
wz_HMUSB_TIME 2015-03-13 19:13:48
Readings:
2015-03-13 19:13:48 D-firmware 0.14
2015-03-13 19:13:48 D-serialNr
cmdStack:
Helper:
cSnd 01127000000102010E
mId 0001
rxType 1
Io:
newChn +000102,00,01,00
nextSend 1426270428.99022
prefIO
rxt 0
vccu
p:
000102
00
01
00
Mrssi:
mNo 07
Io:
fl_HMUSB -62
wz_HMUSB -42
Prt:
bErr 0
sProc 1
Rspwait:
cmd As0B02A001127000000102010E
mNo 02
reSent 4
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
prs 1
Rssi:
At_fl_hmusb:
avg -64
cnt 1
lst -64
max -64
min -64
At_wz_hmusb:
avg -42
cnt 1
lst -42
max -42
min -42
Attributes:
IODev fl_HMUSB
autoReadReg 4_reqStatus
expert 2_full
firmware 0.14
model HM-LC-SW1-PL-OM54
room CUL_HM
serialNr
subType switch
webCmd statusRequest:toggle:on:off
Das Firmwareupdate selbst hat seriell problemlos funktioniert,
die aktuelle HMConfig_SenTHPL.pm ist auch kopiert und mit den richtigen Zugriffsrechten versehen.
Zitat von: PeMue am 13 März 2015, 17:17:48
Hallo Dirk,
ich verstehe die Sache so:
- serieller Bootloader (aktueller Bootloader hier https://github.com/kc-GitHub/Wettersensor/tree/v0.12/Tools/Bootloader/Arduino_Serial
Hier wird HM-ID und Seriennummer mit dem Flash-Skript in die HEX-Datei des Sensors geschrieben und danach die (modifizierte) Firmware geflasht.
- OTA Bootlader (aktuell die V0.7.0 siehe https://github.com/kc-GitHub/Asksin_OTA_Bootloader/tree/master/Tools/Flash-Tool-Windows)
Hier wird im Bootloader die HM-ID und die Seriennummer (auch wieder mit dem Flash-Skript) geschrieben, die Firmware wird ohne Änderung (bis auf die Umwandlung in eq3) über 868 MHz geflasht.
Ist das so richtig?
Korrekt.Doch nicht ganz Korrekt. Siehe hier:
http://forum.fhem.de/index.php/topic,20620.msg273064.html#msg273064
Das korrigierte Script kommt noch.
Zitat von: Poquito am 13 März 2015, 18:54:23
ich weiß nicht mehr weiter. Wieder einen ganzen Tag am Rechner verbracht, ohne einen Schritt weiter gekommen zu sein.
Das Programm auf dem Sensor scheint korrekt zu laufen. Soweit ich das beurteilen kann stimmen die Ausgaben über die serielle Schnittstelle, aber ich kann den Sensor nicht im FHEM einbinden.
Hast du die Seriennummer usw. direkt in die FW einkompiliert? Oder hast du mit dem Flash-Script geflasht?
Und wieso steht da noch "firmware 0.10"?
Zitat von: betateilchen am 13 März 2015, 19:15:53
Bei mir wird der Sensor nun mit der 0.14 Firmware auch als völlig falsches Gerät in fhem angezeigt...
Es fängt schon damit an, dass die HMId in DEF falsch angezeigt wird - ich hatte beim flashen die B4:88:98 verwendet und nicht 00:01:02
Irgendwas muss da mächtig schiefgegangen sein.
Es gab schon mal das Problem dass es beim Hex2bin Probleme gab.
wie sieht denn der Commandline-Aufruf vom Script bei dir aus?
Gruß
Dirk
Zitat von: Dirk am 13 März 2015, 19:28:47
Es gab schon mal das Problem dass es beim Hex2bin Probleme gab.
wie sieht denn der Commandline-Aufruf vom Script bei dir aus?
C:\Users\Udo Neumann\Desktop\Flash-Tool-Windows>flash.cmd com4 HB-UW-Sen-THPL_up
date_V0_14_001_150301.hex B4:88:98 UWS2370787
Start flashing device with HM-ID: B4:88:98 and serial number: UWS2370787
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude.exe: Device signature = 0x1e950f
avrdude.exe: reading input file "HB-UW-Sen-THPL_update_V0_14_001_150301.bin"
avrdude.exe: writing flash (28672 bytes):
Writing | ################################################## | 100% 13.68s
avrdude.exe: 28672 bytes of flash written
avrdude.exe: verifying flash memory against HB-UW-Sen-THPL_update_V0_14_001_1503
01.bin:
avrdude.exe: load data flash data from input file HB-UW-Sen-THPL_update_V0_14_00
1_150301.bin:
avrdude.exe: input file HB-UW-Sen-THPL_update_V0_14_001_150301.bin contains 2867
2 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 12.67s
avrdude.exe: verifying ...
avrdude.exe: 28672 bytes of flash verified
avrdude.exe: safemode: Fuses OK
avrdude.exe done. Thank you.
::**********************************************************
::* Write user defined HM-ID and serial number to bin-file *
::**********************************************************
bin\sed -b -e "s/\(%defSerialNumber%\)\(.*\)\(\x%defHmId1%\x%defHmId2%\x%defHmId
3%\)/%serialNr%\2\x%hmId1%\x%hmId2%\x%hmId3%/" %fileBasename%.bin > %fileBasenam
e%.tmp
del %fileBasename%.bin
ren %fileBasename%.tmp %fileBasename%.bin
echo Start flashing device with HM-ID: %hmId1%:%hmId2%:%hmId3% and serial number
: %serialNr%
:useDefaultValues
::*******************************
::* Begin flashing with avrdude *
::*******************************
if %serialNr%!==! (
echo Start flashing device with predefined HM-ID and serial number.
)
bin\avrdude.exe -Cbin\avrdude.conf -patmega328p -carduino -P %1 -b57600 -D -Ufla
sh:w:%fileBasename%.bin:r
del %fileBasename%.bin
goto :end
Gab es früher nicht unterschiedliche Firmwarefiles für Innen- und Aussensensoren, wegen unterschiedlicher HM-model-Typen?
Ich bin jetzt wieder auf der 0.12, die liess sich problemlos wieder einspielen.
ZitatC:\Users\Udo Neumann\Desktop\Flash-Tool-Windows>flash.cmd com4 HB-UW-Sen-THPL_up
date_V0_14_001_150301.hex B4:88:98 UWS2370787
Ok, das ist das Problem.
Da ist das "alte" flashscript scheinbar doch incompatibel.
Mist ich werde alt und leide wohl langsam an "Amnesie".
Ich schicke dir gleich das richtige Script. Weil da gehört noch der Devicetype mit rein.
Hej Dirk,
jetzt mal ein kleines Feedback zur 0.14er.
Als ich heute zwischendurch auf mein Display schaute, musste ich feststellen, dass es laut einen meiner Sensoren draußen -39,7°C hat. Es ist heute zwar heute etwas kälter, aber als so schlimm hab ich es auch nicht empfunden. ;-)
Ein kurzer Blick auf System zeigte mir folgende letzte Logeinträge:
2015-03-13_06:19:28 sensorOutdoor T: 5.5 H: 63 L: 0.01 P: 995.8 P-NN: 1021.6
2015-03-13_06:19:28 sensorOutdoor batVoltage: 2.2
2015-03-13_06:22:13 sensorOutdoor T: 5.5 H: 63 L: 0.01 P: 995.8 P-NN: 1021.6
2015-03-13_06:22:13 sensorOutdoor batVoltage: 2.1
2015-03-13_06:24:43 sensorOutdoor T: 5.5 H: 63 L: 0.03 P: 995.9 P-NN: 1021.7
2015-03-13_06:24:43 sensorOutdoor batVoltage: 2.2
2015-03-13_06:28:08 sensorOutdoor T: 5.5 H: 62 L: 0.03 P: 995.8 P-NN: 1021.6
2015-03-13_06:28:08 sensorOutdoor batVoltage: 2.2
2015-03-13_06:28:17 sensorOutdoor T: -39.7 H: 41 L: 0.01 P: 995.8 P-NN: 1021.6
2015-03-13_06:28:17 sensorOutdoor batVoltage: 1.2
Ich hab vorhin gerade die beiden Zellen mit dem Multimeter gemessen und siehe da:
Zelle 1: 951mA
Zelle 2: 159mA
Jetzt während dem Schreiben noch einmal gemessen und da gibt es eine kleine Änderung:
Zelle 1: 953mA
Zelle 2: 694mA
Die ganzen andern Sensoren, die ich quasi zeitgleich upgegradet habe (sind allerdings 03er und nicht 06er wie dieser), liefern hingegen weiterhin ordnungsgemäß ihre Daten bei FHEM ab.
Zeitpunkt der Inbetriebnahme des Sensors (erster Eintrag im Logfile mit einstelliger Nachkommastelle) war:
2015-03-03_01:45:25 sensorOutdoor batVoltage: 2.2
Hallo Dirk
Zitat von: Dirk am 13 März 2015, 19:28:47
Hast du die Seriennummer usw. direkt in die FW einkompiliert? Oder hast du mit dem Flash-Script geflasht?
Und wieso steht da noch "firmware 0.10"?
Das ist ja das Problem, dass die Daten in FHEM nicht korrekt interpretiert werden. In der V0.14 wurde Firmware 6.9 angezeigt.
Gestern mit der neuesten Version wurde 6.6 angezeigt und heute nachdem ich das Programm mit ein paar Änderungen (nur zur Ausgabe einiger Variablen über die serielle Schnittstelle) nochmals compiliert und hochgeladen habe, wird nun 0.10 angezeigt, aber bei der Ausgabe der entsprechenden Variablen über die serielle Schnittstelle stimmt soweit alles.
An der Firmware hab ich bisher nichts geändert, sondern nur die Variable im Programm und dieses direkt aus Arduino V1.6 hochgeladen.
Gruß
Helmut
Zitat von: Mr. P am 13 März 2015, 20:22:29
Ich hab vorhin gerade die beiden Zellen mit dem Multimeter gemessen und siehe da:
Zelle 1: 951mA
Zelle 2: 159mA
mA?
Du hast den Kurzschlusstrom der Zellen gemessen?
Oder sollten das mV sein?
Zitat von: Poquito am 13 März 2015, 20:44:28
Das ist ja das Problem, dass die Daten in FHEM nicht korrekt interpretiert werden. In der V0.14 wurde Firmware 6.9 angezeigt.
Gestern mit der neuesten Version wurde 6.6 angezeigt und heute nachdem ich das Programm mit ein paar Änderungen (nur zur Ausgabe einiger Variablen
Da ist auf alle Fälle was Faul. Drück mal die Configtaste und poste mal die Debugausgabe vom Sensor.
Du hast aber nur die erste Zeile mit "#define USE_ADRESS_SECTION 1" in der wetterSensor.h geändert?
nicht diese Zeile:
#if USE_ADRESS_SECTION == 0in der Register.h darf das auch nicht geändert werden.
Zitat von: Dirk am 13 März 2015, 22:05:13
mA?
Du hast den Kurzschlusstrom der Zellen gemessen?
Oder sollten das mV sein?
Da ist auf alle Fälle was Faul. Drück mal die Configtaste und poste mal die Debugausgabe vom Sensor.
Du hast aber nur die erste Zeile mit "#define USE_ADRESS_SECTION 1" in der wetterSensor.h geändert?
nicht diese Zeile:
#if USE_ADRESS_SECTION == 0
*argl* - Macht der Gewohnheit, sorry!
Natürlich mein ich mV!
Zitat von: Dirk am 13 März 2015, 21:56:57
Daher hier NUR für alle mit dem "alten" seriellen Bootloader (vor 08 / 2014) sind im Anhang die dafür passenden Hex-Files
Funktioniert nicht.
Zitat von: betateilchen am 13 März 2015, 22:11:24
Funktioniert nicht.
Was?, Das Hexfile läuft nicht auf dem Sensor?. Lässt sich nicht flashen?
Dann muss ich dich etwas vertrösten. Ich muss mir erst mal wieder eine passende Umgebung dazu bauen.
Du bist nicht zufällig nächsten Samstag mit in Karlsruhe? Dann könnte ich dir den Sensor flashen.
Das File läßt sich problemlos flashen. Aber die Daten des Sensor sehen danach in fhem noch kranker aus als vorher.
Es wird ein neues HM-Device mit völlig abstrusen Daten angelegt - es stimmen weder die HMid, noch die Seriennummer, noch die Firmwareversion (die vorher zumindest richtig angezeigt wurde)
2015.03.13 22:09:45.637 2: CUL_HM Unknown device CUL_HM_ID_CA06_931203 is now defined
2015.03.13 22:09:45.642 2: autocreate: define CUL_HM_ID_CA06_931203 CUL_HM 931203
Nächste Woche Samstag kann ich leider nicht, weil ich hier Besuch bekomme und nicht in der Gegend bin.
Kann ich mit dem USB-Seriell Wandler irgendwie den aktuellen Bootloader selbst flashen?
Bei den unterschiedlichen Beschreibungen und Begrifflichkeiten hier in und ausserhalb des Forums blicke ich einfach nicht mehr durch.
Das hier hab ich aber noch nicht getestet:
http://doswa.com/2010/08/24/avrdude-5-10-with-ftdi-bitbang.html
RPi Hast du vermutlich nicht mehr.
Ggf. geht das mit dem einen der anderen Einplatinenrechner auch.
BeagleBone Black: http://datko.net/2013/11/11/bbb_atmega328p/
Ansonsten gibt es auch Sketches für Arduino um diesen zu einem ISP zu machen.
Ich baue die aber die Hexfiles noch für den "alten" BL.
Und achte auch darauf dass die mit mit folgenden Updates auch mit dabei sind.
Zitat von: Dirk am 13 März 2015, 22:45:10
RPi Hast du vermutlich nicht mehr.
doch, hab ich theoretisch schon, aber da muss ich hier erstmal die gesamte Infrastruktur auseinanderreißen
Ne, lass mal.
ich habe hier sogar einen USB-ISP Programmieradapter gefunden (STK500v2 kompatibel)
http://forum.diamex.de/content.php?33-ISP-Programmer
Jetzt muss ich nur noch rausfinden, wie ich den Adapter mit der Sensorplatine verheiraten kann um den Bootloader zu aktualisieren...
(http://up.picr.de/21275272kt.jpg)
Ich gebe auf. Offensichtlich bin ich zu doof dafür.
Zitat von: betateilchen am 14 März 2015, 12:07:21
Ich gebe auf. Offensichtlich bin ich zu doof dafür.
Ich hatte es mir auch deutlich einfacher vorgestellt und von daher geht es mir momentan auch nicht viel besser . Vermutlich ist es nur eine Kleinigkeit die übersehen oder vergessen wurde, aber wenn man nicht weiß an welcher Stelle man anfangen soll zu suchen, ist es sehr frustrierend.
@Dirk
Ich habe nur in
wetterSensor.h und
AskSinMain.h die #define Anweisung auf
0 gesetzt, sonst nichts.
Im Monitor wird folgendes angezeigt:
freeMem: 994 byte
Device type from Bootloader: F1 02
Serial from Bootloader: 48 46 42 30 30 31 38 35 30 31
Addresse from Bootloader: AB CD EF
powerMode: 3
Config changed. Data: (L:0)
lowBatLimit: 0
ledMode: 0
burstRx: 0
transmDevTryMax: 1
altitude: 0
<- 14 00 A2 70 2E 2E 2E 1B 0C 94 00 00 00 00 00 00 00 71 D0 0D 48 (L:21) (M:2062)
-> NA (M:2758)
<- 14 01 A2 70 2E 2E 2E 01 0C 94 00 00 00 00 00 00 00 71 D0 0D 48 (L:21) (M:2772)
-> NA (M:3469)
<- 1A 02 A2 00 2E 2E 2E 00 00 00 0A 00 53 74 61 72 74 69 6E 67 20 73 6B 65 74 63 68 (L:27) (M:37305)
<- 1A 03 A2 00 2E 2E 2E 00 00 00 0A 00 53 74 61 72 74 69 6E 67 20 73 6B 65 74 63 68 (L:27) (M:37544)
-> NA (M:38239)
-> 10 44 A0 01 F1 10 34 2E 2E 2E 00 04 00 00 00 00 00 (L:17) (M:39166)
<- 1A 44 A0 10 2E 2E 2E F1 10 34 02 01 00 05 00 0A 00 0B 00 0C 00 12 00 14 00 24 00 (L:27) (M:39181)
-> 0A 44 80 02 F1 10 34 2E 2E 2E 00 (L:11) (M:39441)
<- 0E 45 A0 10 2E 2E 2E F1 10 34 02 25 00 00 00 (L:15) (M:39447)
-> 0A 45 80 02 F1 10 34 2E 2E 2E 00 (L:11) (M:39597)
-> 10 45 A0 01 F1 10 34 2E 2E 2E 01 04 00 00 00 00 01 (L:17) (M:39627)
Von
Device type bis
Addresse habe ich eingefügt um zu sehen ob die Daten richtig übernommen werden.
Gruß
Helmut
Mit Hilfe dieser Anleitung:
http://www.lxccu.com/hb-raspberry-bootloader-update
und eines RaspberryPi habe ich es nun geschafft, den dort beschriebenen Bootloader zu flashen. Nun tut der Sensor erstmal gar nix mehr, was mich aber nicht sonderlich verwundert.
Einfache Frage: Was ist jetzt der nächste Schritt, um eine Firmware auf den Sensor zu bekommen?
Wenn du jetzt den OTA-Bootloader drauf hast (inkl. korrekt eingetragener Seriennummer und HMID), dann kannst du jetzt die Firmware flashen. Ich habs mit dem Homematic-FW-Tool gemacht. flash-ota oder CCU sollen aber wohl auch funktionieren.
perl flash.pl Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex F1:02 B4:88:98 UWS2370787
Test Bootloader connection
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e950f
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Write Bootloader
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: erasing chip
avrdude: reading input file "Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin"
avrdude: writing flash (4096 bytes):
Writing | ################################################## | 100% 3.13s
avrdude: 4096 bytes of flash written
avrdude: verifying flash memory against Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin:
avrdude: load data flash data from input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin:
avrdude: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin contains 4096 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 2.08s
avrdude: verifying ...
avrdude: 4096 bytes of flash verified
avrdude: reading input file "0x2F"
avrdude: writing lock (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x2F:
avrdude: load data lock data from input file 0x2F:
avrdude: input file 0x2F contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
./flash-ota -f HB-UW-Sen-THPL_update_V0_14_001_150301.eq3 -s UWS2370787
HomeMatic OTA flasher version 0.097-git
Reading firmware from HB-UW-Sen-THPL_update_V0_14_001_150301.eq3...
Firmware with 224 blocks successfully read.
Rebooting HM-CFG-USB to avoid running out of credits
HM-CFG-USB not in bootloader mode, entering bootloader.
Interrupt transfer not completed: Unknown error code 5 / 0x05!
Can't send null frame: No such device (it may have been disconnected)
Waiting for device to reappear...
Can't release interface: No such device (it may have been disconnected)
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB in bootloader mode, rebooting
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB opened
HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial UWS2370787
Wie krieg ich denn den Sensor in den Update-Mode? Irgendwie gibt der überhaupt kein Lebenszeichen mehr von sich...
Nach dem Power-On muss die LED 7-mal blinken (wegen V0.7), ansonsten läuft der Bootloader nicht korrekt. Du kannst dich auch mal per seriell verbinden. Beim Starten macht er auch Ausgaben in der Art "Asksin Bootloader 0.7" und dann zyklisch "Sending blabla". Falls das alles nicht kommt, dann ging irgendwas schief.
es blinkt überhaupt nichts mehr...
ZitatWie krieg ich denn den Sensor in den Update-Mode?
batterie raus, taster drücken, batterie rein und wenn der download anfängt (flackernde led), taster loslassen.
ZitatIrgendwie gibt der überhaupt kein Lebenszeichen mehr von sich...
sniffe einmal den sensor mit attr logIDs des hmusb.
es blinkt nichtmal mehr beim Einlegen der Batterien...
Ich hatte nach dem Flashen des Bootloaders das gleiche Problem: Gerät danach tot.
Bei mir lag es irgendwie daran, dass die hex2bin-Umwandlung nicht korrekt war. Wenn ich das Hex-File (ohne gepatchte Seriennummer/HMID) direkt geflasht habe, dann lief der Bootloader. Wenn ich jedoch das Skript benutzt habe, welches ja zunächst das Hex-File nach Bin wandelt, dann war der Sensor danach tot. Ich hab mir dann so beholfen: http://forum.fhem.de/index.php/topic,20620.msg269962.html#msg269962
Mag bei dir natürlich auch ganz was anderes sein... Aber probier doch einfach mal den unbehandelten Hex-Bootloader zu flashen. Ob er denn dann erstmal ein Lebenszeichen von sich gibt.
~/AskSinBootloader_Flash-Tool-RaspberryPi# bin/avrdude -Cbin/avrdude.conf -p atmega328p -P gpio -c gpio -e -Uflash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:r -Ulock:w:0x2F:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: erasing chip
avrdude: reading input file "Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex"
avrdude: writing flash (10744 bytes):
Writing | ################################################## | 100% 5.89s
avrdude: 10744 bytes of flash written
avrdude: verifying flash memory against Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:
avrdude: load data flash data from input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:
avrdude: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex contains 10744 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 5.09s
avrdude: verifying ...
avrdude: 10744 bytes of flash verified
avrdude: reading input file "0x2F"
avrdude: writing lock (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x2F:
avrdude: load data lock data from input file 0x2F:
avrdude: input file 0x2F contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Der einzige erkennbare Unterschied ist für mich, dass dabei 10744 Bytes geschrieben werden anstatt 4096 wie vorher.
Am Verhalten des Sensors ändert sich aber nichts :(
Edit: ich hab es nun auch mit "i" anstatt "r" als Format probiert, dann werden 32k geschrieben, was aber auch nix ändert.
Die einzige Idee, die ich noch hätte, wäre, zu gucken, ob die Fuse-Bits richtig gesetzt sind. Ich hatte zum Beispiel mal händisch die Fuse-Bits, die die Größe des Bootbereichs angeben, von 2k auf 4k ändern müssen. Davor ging gar nix. Aber soviel ich weiß, macht das alles das Flash-Skript schon für dich. Ich meinen ersten Versuch mit AVRStudio gemacht und da musste ich eben alles händisch machen.
Hier ein Post von Dirk, wo drinsteht, wie die Fuses gesetzt sein müssen:
http://forum.fhem.de/index.php/topic,20620.msg269627.html#msg269627
Zitat von: vbs am 14 März 2015, 14:57:47
Die einzige Idee, die ich noch hätte, wäre, zu gucken, ob die Fuse-Bits richtig gesetzt sind.
von sowas hab ich keine Ahnung :(
so... den zweiten Sensor habe ich auf die gleiche Art und Weise jetzt auch umgebracht *grummel*
Zitatvon sowas hab ich keine Ahnung
ist auch nicht nötig. genauso wie beim flashen, nur einen anderen befehl. als bsp aus dem git vom bootloader:
avrdude -p m328p -P usb -c usbasp -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m
Du bist mein Held, ich sehe rote Lichtzeichen. Jetzt muss ich die nur noch "interpretieren"...
ZitatJetzt muss ich die nur noch "interpretieren"
einfach sniffen.
da kommt nix zum sniffen...
Ich fasse mal zusammen:
Wenn ich das HEX File (ohne Id und Seriennummer) zusammen mit den fuse bits flashe, bekomme ich hinterher 7 mal rotes Blinken.
Aber in fhem bekomme ich mit logIDs all,sys keine verwertbaren Infos, ausserdem hätte ich ja gerne die gleiche HMId und S/N wie vorher auch.
Also muss ich irgendwie den von vbs beschriebenen Weg gehen, um ein brauchbares BIN file zu bekommen.
http://forum.fhem.de/index.php/topic,20620.msg269962.html#msg269962
Kann mir jemand den aufgeführten Schritt 2 (Auslesen des geschriebenen HEX files aus dem Sensor) erklären?
Zitat von: betateilchen am 14 März 2015, 17:31:15
da kommt nix zum sniffen...
doch, da kommt was:
2015-03-14 17:35:53.893600: 14000010ABCDEF0000000048423044656661756C74
Packet information:
Length: 20
Message ID: 0
Sender: abcdef
Receiver: 000000
Control Byte: 0x00
Flags:
Message type: Information (0x10)
Mesage: 0048423044656661756C74
Im Prinzip so ähnlich, wie du auch geflasht hast, aber nun mit "r" anstatt "w". Also irgendwie so in der Art:
~/AskSinBootloader_Flash-Tool-RaspberryPi# bin/avrdude -Cbin/avrdude.conf -p atmega328p -P gpio -c gpio -Uflash:r:outbin.bin:r
Moment mal, war dein Flash-Aufruf nicht falsch?
-Uflash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:r
Das letzte "r" gibt ja das Format an und "r" bedeutet raw-binary. Übergeben hast du aber scheinbar ein Intel-Hex-File. Hm...
Und ja, du musst auf jeden Fall Seriennummer und HMID mit in den Bootflasher.
das hex-file hab ich mit "i" geschrieben, nachdem mir der Fehler mit dem "r" klarwurde (steht auch schon weiter oben)
Im Moment bin ich soweit:
(http://up.picr.de/21278664hb.png)
Das ist quasi die Firmware auf einem Sensor mit Bootloader (hex-File) mit seinen Defaultwerten - der Sensortyp fehlt deshalb noch komplett.
Aber ich hoffe, das bekomme ich jetzt auch noch hin. Als nächstes probiere ich mal das von Dir beschriebene Auslesen.
Wieder ein Stück weiter:
(http://up.picr.de/21278946fc.png)
Seriennummer und HMId sind nun korrekt.
Aber ich bekomme keine Wetterdaten in den readings, ein getConfig funktioniert nicht und model in den Attributen steht auf "unknown".
Hui,
Da ist man mal "kurz" beim einkaufen und schon ist hier was los :)
Sorry Udo dass du hier so große Probleme hast.
Ich werde mir mal überlegen wie ich das Flashen vom Bootloader einfacher gestalten kann.
Wenn du das Flash wieder ausgelesen hast, kannst du dort mit einem Hex-Editor die Daten ändern.
In den letzten 15 Bytes stehen die Relevanten Informationen
1 - 2. Byte ist die Model-ID. Also z.B. F1 01
3 -12. Byte ist die Seriennummer (Ascii)
13 - 15. Byte Sind die 3 Bytes der HM-ID.
Viele Grüße
Dirk
warum nicht einfach ein neues hexfile bauen? ist das nicht viel einfacher. hier http://forum.fhem.de/index.php/topic,18071.msg208657.html#msg208657 (http://forum.fhem.de/index.php/topic,18071.msg208657.html#msg208657) habe ich das mal für den sw1pbu beschrieben. es muss dann nur der name geändert werden. diese "HB-UW-Sen-THPL.h" datei ändern, und dann
make clean HB_UW_Sen_THPL
fertig ist der bootloader.
Zitat von: betateilchen am 14 März 2015, 18:16:17
Aber ich bekomme keine Wetterdaten in den readings, ein getConfig funktioniert nicht und model in den Attributen steht auf "unknown".
Das ist aktuell ein kleiner Bug.
Man muss die Config-Taste so oft drücken, bis alle Config-Daten übertragen wurden.
Das kann auch schon mal 3-4 mal sein.
Wenn die LED nach dem Drücken ca. 20 sek. weiter blinkt, sollte alles durch sein.
Ach und die neue HMConfig_SenTHPL.pm solltest du auch ins FHEM-Verzeichniss kopieren.
Zitat von: frank am 14 März 2015, 18:26:05
warum nicht einfach ein neues hexfile bauen? ist das nicht viel einfacher.
Weil das mit dem Flash-Tool normalerweise automatisch geht.
Und nicht jeder kann / möchte erst den Compiler anwerfen.
Gruß
Dirk
ZitatWeil das mit dem Flash-Tool normalerweise Automatisch geht.
Und nicjt jeder kann / möchte erst den Compiler anwerfen.
nur wenn "normalerweise" nicht funktioniert. ;)
Ich habe hier schon den Prototyp vom Flashscript liegen welches dann ohne hex2bin auskommt. Und, so der plan, dann nur noch avrdude benötigt.
Das Ganze wird dann Perl, sollte dann also auch weitestgehend Plattformunabhängig sein.
es tut sich nichts bezüglich Wetterdaten in den readings...
(http://up.picr.de/21279308js.png)
örks... ich weiss, wieso. Ich hab beim Type 1F:02 anstatt F1:02 eingetragen.
Also die ganze Prozedur nochmal von vorne...
Das war der härteste Kampf gegen Homematic ever...
(http://up.picr.de/21279686vd.png)
Zitat von: betateilchen am 14 März 2015, 19:16:53
Das war der härteste Kampf gegen Homematic ever.
Und was ist das für ein Gefühl ihn gewonnen zu haben? :-)
Na cool das das jetzt bei dir geklappt hat. Wenn auch mit Hindernissen.
Dafür geht es beim nächsten Update dann viel einfacher :)
Ich danke allen, die mir hier gestern und heute bei der Problemlösung mit Tipps geholfen haben!
Die Runde geht auf mich...
(http://up.picr.de/21279817la.jpg)
Zitat von: Mr. P am 14 März 2015, 19:23:00
Und was ist das für ein Gefühl ihn gewonnen zu haben? :-)
Willst Du eine ehrliche Antwort? Es ist nichts weiter als Frust.
Zitat von: Dirk am 14 März 2015, 19:23:59
Dafür geht es beim nächsten Update dann viel einfacher :)
viel einfacher fand ich den seriellen Bootloader...
Zusammenfassung der letzten beiden Tage für jemand wie mich
- ich lasse mal den seriellen Bootloader und die Firmware 0.12 drauf und gehe halt ab und zu resetten
oder
- ich nehme mir mal (also nie) ganz viel Zeit und aktualisiere auf OTA Bootloader
Trotzdem noch mal die Frage:
Funktioniert OTA mit einem CUL überhaupt, oder sollte ich die lieber die Finger davon lassen?
Danke + Gruß
PeMue
Zitat von: PeMue am 14 März 2015, 20:12:32
Funktioniert OTA mit einem CUL überhaupt, oder sollte ich die lieber die Finger davon lassen?
Ja. Mit flash-ota.
Ich bin am kommenden Wochenende in Karlsruhe.
Da könnte ich dort den einen oder anderen Sensor updaten.
Viele Grüße
Dirk
Zitat von: Dirk am 14 März 2015, 20:15:03
Ja. Mit flash-ota.
Radio Eriwan sagt: "Im Prinzip schon..." 8)
Mich würde ja brennend interessieren, was denn nun genau das Problem beim hex2bin ist, damit das Update nicht funktioniert.
Letztendlich waren es hier ja zwei poplige Ursachen, die zu den Problemen führten.
- die fuse bits
- der Fehler bei hex2bin
Welches Update-Script hattest du denn benutzt?
Ich kann mir das die Tage noch mal ansehen.
Denn das interessiert mich auch.
Die Fuse-Bits werden ja auch durch das Script gesetzt.
Ich habe das Skript von hier benutzt:
http://www.lxccu.com/hb-raspberry-bootloader-update
Letztendlich hatte ich dann dort das Setzen der fuse-bits wie hier vorgeschlagen
http://forum.fhem.de/index.php/topic,20620.msg273418.html#msg273418
mit in den Aufruf von avrdude eingebaut.
Im Skript selbst hatte ich den Aufruf von hex2bin auskommentiert und den Aufruf von avrdude angepasst, je nachdem, ob ich das (unveränderte) hex-File oder das (zurückgelesene) bin File flashen wollte.
Wenn man weiss, wo man ansetzen muss, ist das Ganze relativ schnell erledigt, wenn auch völlig unlogisch vom eigentlichen Ablauf.
Zitat von: betateilchen am 14 März 2015, 20:34:38
Ich habe das Skript von hier benutzt:
http://www.lxccu.com/hb-raspberry-bootloader-update
Ah, ok. Von dem Script bin ich bisher immer nur ausgegangen das das funktioniert. Das ist nicht von mir.
Ich werde mal sehen, dass ich das überarbeitet Script so schnell als möglich fertig bekomme.
Ansonsten möglichst das Windows-Script aus dem Git-Repo benutzen.
Ein Windows Skript auf einem Raspberry zu verwenden, ist "schwierig" ...
Zitat von: betateilchen am 15 März 2015, 10:21:26
Ein Windows Skript auf einem Raspberry zu verwenden, ist "schwierig" ...
Daher schrieb ich ja "möglichst"
Ich schaue aber mal, dass ich das Script wie geplant nach Perl portiere.
Naja, ich hab ja gestern das verwendete Skript überarbeitet, damit es funktioniert.
Nur das hex2bin Problem konnte ich nicht skript-intern lösen. Deshalb der Umweg über das Zurücklesen. Dazu muss eben das Skript zweimal modifiziert werden, damit es sowohl bin als auch hex files schreiben kann (ich hab das Skript einfach kopiert und den avrdude Aufruf jeweils angepasst). Bei mir gibt es also ein "hexflash.pl" und ein "binflash.pl", die bis auf 4 geänderte Bytes identisch sind:
".bin:r" vs. ".hex:i"
Ich kann Dir gerne das Skript, so wie ich es gestern verwendet habe, per Mail schicken, wenn Dir das weiterhilft. Das Skript ist ja immerhin schon in perl.
Zitat von: Dirk am 14 März 2015, 20:15:03
Ich bin am kommenden Wochenende in Karlsruhe.
Da könnte ich dort den einen oder anderen Sensor updaten.
Hallo Dirk,
bin leider musikalisch am nächsten Wochenende ziemlich eingespannt, werde wohl nicht kommen können.
Daher hilft mir nur: selber lernen. Aber ich bin zuversichtlich ;)
Gruß PeMue
Zitat von: Dirk am 13 März 2015, 13:10:02
Ja, das passt. So mach ich das bei den Sensoren :)
Das Bild passt nicht exakt zu den gelieferten Modulen. Die Löcher für die Stiftleisten waren halbiert. Lassen sich also wunderbar auch SMD bestücken.
Hi Dirk,
welches Rastermaß haben die Pins auf dem Modul? Mit 2,54mm bekomme ich bei 17mm (17x19mm lt. Beschreibung) keine 8 Stück nebeneinander.... 8x2,54 = 20.32mm
Hi Tobias,
müsste ich noch mal ausmessen.
Wenn du willst, kann ich dir meine Eagle-Lib schicken.
Da hatte ich das Teil schon mal gebaut.
Viele Grüße
Dirk
Zitat von: Dirk am 20 März 2015, 11:53:11
Hi Tobias,
müsste ich noch mal ausmessen.
Wenn du willst, kann ich dir meine Eagle-Lib schicken.
Da hatte ich das Teil schon mal gebaut.
Viele Grüße
Dirk
Ich nutze Target3001, ev. kannst du es als CXF Datei exportieren??
Nur mal so nebenbei...
(http://up.picr.de/21336700ry.jpg)
Die kleine Platine links in der unteren Gehäusehälfte ist die Ladeelektronik für die LiIon Zelle ganz rechts im Gehäusedeckel neben der Platine. Das Laden kann per USB Kabel durch das Batteriefach erfolgen.
(http://up.picr.de/21336733ge.jpg) (http://up.picr.de/21336793ul.jpg)
Aber da die Zelle eine ziemlich hohe Kapazität hat und der Energieverbrauch des Sensors inzwischen doch in einem relativ kleinen Bereich liegt, denke ich, dass ein Aufladen maximal einmal pro Jahr nötig sein wird.
Hi Betateilchen, dann setz doch mal bitte auch einen Link zu deiner Ladeelektronik mit rein. Ich denke das hast du im Chinashop fertig gekauft, korrekt?
Zitat von: Tobias am 20 März 2015, 14:02:57
Ich denke das hast du im Chinashop fertig gekauft, korrekt?
Korrekt. Findet man beispielsweiese bei ebay, wenn man nach TP4056 sucht. Alternative Quellen: Pollin und Amazon.
so sieht übrigens eine sonnenfinsternis beim sensor aus. luminosity gestern und heute, wetter jeweils heiter.
(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=29577;image)
(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=29575;image)
gruss frank
Aber von wegen "Mond schiebt sich zwischen Erde und Sonne"... sowas passiert, wenn der griechische Finanzminister seinen Mittelfinger in den Himmel reckt!
Hallo,
jetzt habe ich auch mal wieder eine Frage.
Ich habe mir nun einen Sensor mit Temp/Luftfeuchte und Luftdruck gebaut.
Fhem legt das Device automatisch an, aber es wird kein Plot automatisch angelegt. Ist das so gewünscht?
Wie macht Ihr das eigentlich, dass ein Plot mit allen drei Werten sauber dargestellt wird.
Hat mir einer vielleicht mal ein Konfigurationsbeispiel?
Gruß
Björn
Zitat von: bjoernh am 20 März 2015, 23:01:47
Wie macht Ihr das eigentlich, dass ein Plot mit allen drei Werten sauber dargestellt wird.
Ich gehe in die Detailansicht des FileLog, klicke dort auf den Link "Create SVG" und suche mir die drei Spalten aus, die ich dargestellt haben möchte. In weniger als zwei Minuten ist der Plot exakt so definiert, wie ich ihn mir vorstelle.
Frage: Wenn die Batteriespannung schon nur noch mit einer Dezimalstelle ausgegeben wird, könnte man dann nicht gleich das Format von zweistellig nach dem Komma auf einstellig ändern? Ich hab das jetzt mal lokal in der HMConfig... für mich umgesetzt.
Irgendwie wäre mir sogar die Möglichkeit, die readings des Sensors runden zu können, noch lieber. Mir reicht z.B. der Luftdruck ohne Nachkommastelle.
Zitat von: betateilchen am 21 März 2015, 13:05:11
Frage: Wenn die Batteriespannung schon nur noch mit einer Dezimalstelle ausgegeben wird, könnte man dann nicht gleich das Format von zweistellig nach dem Komma auf einstellig ändern? Ich hab das jetzt mal lokal in der HMConfig... für mich umgesetzt.
Das hatte ich in einer kommenden Version vor.
Aktuell ist das aus Kompatibilitätsgründen noch so drin.
Der Sensor sendet die Spannung daher auch noch in 2 Bytes. Obwohl da auch 1 Byte ausreichen würde.
ZitatIrgendwie wäre mir sogar die Möglichkeit, die readings des Sensors runden zu können, noch lieber. Mir reicht z.B. der Luftdruck ohne Nachkommastelle.
Aktuell geht das nur über stateFormat
Gruß
Dirk
Zitat von: Dirk am 21 März 2015, 13:17:02
Der Sensor sendet die Spannung daher auch noch in 2 Bytes.
das hat aber nichts mit dem sprintf() zu tun, das Du derzeit zum Schreiben des readings verwendest.
Zitat von: Dirk am 21 März 2015, 13:17:02
Aktuell geht das nur über stateFormat
Das nützt mir nix, weil per longpoll das reading immer mit zwei Nachkommstellen verschickt wird.
Zitat von: betateilchen am 21 März 2015, 13:24:27
das hat aber nichts mit dem sprintf() zu tun, das Du derzeit zum Schreiben des readings verwendest.
Nein, Das betrift nur die physische Übertragung im Funkprotokoll.
ZitatDas nützt mir nix, weil per longpoll das reading immer mit zwei Nachkommstellen verschickt wird.
Das sollte auch über longpoll funtionieren.
Tut es bei mir zumindest.
Zitat von: Dirk am 21 März 2015, 13:29:16
Das sollte auch über longpoll funtionieren.
Meine Aufgabenstellung:
- Luftdruck ohne Nachkommastelle
- Spannung mit einer Nachkommstelle
- Temperatur mit einer Nachkommastelle
Und das alles als
einzelne Readings per longpoll. Wie machst Du das mit stateFormat? Ich habe keine andere Lösung gefunden, als die HMConfig anzupassen.
Warum geht das nicht per userreadings?
Probier das mal so:
{my $t=ReadingsVal($name, 'TEMPERATURE', 0); my $p=ReadingsVal($name, 'AIR_PRESSURE', 0); my $b = ReadingsVal($name, 'BatteryVoltage', 0); sprintf('Temperatur: %.1f °C, Luftdruck: %d HPa, Batterie: %.1f V', $t, $p, $b);}
Dirk, wir reden grade völlig aneinander vorbei :(
Zitat von: betateilchen am 21 März 2015, 13:38:24
Und das alles als einzelne Readings per longpoll. Wie machst Du das mit stateFormat? Ich habe keine andere Lösung gefunden, als die HMConfig anzupassen.
Ok, Diesen Satz hatte ich überlesen.
Daher geht das wohl nur über deinen beschriebenen Weg.
Hey Dirk,
Soweit funktionieren die Sensoren alle.
Nur bei einen Sensor (03) habe ich einen Batterie Wert von 6,4 V.
(hätte beim den 3er nicht auch ein Plexiglasstift dabei sein sollen?)
Und bin noch nicht ganz fertig mit dem Durchlesen wegen CCU2 Einbindung (noch nicht gefunden)
Gruß Gerd
Zitat von: Inputsammler am 22 März 2015, 20:53:46
(hätte beim den 3er nicht auch ein Plexiglasstift dabei sein sollen?)
Das ist richtig. wenn der Fehlt schick ich dir einen nach.
ZitatUnd bin noch nicht ganz fertig mit dem Durchlesen wegen CCU2 Einbindung (noch nicht gefunden)
Die CCU möchte ein Addon:
https://github.com/kc-GitHub/Wettersensor/raw/v0.14_beta/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon.tgz
Aktuell gibt es Probleme mit dem Sensor und der aktuellsten CCU2 FW.
Da wird der Luftdruck nicht mehr angezeigt. Das muss ich noch untersuchen.
Viele grüße
Dirk
Hallo Dirk,
ich habe mal versucht die neue Firmware 0.14 mit der Arduino IDE auf meinen Sensor zu spielen.
Nicht nur, um meinen Sensor zu aktualisieren, für mich währe es auch interessant, wenn man auch die Ardunino IDE benutzen könnte.
Kompilieren des Codes mit der Arduino 1.6.0 geht problemlos. Auch das programmieren des Sensors über ISP Programmer (usbAsp) funktioniert.
Da der Sensor alle paar Minuten blinkt, denke ich dass er grundsätzlich funktioniert.
Beim Pairen mit FHEM siehts aber nicht so gut aus, hier der Eintrag in der fhem config:
define HM_555253 CUL_HM 555253
attr HM_room CUL_HM
define FileLog_HM_555253 FileLog ./log/HM_555253-%Y.log HM_555253
attr FileLog_HM_555253 logtype text
attr FileLog_HM_555253 room CUL_HM
Denke da ist noch ein Problem mit der Device ID, Serial...
Die DEVICE_ADDRESS sollte ja 0xAB, 0xCD, 0xEF lauten, wie in der WetterSensor.h definiert.
Die #define USE_ADRESS_SECTION habe ich in der WetterSensor.h und in der AskSinMain.h auf 0 gesetzt.
Ebenso habe ich in FHEM die neue HMConfig_SenTHPL.pm.
Hast Du einen Tipp für mich?
Danke und Gruss Martin
Hallo,
Genau dieser Weg über die Arduino Soft würde mich auch interessieren, ist halt nicht so umständlich.
LG
Stefan
Hi Martin,
Zitat von: mmatt am 27 März 2015, 08:47:38
Denke da ist noch ein Problem mit der Device ID, Serial...
Die DEVICE_ADDRESS sollte ja 0xAB, 0xCD, 0xEF lauten, wie in der WetterSensor.h definiert.
Kommt drauf an wie die Einstellungen hier sind.
Hast du den Bootloader selber gebrannt? Ansonsten sind HM-ID, Seriennummer usw. Im Bootloader integriert.
Und je nach Einstellungen im Quellcode wird der Sensor die Daten daraus beziehen.
Zeig mal das Telegramm was der Sensor beim Drücken der Configtaste schickt.
Zitat von: Porky666 am 27 März 2015, 09:47:21
Genau dieser Weg über die Arduino Soft würde mich auch interessieren, ist halt nicht so umständlich.
Kommt drauf an :)
Gruß
Dirk
Hallo Dirk,
nur mal so interessehalber: mit welcher Formel/Faktor rechnest Du den Lux-Wert in Luminosity um?
Gruß
Peter
Zitat von: PumpkinEater am 28 März 2015, 11:25:28
... mit welcher Formel/Faktor rechnest Du den Lux-Wert in Luminosity um?
Ich meine, Dirk liest direkt mit der auf S. 23 im Datenblatt des TSL2561 (http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CCwQFjAA&url=http%3A%2F%2Fwww.adafruit.com%2Fdatasheets%2FTSL2561.pdf&ei=9eAXVeOZKInAOeikgIgE&usg=AFQjCNG84pWI0TCh1Qq4lvD5wyk26t0UpQ&bvm=bv.89381419,d.ZWU&cad=rja) in Lux aus. Ohne Filterfolie ist dann bei kurz über 40000 Schluss da der Sensor übersteuert. Aber ich kann mich auch irren ...
Ich habe aber bei meiner Konfiguration noch eine Frage:
Wenn ich mit
rereadcfg die fhem Konfiguration neu einlese, muss ich meine beiden Sensoren neu pairen. Meine Homematic Sensoren/Aktoren im Bad "überleben", d.h. sie bleiben gepairt.
Was mache ich falsch?
Meine Konfiguration:
1xAußensensor, 1xInnensensor jeweils FW v0.12, fhem auf FB7490 mit CUL, ich habe die HMConfig_SenTHPL.pm aus dem Firmwarepaket v0.12 (oder kann ich da bei Beibehaltung der Firmware auf die aktuelle aus dem Repository aktualisieren)?
Danke + Gruß
PeMue
Stand mal irgendwo: Die Folie lässt 25% Licht durch.......Also den Wert vom Sensor * 25 gibt die tatsächlichen Lux, soweit ich mich erinnere (oder wird das direkt im Sensor schon hochgerechnet?)
Hi Peter,
Zitat von: PumpkinEater am 28 März 2015, 11:25:28
nur mal so interessehalber: mit welcher Formel/Faktor rechnest Du den Lux-Wert in Luminosity um?
Eine Übersicht findet man dazu im Wiki:
http://www.fhemwiki.de/wiki/Universalsensor#Der_Helligkeitssensor
Das hatte ich letzten Sommer mit meinem Luxmeter verglichen.
Zitat von: PeMue am 29 März 2015, 13:33:32
Aber ich kann mich auch irren ...
Nein, das ist vollkommen korrekt.
ZitatWenn ich mit rereadcfg die fhem Konfiguration neu einlese, muss ich meine beiden Sensoren neu pairen.
Wie meinst du das?
Normalerweise ist das Peering im Eeprom gespeichert. Daher sollte das erhalten bleiben.
Zitatich habe die HMConfig_SenTHPL.pm aus dem Firmwarepaket v0.12 (oder kann ich da bei Beibehaltung der Firmware auf die aktuelle aus dem Repository aktualisieren)?
HMConfig_SenTHPL.pm aus dem 0.12er und dem 0.14er-Tag unterscheiden sich hier nur unwersentlich. Daher kannst du auch die aktuelle benutzen.
Zitat von: Icinger am 29 März 2015, 13:50:35
Stand mal irgendwo: Die Folie lässt 25% Licht durch.......Also den Wert vom Sensor * 25 gibt die tatsächlichen Lux, soweit ich mich erinnere
Fast. Es sind Sensorwert * 4. weil 25% = 1/4 :)
Ich habe das letzten Sommer auch eine Testsreihe mit der Folie und meinem Luxmeter gemacht.
Hier bin ich auf einen Faktor von 0,265 gekommen.
Mit Folie bekommt man mit einer Division durch 0,265 auf den aktuellen Lux-Wert:
$lux = $lum/0.265
Zitat von: Icinger am 29 März 2015, 13:50:35
oder wird das direkt im Sensor schon hochgerechnet?
Noch nicht. Das wollte ich dem Sensor mit einer nächsten FW-Version spendieren.
Viele Grüße
Dirk
Edit: Ich habe dir Formel im Wiki mal ergänzt.
Hallo zusammen,
ich muss noch mal nachhaken. Ich habe zwei Außensensoren, der eine mit Folie, der andere ohne Folie. Der Sensor mit Folie weist einen Wert von ungefähr 30-32 Prozent des anderen Sensors auf. Sollte also grob passen.
Mir war allerdings aufgefallen, dass die Werte der Sensoren deutlich geringer sind als z.B. bei Wikipedia als übliche Luxwerte angegeben. Außerdem gehen die Sensoren bereits bei 10000 in die Begrenzung. Ich habe dann in diesem Thread einen Beitrag #459 von Dirk gefunden:
(http://forum.fhem.de/index.php/topic,20620.msg160696/topicseen.html#msg160696%5B/url)
ZitatIch habe das Helligkeits-Reading von Lux nach Luminosity geändert, da der wert in Lux nur stimmt, wenn das Licht ungefiltert auf den Sensor fällt. Ansonsten muss man das entsprechend umrechnen.
Daher dachte ich, dass bei der Änderung von Lux auf Luminosity eine Umrechnung stattfindet, die vielleicht meine abweichenden Werte erklärt.
Gruß
Peter
Hallo Dirk,
Zitat von: Dirk am 29 März 2015, 15:31:27
Wie meinst du das?
Normalerweise ist das Peering im EEPROM gespeichert. Daher sollte das erhalten bleiben.
Uups, vielleicht habe ich da auch etwas falsch verstanden. Ich habe in der Firmware jeweils eine eigene HMID (und die eineindeutige Seriennummer) für den jeweiligen Sensor einprogrammiert.
Hier http://forum.fhem.de/index.php/topic,20620.msg210781.html#msg210781 wurde das Thema diskutiert.
Vermutlich hätte ich dem Sensor die HMID meiner Zentrale einprogrammieren sollen, und mit define <sensorname> CUL_HM <HMID_sensor> dem Sensor eine eigene HMID zuweisen sollen, die aber nicht im EEPROM des Sensors steht.Danke + Gruß
PeMue
Edit:
Der Sensor bekommt seine eigene HMID und diese wird auch bei der Definition in fhem zugeordnet:
define HM_Dach_T_P_L CUL_HM F10001Die HMID der Zentrale (sprich bei mir des CULs) ist F1:00:00, allerdings wird der Sensor nach Neustart von fhem bzw. nach
rereadcfg nicht mehr erkannt. Hat jemand eine Idee, was ich falsch mache?
Sorry, etwas offtopic: Aber was ich schon immer wissen wollte und nie zu fragen gewagt habe:
Warum gibt es eine eindeutige Seriennummer UND die HMID? Wo ist der Unterschied? Sind doch beide dazu da, das Gerät eindeutig zu identifizieren, oder?
Was sich die Entwickler genau dachten, weiß ich leider nicht, kann mir aber eine Art einfache Sicherheitsfunktion vorstellen. Die HM-ID wird ja immer gesendet. Eie Abrbeits-ID sozusagen. Mit der SerialNummer kann man die (ungepairte) Devices pairen. In vielen Fällen ganz ohne sie "in die hand" nehmen zu müssen.
Weiß jemand die Bedeutung genau?
Hallo Dirk,
ZitatHast du den Bootloader selber gebrannt?
Zuerst ein Versuch ohne Bootloader per ISP-Programmer über die Arduino IDE, dabei wird der Bootloader beim programmieren entfernt. (Soweit ich das weiss)
Danach ein Versuch mit dem Standart Arduino Bootloader.
Beides hat beim Pairing zum gleichen Ergebnis geführt.
ZitatZeig mal das Telegramm was der Sensor beim Drücken der Configtaste schickt.
Wo kann man das am besten sehen? Hier die serielle Debug Ausgabe der Arduino IDE:
1A 14 A2 00 55 52 53 F1 10 34 69 6E 20 63 6F 6E 66 69 67 20 6D 6F 64 65 0A 00 42 (l:27)<- � (2396777)
-> (2397091)
10 01 A0 01 F1 10 34 55 52 53 00 05 00 00 00 00 00 (l:17)��0A 01 80 02 55 52 53 F1 10 34 00 (l:11)<- � (2397099)Kannst Du etwas daraus lesen?
Grüsse Martin
Hallo Leute,
ich habe Probleme, den Sensor als abgesetzte Temperaturerfassung an meine Heizungsregler anzulernen.
Ich benutze die "neue" Version HM-CC-RT-DN mit Firmware 1.4.
Der Sensor hat die Firmware 0.14. Als HMID und Serial habe ich mir etwas Willkürliches ausgedacht.
Die Anbindung an FHEM mache ich mit einem HMLAN.
Ich habe Regler und Sensor komplett resettet.
Ich bringe den Regler mit langem Druck auf Boost in den Pair-Modus, danach drücke ich den Config-Knopf auf dem Sensor.
Regler, die schon mit meinem HMLAN verbunden sind, geben ein F4 ("es ist bereits eine Zentrale angelernt") zurück, dabei müsste doch für den Sensor ein Slot frei sein, oder nicht? Der Sensor ist ja keine Zentrale.
Regler, die komplett resettet sind, geben ein nAC zurück, auch, wenn ich mehrmals auf den Config-Knopf drücke.
Das Anlernen an den HMLAN funktioniert ohne Probleme.
Hat jemand ähnliche Probleme?
Viele Grüße,
Spiff.
Zitat von: Spiff am 02 April 2015, 23:04:19
Hat jemand ähnliche Probleme?
Ich glaube, die Frage müsste eher lauten, ob das jemand überhaupt schon einmal gemacht hat. :-)
Ich könnte mich jetzt zumindest nicht daran erinnert, so etwas schon einmal hier gelesen zu haben. Scheinen alle den Sensor zuerst mit der Zentrale zu pairen und dann über diese den Sensor mit dem Thermostaten verknüpfen.
Mal abwarten, was Dirk zu deiner Frage sagt - interessiert mich jetzt selbst, ob das schon einmal probiert wurde. :-)
Hallo,
gibt es eigentlich eine Anleitung wie man ein Firmware update mit dem USB-Serial-Adapter durchführt und wie dieser angeschlossen wird ?
Funktioniert das auch über Windows mit der Arduino Software ?
Gruß Holgi
Hallo Holgi,
ich habe mir mal etwas zusammenkopiert, siehe Bild (http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=30341;image).
Du musst auf ein paar Punkte achten:
- der USB-seriell Wandler muss 3,3 V Pegel haben
- die Versorgungsspannung ist nicht notwendig
- der Anschluß ist nicht seitlich wie beim Arduino, sondern oben wie im Bild links
Zum Flashen kannst Du das Windows Flash Tool aus dem 0.12er Zweig (https://github.com/kc-GitHub/Wettersensor/archive/v0.12.zip) der Software nehmen, für die 0.14er Version geht das noch nicht, die 0.13 hat Dirk wohl nie veröffentlicht (zumindest nicht auf Github).
Oder Du compilierst die Software selber, dann geht auch die Arduino IDE, ob das einfacher ist, weiß ich nicht ;D
Viel Erfolg.
Gruß PeMue
Hi Peter,
das wäre doch eine schöne Ergänzung auf der wiki-Seite.
Soll ich das übertragen?
Hi Mr. P,
das direkte Peeren scheint noch nicht zu gehen.
Wie ist denn der Weg über fhem genau?
Ich habe ausprobiert:
set <sensChan> peerChan 0 <actChan> single set
Muss ich die Geräte in den Peering-Modus versetzen? Wann genau?
Und wie kann ich erkennen, dass es mit dem Peering tatsächlich geklappt hat?
Viele Grüße
Spiff
Hej Spiff,
bin gerade nicht vor einem Computer, aber schau einfach ins FHEMwiki beim Thermostaten rein.
Dort steht dann mitunter, wie das Peering vom Weather-Channel funktioniert. ;-)
Zitat von: Spiff am 03 April 2015, 11:18:03
... das wäre doch eine schöne Ergänzung auf der wiki-Seite.
Soll ich das übertragen?
Hallo Spiff,
gerne, aber dann nimm ein vernünftiges Bild (http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=30365;image) ;D
Bitte aber vorher noch einmal die Verdrahtung prüfen, vier Augen sehen mehr als zwei ...
Danke + Gruß
PeMue
Hallo PeMue, danke für die Info. Die 0.12 habe ich auf dem Sensor. Kann ich mit dem flashtool der 0.12 Version die 0.14 flashen ?
Gruß Holgi
Hallo Holgi,
Zitat von: PeMue am 03 April 2015, 05:12:58
... für die 0.14er Version geht das noch nicht ...
Oder Du baust um auf OTA bootloader ;). Was das bedeutet, ist in betateilchens Anstrengungen auf mehreren Seiten (ab S. 108 ff) nachzulesen.
Gruß PeMue
Hm, ok. OTA geht leider nicht da ich noch den alten HMLan Adapter habe.
Hallo,
ich scheitere an 115 Seiten :-[
gibt es eine Schritt für Schritt Anleitung zum Flashen der Sensoren mit dem Pi?
(welcher Pin Pi an welchen Pin Sensor - Im Wiki-Photo nur zu erahnen, Software, etc)
Ich würde gerne einen Außen- und einen Innensensor auf die aktuelle Firmware bringen (serieller Bootloader).
Die Suchfunktion hat mich nicht beglückt und ich bin für jede Antwort dankbar!
(z.B. "Du Ignorant, steht doch ganz eindeutig auf Seite 75 des Threads" :))
Vielen Dank Boris
Zitat von: Dirk am 23 März 2015, 21:18:05
Aktuell gibt es Probleme mit dem Sensor und der aktuellsten CCU2 FW.
Da wird der Luftdruck nicht mehr angezeigt. Das muss ich noch untersuchen.
Hallo Dirk,
ich hatte das Problem mit der fehlenden Luftdruckanzeige ja gemeldet. Teilweise kann ich jedoch Entwarnung geben: Der Luftdruck wird auch mit der neuesten CCU2-Firmware 2.13.7 korrekt angezeigt. Da ich das Sensor-Addon nicht auf die CCU2 aufspielen konnte, hatte ich dies manuell gemacht: Auf dem Windows-PC das AddOn-File entpackt und die Files /firmware/rftypes/* per scp auf die CCU2 kopiert. Danach wurde der Luftdruck nicht angezeigt. Ich habe das Ganze jetzt noch mal wiederholt, aber das Addon-tar.gz-File direkt auf der CCU2 entpackt und dann die Files in die richtigen Ordner kopiert. Nun wird auch der Luftdruck richtig angezeigt. Ich vermute, dass beim Entpacken auf dem Windowsrechner ein dos/unix-Formatproblem aufgetreten ist (CRLF), und das xml-File dann von der CCU2 nicht mehr richtig gelesen wurde.
Es bleibt also nur noch das Problem, dass die CCU2 das Addon nicht installieren will (mittels "Zusatzsoftware installieren").
Gruß
Peter
Zitat von: Bkel am 03 April 2015, 20:05:04
... gibt es eine Schritt für Schritt Anleitung zum Flashen der Sensoren mit dem Pi?
(welcher Pin Pi an welchen Pin Sensor - Im Wiki-Photo nur zu erahnen, Software, etc)
Ich würde gerne einen Außen- und einen Innensensor auf die aktuelle Firmware bringen (serieller Bootloader).
Hallo Boris,
gerade auf dieser (http://forum.fhem.de/index.php/topic,20620.msg281346.html#msg281346) Seite habe ich etwas geschrieben, also nochmal:
- (3,3V) USB-seriell Wandler an den Sensor anschließen, Bild siehe hier (http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=30365;image)
- Batterie in den Sensor einlegen
- v0.12 Software von hier (https://github.com/kc-GitHub/Wettersensor/archive/v0.12.zip) herunterladen und auspacken
- die hex/bin Dateien in das Verzeichnis Flash-Tool-Windows kopieren
- in einem (Windows) Eingabeaufforderungsfenster in das Verzeichnis Flash-Tool-Windows navigieren
- folgenden Befehl eingeben
flash <comport> HB-UW-Sen-THPL-O_update_V0_12_001_140922.hex <HMIDsensor> <serialsensor> , wobei Du den COM Port aus dem Gerätemanager bekommst (z.B. COM5),
die HMID ist sechsstellig hex., z.B. AB:CD:EF und die Seriennummer ist zehnstellig, ASCII, z.B. USO123456 (
Universal
Sensor
Outdoor), für den Innensensor entsprechend mit I statt O ...
Gruß PeMue
Hallo PeMue,
den Post hatte ich schon gesehen.
Mein Ziel ist es die 0.14 über einen Raspberry PI (ohne USB-UART-Adapter) auf die Sensoren zu bekommen.
Da habe ich das sicherlich vorhandene Kochrezept noch nicht lokalisiert.
Gruß
Boris
Hallo Boris,
so wie ich das verstanden habe, geht das auch nicht. Ob Du den Sensor mit PC oder Raspberry Pi programmierst, der serielle Bootloader bleibt derselbe ...
Gruß PeMue
Zitat von: PeMue am 29 März 2015, 13:33:32
Ich habe aber bei meiner Konfiguration noch eine Frage:
Wenn ich mit rereadcfg die fhem Konfiguration neu einlese, muss ich meine beiden Sensoren neu pairen. Meine Homematic Sensoren/Aktoren im Bad "überleben", d.h. sie bleiben gepairt.
Was mache ich falsch?
Gelöst: Einfach länger warten und autocreate seine Dinge anlegen lassen. Aber das ist halt so mit den Leuten, die die fhem.cfg noch mit der Hand bearbeiten ...
Vielleicht fange ich ja mal mit dem OTA Bootloader an.
Schöne Ostern.
Gruß PeMue
ich habe ja meinen Aussensensor auch schon einmal mit einer neuen Firmware der 0.12 seiner Zeit geflasht.
Das hatte ich unter Windows gemacht und habe den USB Stick an den Windows PC gesteckt, dass ist noch das was ich weiß.... den Rest habe ich auch schon wieder vergessen und wie das ging und wo die aktuelle Firmware liegt weiß ich auch nicht mehr.... und wenn man als Beispiel mal "HM-WDS10-TH-O" im Wiki eingibt kommt auch nichts was darauf hinweist, dass hier irgend etwas über die Sensoren steht.
Alles in allem was will ich damit sagen, vielleicht sollte man mal einen angepinnten Beitrag fertig stellen, mit allen Vorgehensweisen wie ich eine aktuelle Firmware auf die Sensoren bekomme, in erster Instanz mal die mit dem USB Stick, denn diese wird sicher die am meisten verbreitete Art und Weise sein/werden.
Hi,
die wiki-Seite zum Sensor ist hier:
http://www.fhemwiki.de/wiki/Universalsensor
Ich habe es gestern endlich hinbekommen, die Sensoren zu peeren.
Zur Analyse empfiehlt sich das hmInfo-Modul (http://hminfo-modul%20http://www.fhemwiki.de/wiki/HomeMatic_HMInfo).
Es geht so:
- Sensor und Regler mit fhem pairen.
- den Sensor muss man momentan (FW 0.14) evtl. mehrmals (2-3x) pairen, bis alle dargestellten Fehler bei set hmInfo configCheck beseitigt sind.
- set (sensor) peerChan 0 (Regler_Weather) single peert den Sensor mit dem Weather-Kanal des Reglers.
- am Sensor wieder mehrmals (2-3x) den config-Knopf drücken.
- am Regler muss man keinen Anlernmodus ausführen. Wenn man das macht, wird er sofort beendet und keine Statusnachricht angezeigt. Etwas verwirrend.
- wenn noch Register-Fehler im set hmInfo configCheck angezeigt werden, hilft ein set (Regler) getConfig und ggf. eine Beschleunigung der Übertragung der Daten für Ungeduldige mit set (Regler) burstXmit
- Als Check, ob alles geklappt hat, müssen in set hmInfo peerXref beide Richtungen dargestellt sein: Sensor => Regler und Regler => Sensor
- weiterer Check: im Regler_Weather und Sensor muss das Attribut peerIDs 00000000,21FF3401 angezeigt sein (die zweite ist die ID des jeweils anderen Gerätes)
- weiterer Check: die Sensor-LED blinkt jetzt 3x bei der Übertragung
- weiterer Check: die measured-temp des Reglers muss jetzt der des Sensors entsprechen.
Und genau da musste ich leider feststellen, dass die Übertragung der Temperatur bei mir nicht zuverlässig funktioniert.
Der Regler wechselt immer zwischen seiner eigenen und der des Sensors hin und her.
Ich habe als Test die Sensoren in den Kühlschrank gelegt. Die Entfernung zum Sensor und HMLAN ist ca. 3m.
Daher vermute ich eher keinen "Hardware-Übertragungsfehler" durch schlechten Empfang.
Hat jemand ähnliche Erfahrungen gemacht?
Anbei ist eine Aufzeichnung, aus der man erkennt, wie die Temperatur (rot) hin und wieder die des Reglers annimmt. Wenn dann wieder die Sensor-Temperatur des Kühlschranks angezogen wird, greift die Fenstererkennung und stellt die Soll-Temp (blau) auf 12°C. Der Aktuator (grün) fährt fleißig hin- und her.
Dann noch ein Bug (oder Feature) im Regler: Sensoren wieder aus dem Kühlschrank genommen, Fenstersymbol erlischt, Soll-Temperatur bleibt bei 12°C...
Viele Grüße
Spiff
Zitat von: Spiff am 04 April 2015, 14:13:14
die wiki-Seite zum Sensor ist hier:
http://www.fhemwiki.de/wiki/Universalsensor
wenn du mich meinst...!
Ja ich weiß das (habe es als Link abgespeichert) ;), aber ich wollte nur darauf hinweisen, das wenn hier jemand sucht, er meistens nicht nach Universalsensor sucht... denke ich..!! ;)
Zitat von: Spiff am 04 April 2015, 14:13:14
Hat jemand ähnliche Erfahrungen gemacht?
Ja: http://forum.fhem.de/index.php/topic,34948.0.html
Gruß
G.
Hallo Zusammen,
Zitat von: mmatt am 31 März 2015, 19:23:56
Zuerst ein Versuch ohne Bootloader per ISP-Programmer über die Arduino IDE, dabei wird der Bootloader beim programmieren entfernt. (Soweit ich das weiss)
Das ist korrekt.
ZitatDanach ein Versuch mit dem Standart Arduino Bootloader.
Der Standart Bootloader wird keine Seriennummer usw. zurück liefern. Da musstest du eine Spezielle Firmware compilieren und flashen die diese Daten schon enthält.
Zitat von: Mr. P am 02 April 2015, 23:37:23
Ich glaube, die Frage müsste eher lauten, ob das jemand überhaupt schon einmal gemacht hat. :-)
Das hatte ich auch noch nicht getestet da ich an diese Möglichkeit noch gar nicht gedacht hatte.
Daher funktioniert das aktuell offensichtlich nicht.
Zitat von: PeMue am 03 April 2015, 14:48:15
Hallo Holgi,
Oder Du baust um auf OTA bootloader ;). Was das bedeutet, ist in betateilchens Anstrengungen auf mehreren Seiten (ab S. 108 ff) nachzulesen.
Ich denke das war eher die Ausnahme das das bei Betateilchen so kompliziert war. :)
Zitat von: PumpkinEater am 03 April 2015, 20:12:50
ich hatte das Problem mit der fehlenden Luftdruckanzeige ja gemeldet. Teilweise kann ich jedoch Entwarnung geben: Der Luftdruck wird auch mit der neuesten CCU2-Firmware 2.13.7 korrekt angezeigt. Da ich das Sensor-Addon nicht auf die CCU2 aufspielen konnte, hatte ich dies manuell gemacht: Auf dem Windows-PC das AddOn-File entpackt und die Files /firmware/rftypes/* per scp auf die CCU2 kopiert. Danach wurde der Luftdruck nicht angezeigt. Ich habe das Ganze jetzt noch mal wiederholt, aber das Addon-tar.gz-File direkt auf der CCU2 entpackt und dann die Files in die richtigen Ordner kopiert. Nun wird auch der Luftdruck richtig angezeigt. Ich vermute, dass beim Entpacken auf dem Windowsrechner ein dos/unix-Formatproblem aufgetreten ist (CRLF), und das xml-File dann von der CCU2 nicht mehr richtig gelesen wurde.
Es bleibt also nur noch das Problem, dass die CCU2 das Addon nicht installieren will (mittels "Zusatzsoftware installieren").
Ah, Danke für den Hinweis.
Ich schaue mir das Addon noch mal an, warum sich das im Moment nicht installieren lässt.
Zitat von: Bkel am 04 April 2015, 00:59:42
Mein Ziel ist es die 0.14 über einen Raspberry PI (ohne USB-UART-Adapter) auf die Sensoren zu bekommen.
Theoretisch sollte das auch funktionieren. Das hier könnte da eine Anlaufstelle sein:
http://www.deanmao.com/2012/08/10/uploading-sketches-to-the-arduino-on-the-pi/
Zitat von: Spiff am 04 April 2015, 14:13:14
Und genau da musste ich leider feststellen, dass die Übertragung der Temperatur bei mir nicht zuverlässig funktioniert.
Der Regler wechselt immer zwischen seiner eigenen und der des Sensors hin und her.
....
Hat jemand ähnliche Erfahrungen gemacht?
Ja, das ist noch ein bekanntes Problem.
Allerdings kann ich das bei mir aktuell noch nicht nachvollziehen.
Daher währ es schön, wenn du da als Tester mit zur Verfügung stehen kannst
Viele Grüße
Dirk
Zitat von: Dirk am 04 April 2015, 14:52:00
Ja, das ist noch ein bekanntes Problem.
Allerdings kann ich das bei mir aktuell noch nicht nachvollziehen.
Daher währ es schön, wenn du da als Tester mit zur Verfügung stehen kannst
Ich glaube, da stehen dir auch ein paar Leute mehr zur Verfügung. ;-)
Zitat von: Mr. P am 04 April 2015, 14:56:54
Ich glaube, da stehen dir auch ein paar Leute mehr zur Verfügung. ;-)
Na sicher. Am besten, Dirk läßt uns mal wissen, was er genau braucht, und wir testen. Ich hatte das Peering nach einigen Versuchen wieder aufgehoben, da es nicht ging.
Gruß
G.
ZitatAm besten, Dirk läßt uns mal wissen, was er genau braucht, und wir testen. Ich hatte das Peering nach einigen Versuchen wieder aufgehoben, da es nicht ging.
Am Besten währ folgendes:
Die Aktuelle Version der FW (0.15) auf einem Sensor zum Testen installieren. Hier sehen die Debugausgeben wieder besser aus.
Aktuelle muss man die selber kompilieren. Kann ich aber auch zur Verfügung stellen. Und dann die Debugausgaben vom Sensor über den UART eine längere Zeit am besten parallel zu FHEM aufzeichnen.
Da hoffe ich was ableiten zu können.
Viele Grüße
Dirk
Ich habe die v0.15er firmware-files in die git Masterbranch mit eingecheckt.
Damit sehen die Debugausgaben wieder besser aus.
Jetzt warte ich auf Logs von gepeerten Thermostaten :)
Viele Grüße
Dirk
Zitat von: Dirk am 04 April 2015, 16:06:10
Und dann die Debugausgaben vom Sensor über den UART eine längere Zeit am besten parallel zu FHEM aufzeichnen.
Da hoffe ich was ableiten zu können.
Ok, muss mir leider erst am Dienstag Kabel besorgen... aber das schaffen wir auch noch. :-)
Zitat von: Dirk am 04 April 2015, 16:06:10
Am Besten währ folgendes:
Und dann die Debugausgaben vom Sensor über den UART eine längere Zeit am besten parallel zu FHEM aufzeichnen.
Dazu habe ich noch eine Frage. Was genau meinst Du damit? Offenbar nicht das Mitschneiden in FHEM?
Gruß
G.
Das Mitschneiden der Logs in FHEM von Sensor und Thermostat ist der eine Teil.
Das Andere ist das Mitschneiden der Debugausgaben des Sensors an dessen serieller Schnittstelle.
Die Einstellungen vom UART hier sind übrigens 57600 Baud, 8 Bit, Parity None.
Sensor -> UART (RPI oder UART-USB-Adapter)
Sensor -> RPI/Adapter
TX -> RX
GND -> GND
Beim Sensor ist dazu die untere Pinleiste zu verwenden (über dem Batteriehalter) und gezählt von Links
1: TX
4: GND
Der Pegel wird vom Sensor vorgegeben (3,3 V)
In dieser Richtung kann der Sensor so daher auch an einen UART angeschlossen werden der mit 5 V arbeitet.
Viele Grüße
Dirk
Zitat von: Dirk am 04 April 2015, 20:04:28
Das Andere ist das Mitschneiden der Debugausgaben des Sensors an dessen serieller Schnittstelle.
Das hatte ich befürchtet. So etwas übersteigt meine aktuellen Möglichkeiten. Gibt es dazu irgendwo eine Anleitung? Man müßte z.B. noch einen Raspi anschließen (Pegel?) und mit einem Terminalprogramm mitschneiden, nehme ich an. Einen USB-UART Konverter habe ich leider nicht.
Gruß
G.
Ich habe es unten im Post mal aktualisiert.
Es reichen 2 Leitungen
Sensor -> UART (RPI oder UART-USB-Adapter)
ZitatMan müßte z.B. noch einen Raspi anschließen (Pegel?) und mit einem Terminalprogramm mitschneiden, nehme ich an.
Ja, genau. Das würde gehen
Viele Grüße
Dirk
O.k., das könnte ich mal probieren. Der Sensor wirft kontinuierlich Daten auf der Schnittstelle aus oder muß man das irgendwo setzen?
Ergänzung:
Habe gerade in der Bastelkiste einen Prolific USB-serial-Konverter (7ST-DH-005) gefunden. Der müßte doch dafür gehen, oder?
Gruß
G.
Nein, das Debug ist bei v0.14 und v0.15 aktuell immer an. Bei 0.15 halt in besser lesbarer Form. Daher bitte diese Version zum debuggen nehmen.
Bei jedem Senden/Empfangen und jeder Aktivität also auch Configtaste-Drücken gibt es ein entsprechende Debug-Ausgabe. Auch beim "Einschalten".
Wenn burstRx gesetzt ist, dann bleibt der Sensor aktuell übrigens dauerhaft an. Was sich dementsprechend auf den Batterieverbrauch auswirkt.
Allerdings sieht dann im Debug den Kompletten Funkverkehr aller HM-Geräte in der Nähe.
Daher bei den Tests burstRx am besten aus lassen. Ansonsten wird das zu viel.
Achso:
Den FHEM-Log für dieses Experiment bitte auf Millisekunden-Ausgabe stellen (attr global mseclog 1)
Und zum Synchronisieren von FHEM-Log und dem Sensor-Debug einmal am Start der Reihe die Config-Taste vom Sensor drücken.
Die Sensor-Debug-Ausgaben habe nämlich nur die Millisekunden nach dem letzten Einschalten als Timestamp.
So, die Firmware 0.15 wäre mal erfolgreich drauf.
Bei den beiden gepeerten Devices muß dann verbose 5 gesetzt werden?
Gibt es evtl. eine Einstellung, alles in eine separates fhem-Logfile zu schreiben, anstelle in das Hauptlog?
Angehängt mal das Log einer normalen, zyklischen Datenübertragung. Ist das so richtig?
Gruß
G.
Hallo,
wie bekomme ich denn nun die aktuelle Firmware auf meine Sensoren ? Die Version 0.12 habe ich schon drauf, mit der sollte es ja ohne weiteres gehen, aber wie bekomme ich die 0.15 auf die Sensoren ?
Habe einen UART Adapter und auf beiden Sensoren (Außen und Innen-Sensor) den seriellen Bootloader.
Da ich nur einen HMLAN Adapter habe, mit dem kein OTA update funktioniert, hatte ich die Sensoren bei Dirk mit seriellem bootloader und einem UART Adapter bestellt.
Gruß Holgi
Schau mal hier:
http://forum.fhem.de/index.php/topic,20620.msg269542.html#msg269542
Und dann hier mit berichtigen Aufruf des avrdude und in der Antwort von Dirk findest Du den link auf das korrekte 0.14 Hexfile.
Passt antürlich nicht, wenn Du die 0.15er haben möchtest.
http://forum.fhem.de/index.php/topic,20620.msg269637.html#msg269637
Wie die Sensoren angeschlossen werden, wird ja hier beschrieben.
http://forum.fhem.de/index.php/topic,20620.msg281490.html#msg281490
Das sollte es dann gewesen sein :)
Hallo maxritti,
ich dachte, bei dem serielle Bootloader muss noch die HMID und die Seriennummer in das HEX-File eingebaut werden, da nur im OTA Bootloader HMID und Seriennummer hinterlegt sind.
Oder habe ich da etwas falsch verstanden?
Danke + Gruß
Peter
Also ich habe da mal nichts weiter dran gedreht an dem File und alles klappt soweit.
Mehr kann ich dazu nicht sagen.
Hallo maxritti,
bitte poste doch mal Deine HMID und die Seriennummer Deines Sensors.
Danke + Gruß
PeMue
Zitat von: PeMue am 05 April 2015, 11:11:33
ich dachte, bei dem serielle Bootloader muss noch die HMID und die Seriennummer in das HEX-File eingebaut werden, da nur im OTA Bootloader HMID und Seriennummer hinterlegt sind.
Oder habe ich da etwas falsch verstanden?
Jain.
Hi Peter,
In den ersten Sensoren die es gab, war quasi ein Standart-Arduino Bootloader installiert.
Hier muss man das Hexfile mit mit angepassten HMID und Seriennummer flashen.
Von diesen gab es aber nur relativ wenige.
Die Sensoren mit "aktuellem" Seriellen Bootloader halten Seriennummer, HMID und Typ im Bootloader. Daher kann man das Hexfile hier ohne weitere Anpassung flashen.
Gruß
Dirk
Hallo Dirk,
dann verstehe ich aber betateilchens Aufregung nicht ganz. Er hätte dann ganz normal mit AVRDUDE die Firmware hochladen können und das war es dann.
Nochmal für mich (ich bin manchmal etwas langsam ;)):
- mit dem Windows Flash Tool aus v0.12 (muss ich mir mal anschauen, was das so macht) wird die HMID und die Seriennummer in den Bootloader Bereich geschrieben (ich dachte immer, hier wird im BIN-File der Firmware nach der Standard HMID bzw. -seriennummer gesucht und diese (in der Firmware selbe) ersetzt)
- wenn man das einmal gemacht hat, ist die Sache für alle Zeiten erledigt
- ab dann kann ich die Firmware ganz ohne Aufwand mit avrdude flashen (das Skript zu schreiben bekomme selbst ich hin, das kann ich von maxritti abschreiben und für Windows anpassen) 8)
Soweit korrekt verstanden?
Falls nicht, könntest Du einen Link auf den angepassten seriellen Bootloader posten? Der muss vermutlich mit HMID und Seriennummer kompiliert werden, oder?
Danke + Gruß
Peter
Zitat von: PeMue am 05 April 2015, 11:33:35
dann verstehe ich aber betateilchens Aufregung nicht ganz. Er hätte dann ganz normal mit AVRDUDE die Firmware hochladen können und das war es dann.
Nein, er hatte noch den alten seriellen Bootloader drauf.
Zitat
ich dachte immer, hier wird im BIN-File der Firmware nach der Standard HMID bzw. -seriennummer gesucht und diese (in der Firmware selbe) ersetzt
So ist das auch. Das ist notwendig wenn man das Hexfile mit dem alten Bootloader benutzen möchte.
Das ist übrigens ein spezielles Hexfile was ich noch für den alten Bootloader Kompiliere.
ZitatFalls nicht, könntest Du einen Link auf den angepassten seriellen Bootloader posten? Der muss vermutlich mit HMID und Seriennummer kompiliert werden, oder?
Ich habe da gar kein seperaten Bootloader gebaut. Daher ist das der selbe Bootloader wie hier:
https://github.com/kc-GitHub/Wettersensor/tree/v0.12/Tools/Bootloader
Hier muss man lediglich vor dem Flashen im Binfile die letzten 15 Bytes durch Type (2 Bytes), Seriennummer (10 Bytes) und HMID (3 Bytes) ersetzen.
Dazu muss das Hexfile in ein Binfile konvertiert werden (Hex2bin).
Dann kann man das ersetzen am einfachsten per Hexeditor vornehmen.
Dann das Binfile mit avrdude in den Sensor flashen.
Anbei mal ein Hexfile von dem Bootloader wo auch schon eine ältere Firmware mit drin steckt.
Das kann man mit dem flashtool von hier in den Sensor flashen:
https://github.com/kc-GitHub/Asksin_OTA_Bootloader/tree/master/Tools/Flash-Tool-Windows
Edit: Reihenfolge von Type, HMID und Seriennummer korrigiert
Zitat von: Dirk am 05 April 2015, 11:55:18
So ist das auch. Das ist notwendig wenn man das Hexfile mit dem alten Bootloader benutzen möchte.
Hallo Dirk,
ok, muss ich mir mal anschauen, aber ich meine ich habe die Grundzüge verstanden.
Kann ich irgendwie feststellen, welchen Bootloader ich draufhabe? Sensor an Terminal hängen, Taste beim Starten drücken und schauen, was kommt?
Danke + Gruß
PeMue
Zitat von: PeMue am 05 April 2015, 14:15:21
Kann ich irgendwie feststellen, welchen Bootloader ich draufhabe? Sensor an Terminal hängen, Taste beim Starten drücken und schauen, was kommt?
Da die Bootloader ansich gleich sind, eher nicht.
Du könntest den kompletten Flash vom AVR mit einem ISP auslesen.
Wenn die letzten 15 Bytes leer sind, dann hast du den "alten" Bootloader.
Ansonsten sollte da Type, Seriennummer und HMID stehen
Gruß
Dirk
Hi,
ich kann meine Aufzeichnungen auch leider erst nach Ostern starten. Geht das denn mit einem einfachen USB-Serial-Adapter und direkter Verkabelung?
Einen Hinweis wollte ich noch geben: ich hatte die Sensoren auch einmal in den Eisschrank gelegt. Dort wurde der eigentliche Wert um -7°C mit +95°C an den Regler übertragen. Es ist vielleicht aber auch einfach im Regler nicht vorgesehen, dass es in der Wohnung so kalt sein könnte... :)
Gruß
Spiff
Zitat von: Dirk am 05 April 2015, 14:18:57
Du könntest den kompletten Flash vom AVR mit einem ISP auslesen.
Wenn die letzten 15 Bytes leer sind, dann hast du den "alten" Bootloader.
Ansonsten sollte da Type, Seriennummer und HMID stehen
Ok, ich bin weitergekommen:
* Auslesen geht auch mit dem bestehenden Bootloader und USB-seriell Wandler mit
bin\avrdude.exe -Cbin\avrdude.conf -patmega328p -carduino -P COM5 -b57600 -D -Uflash:r:flash.hex:i(Basis ist der Flash-Tool-Windows aus der v0.12)
* ich habe wohl einen neuen Bootloader aber mit dem Skript für den alten geflasht, da ich zwei Seriennummern finde
- die programmierte (http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=30560;image) mitten im Code und
- die von Dirk in den Bootloader programmierte (http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=30562;image), die auch auf dem Aufkleber steht
Da werde ich doch mal den ISPProgrammer anwerfen und den Bootloader modifizieren, dann kann ich die normale Firmware draufmachen ...
Für meinen Außensensor muss ich aufs Dach, der könnte noch den alten Bootloader draufhaben.
Gruß PeMue
Zitat von: maxritti am 05 April 2015, 09:22:37
Schau mal hier:
http://forum.fhem.de/index.php/topic,20620.msg269542.html#msg269542
Und dann hier mit berichtigen Aufruf des avrdude und in der Antwort von Dirk findest Du den link auf das korrekte 0.14 Hexfile.
Passt antürlich nicht, wenn Du die 0.15er haben möchtest.
http://forum.fhem.de/index.php/topic,20620.msg269637.html#msg269637
Wie die Sensoren angeschlossen werden, wird ja hier beschrieben.
http://forum.fhem.de/index.php/topic,20620.msg281490.html#msg281490
Das sollte es dann gewesen sein :)
Hm, danke für die Info aber gibt es keine Möglichkeit die Firmware über Windows zu flashen ?
Meine hier irgendwo gelesen zu haben das es mit der 0.12 Version auch über Windows ging.
Gruß Holgi
Zitat von: The-Holgi am 05 April 2015, 18:28:43
Hm, danke für die Info aber gibt es keine Möglichkeit die Firmware über Windows zu flashen ?
Meine hier irgendwo gelesen zu haben das es mit der 0.12 Version auch über Windows ging.
Gruß Holgi
Sollte mMn nach kein Problem sein.
Die Arduino Software gibt es ja auch für Windows. Da müsstest du halt nur die Pfade und den USB Port für Deine Umgebung anpassen.
Zitat von: Dirk am 05 April 2015, 11:55:18
Anbei mal ein Hexfile von dem Bootloader wo auch schon eine ältere Firmware mit drin steckt.
Hallo Dirk,
in dem Beispiel scheint der Type falsch zu sein (soll für Innensensor):
ist:
00007FF0 12 34 48 42 30 44 65 66 61 75 6C 74 AB CD EF | .4HB0Default«Íïsoll:
00007FF0 F0 F1 48 42 30 44 65 66 61 75 6C 74 AB CD EF | ñ.HB0Default«ÍïAber solangsam kapiere ich die Sache ...
Gruß PeMue
Edit:
Ich korrigiere mich:
Type ist mit 12 34 vorbelegt
Seriennummer ist mit HB0Default vorbelegt
HMID ist mit AB CD EF vorbelegt, den Rest macht das Flash-Skript :)
Hallo zusammen,
ich brauche die Hilfe von Euch Spezialisten. Ich wollte meinen USBASP (leider nur 5 V, da das Chinateil mit 3,3 V gar nicht geht) testen und habe folgendes getan (eigentlich dachte ich, ich lese nur aus):
C:\Temp\sensor>bin\avrdude -patmega328p -cusbasp -Pusb -B4.0 -D -Uflash:r:flash.hex:i
avrdude: set SCK frequency to 187500 Hz
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e950f
avrdude: current erase-rewrite cycle count is -315 (if being tracked)
avrdude: reading flash memory:
Reading | ################################################## | 100% 9.61s
avrdude: writing output file "flash.hex"
avrdude: safemode: lfuse changed! Was e2, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: hfuse changed! Was d0, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: efuse changed! Was 6, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK
avrdude done. Thank you.
C:\Temp\sensor>bin\avrdude -patmega328p -cusbasp -Pusb -B4.0 -D -Uflash:r:flash.hex:i
avrdude: set SCK frequency to 187500 Hz
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
mit dem Ergebnis, dass gar nichts mehr funktioniert (weder über seriell noch über USBASP). Ich vermute, dass ich auf die Fragen der Fuses mit y hätte antworten sollen. Vermutlich sucht der Prozessor jetzt seinen (externen) Takt, den er aber auf der Platine nicht hat.
Habt ihr irgendwelche Ideen:
- was ich falsch gemacht habe bzw.
- wie ich den Sensor wieder retten kann?
Laut Datenblatt sollten die Pins 5 V abkönnen, die Versorgungsspannung kam vom Sensor selber, am Sensor liegen auch 3,3 V an.
Vielen Dank mal im voraus.
Gruß PeMue
Hilft Dir zwar nicht weiter, aber zum Trost: Ich habe meinen Sensor auch beim Versuch den OTA Bootloader aufzuspielen mittels der Fuses ins Nirwana geschickt und mir fehlt das know how, einen externen Takt anzulegen, was wohl die Reanimationsmethode der Wahl ist.
Grüße
Boris
Hallo Boris,
siehe
http://www.heise.de/ct/hotline/Fuse-Bits-falsch-gesetzt-321580.html
Diese China-Programmer sind zwar billig, aber tun nicht wirklich. Obwohl der Schaltplan, etc. gleich sind >:( >:( >:(
Gruß PeMue
Hej, Leute!
Die selbe Leistung (den Sensor beim Flashen von OTA-Bootloader töten) habe ich bereits vor einigen Seiten hier im Thread gebracht >:(
Ich meine, die Frage nach der Wiederherstellung der Fuses hatte ich mit 'y' beantwortet, was jedoch auch nichts genutzt hat. Ich glaube, der µC ist bei der Fragestellung bereits tot. Somit Willkommen im Club! :(
Dirk hat mir damals folgenden Tip gegeben:
ZitatSo ein Problem hatte ich durch einen Wackler auch schon mal bekommen.
Dann könnte es sein das der AVR jetzt verfused ist.
Ich fürchte da hilft nur noch ein HV-Programmer.
Hast du einen Arduino und ein Bisschen "Hünerfutter" da? Dann kann man den damit wieder erwecken:
http://mightyohm.com/blog/2008/09/arduino-based-avr-high-voltage-programmer/
So einen hab ich mir auf dem Steckbrett für genau solche Fälle zusammengebaut.
Ich habe mich damit zuerst an einem Arduino 'vergangen'. Leider ohne Erfolg, dann habe ich mich an den eigentlichen Sensor nicht mehr getraut. Letzendlich hat Dirk das Device dankenswerterweise wiederbelebt.
Grüße,
Alexander
Sch...e! Auch ein (5 V) Oszillator an Pin 7 des Prozessors schafft es nicht, den USBASP Programmer zum Spielen zu bringen. Irgendwo habe ich auch mal was von einer "Programmierzange", gelesen:
Sprich: Zange um den (stromlosen) Mikrocontroller rum (inkl. der richtigen Peripherie) und dann programmieren. Dann werde ich mal hoffen, dass Dirk mitliest ...
Gruß PeMue
Es gibt mehrere Arten, einen Atmel zu 'verfusen'. Nicht nur die falsche Wahl der Taktquelle. :(
Zitat von: PeMue am 07 April 2015, 21:27:40
Sch...e! Auch ein (5 V) Oszillator an Pin 7 des Prozessors schafft es nicht, den USBASP Programmer zum Spielen zu bringen.
Bitte kein 5 V Pegel bei 3,3V Versorgungsspannung. Das mag der AVR nicht.
Ansonsten, der unten verlinkte HV-Programmer auf Arduino-Basis funktioniert bei mir bei diesen Fällen gut.
Alle zum Programmieren benötigten Pins liegen an den Pinreihen an.
Bis auf einer.Den kann man aber kurz mit einer Nadel kontaktieren.
Das Zurücksetzen des AVR mit dem Arduino-HV-Programmer dauert nur eine Sekunde.
Gruß
Dirk
Zitat von: Dirk am 07 April 2015, 21:57:19
Bitte kein 5 V Pegel bei 3,3V Versorgungsspannung. Das mag der AVR nicht.
Das war nur der Quarz, der ein 5 V Quarz an 3,3 V betrieben war. Aber ich muss noch mal meinen einen USBASP nachmessen, es kann sein, dass der 5 V Pegel hatte und der Atmega328 dann ganz hinüber ist.
Die Spannungsversorgung kam vom Sensor, aber wenn die Pegel des Programmers 5 V hatten ist das suboptimal >:(
Datenblatt: Vcc +0,5 V --> 3,3 V + 0,5 V = 3,8 V, da sind 5 V dann definitiv zu viel *grr*
Gruß PeMue
Zitat von: PeMue am 07 April 2015, 22:24:17
Aber ich muss noch mal meinen einen USBASP nachmessen, es kann sein, dass der 5 V Pegel hatte und der Atmega328 dann ganz hinüber ist.
Ich habe hier hinter meinem 5V USBASP ein paar Widerstände als Spannungsteiler in den Signalen die zum AVR gehen.
Das funktioniert gut.
Ansonsten repariere ich dir den Sensor auch wieder.
Gruß
Dirk
Hallo,
nach Reparieren des Kabels ging das Flashen des neuen seriellen Bootloaders auf meinen Außensensor (der übrigens einen Bootloader ohne Seriennummer hatte) ganz gut, siehe
Readings
Activity alive 2015-04-09 13:25:22
D-firmware 0.15 2015-04-09 12:15:22
D-serialNr USO6607220 2015-04-09 12:15:22
PairedTo 0xF10000 2015-04-09 13:47:58
R-altitude 0 m 2015-04-09 12:15:23
R-lowBatLimitTHPL 1.6 V 2015-04-09 12:15:23
R-pairCentral 0xF10000 2015-04-09 12:15:23
Der "zerschossene" Innensensor war leider durch mich nicht wiederbelebbar :-[
Gruß PeMue
mein Aussensensor spinnt seit heute irgendwie rum...
Also heute Vormittag ist er gegen 11:40 Uhr ausgestiegen... hier mal die letzten Zuckungen
2015-04-09_11:40:59 Aussensensor_Terrasse Activity: dead
2015-04-09_11:30:57 Aussensensor_Terrasse Activity: alive
2015-04-09_11:24:21 Aussensensor_Terrasse temperature: 20.7
2015-04-09_11:24:21 Aussensensor_Terrasse T: 20.7 L: 17.59 P: 1025.0 P-NN: 1052.6
2015-04-09_11:24:21 Aussensensor_Terrasse rssi_at_HMUSB: -65
2015-04-09_11:24:21 Aussensensor_Terrasse pressure: 1025.0
2015-04-09_11:24:21 Aussensensor_Terrasse pressure-nn: 1052.6
2015-04-09_11:24:21 Aussensensor_Terrasse luminosity: 17.59
2015-04-09_11:24:21 Aussensensor_Terrasse battery: ok
2015-04-09_11:24:21 Aussensensor_Terrasse batVoltage: 3.01
2015-04-09_11:22:39 Aussensensor_Terrasse temperature: 14.8
2015-04-09_11:22:39 Aussensensor_Terrasse T: 14.8 L: 0.48 P: 1026.1 P-NN: 1053.7
2015-04-09_11:22:39 Aussensensor_Terrasse rssi_at_HMUSB: -58
2015-04-09_11:22:39 Aussensensor_Terrasse pressure: 1026.1
2015-04-09_11:22:39 Aussensensor_Terrasse pressure-nn: 1053.7
2015-04-09_11:22:39 Aussensensor_Terrasse luminosity: 0.48
2015-04-09_11:22:39 Aussensensor_Terrasse battery: ok
dann habe ich die Batterien wechselt und der Melder lief wieder bis 13:23 Uhr und wieder Schicht im Schacht... ausgestiegen:
2015-04-09_13:23:41 Aussensensor_Terrasse Activity: dead
2015-04-09_13:03:44 Aussensensor_Terrasse temperature: 21.2
2015-04-09_13:03:44 Aussensensor_Terrasse T: 21.2 L: 2780 P: 1023.9 P-NN: 1051.5
2015-04-09_13:03:44 Aussensensor_Terrasse rssi_at_HMUSB: -68
2015-04-09_13:03:44 Aussensensor_Terrasse pressure: 1023.9
2015-04-09_13:03:44 Aussensensor_Terrasse pressure-nn: 1051.5
2015-04-09_13:03:44 Aussensensor_Terrasse luminosity: 2780
2015-04-09_13:03:44 Aussensensor_Terrasse battery: ok
2015-04-09_13:03:44 Aussensensor_Terrasse batVoltage: 3.01
2015-04-09_13:03:42 Aussensensor_Terrasse rssi_at_HMUSB: -66
2015-04-09_13:03:42 Aussensensor_Terrasse rssi_at_HMUSB: -66
2015-04-09_13:03:42 Aussensensor_Terrasse rssi_at_HMUSB: -67
2015-04-09_13:03:41 Aussensensor_Terrasse rssi_at_HMUSB: -67
2015-04-09_13:03:41 Aussensensor_Terrasse R-pairCentral: 0x1EA121
2015-04-09_13:03:41 Aussensensor_Terrasse R-burstRx: off
2015-04-09_13:03:41 Aussensensor_Terrasse rssi_at_HMUSB: -71
2015-04-09_13:03:41 Aussensensor_Terrasse D-serialNr: UWS0931763
2015-04-09_13:03:41 Aussensensor_Terrasse D-firmware: 0.12
2015-04-09_13:03:41 Aussensensor_Terrasse Activity: alive
2015-04-09_12:49:29 Aussensensor_Terrasse Activity: unknown
nochmals Batterien gewechselt, Melder lief wieder und das selbe Spielchen... was ist da passiert..?
letzte Log bis zum Ausstieg:
2015-04-09_16:43:28 Aussensensor_Terrasse Activity: dead
2015-04-09_16:25:21 Aussensensor_Terrasse temperature: 24.4
2015-04-09_16:25:21 Aussensensor_Terrasse T: 24.4 L: 358 P: 1022.5 P-NN: 1050.1
2015-04-09_16:25:21 Aussensensor_Terrasse rssi_at_HMUSB: -59
2015-04-09_16:25:21 Aussensensor_Terrasse pressure: 1022.5
2015-04-09_16:25:21 Aussensensor_Terrasse pressure-nn: 1050.1
2015-04-09_16:25:21 Aussensensor_Terrasse luminosity: 358
2015-04-09_16:25:21 Aussensensor_Terrasse battery: ok
2015-04-09_16:25:21 Aussensensor_Terrasse batVoltage: 3.08
2015-04-09_16:22:11 Aussensensor_Terrasse temperature: 24.3
2015-04-09_16:22:11 Aussensensor_Terrasse T: 24.3 L: 401 P: 1022.6 P-NN: 1050.2
2015-04-09_16:22:11 Aussensensor_Terrasse rssi_at_HMUSB: -66
2015-04-09_16:22:11 Aussensensor_Terrasse pressure: 1022.6
2015-04-09_16:22:11 Aussensensor_Terrasse pressure-nn: 1050.2
2015-04-09_16:22:11 Aussensensor_Terrasse luminosity: 401
2015-04-09_16:22:11 Aussensensor_Terrasse battery: ok
2015-04-09_16:22:11 Aussensensor_Terrasse batVoltage: 3.08
2015-04-09_16:18:46 Aussensensor_Terrasse temperature: 24.3
2015-04-09_16:18:46 Aussensensor_Terrasse T: 24.3 L: 152 P: 1022.6 P-NN: 1050.2
2015-04-09_16:18:46 Aussensensor_Terrasse rssi_at_HMUSB: -61
2015-04-09_16:18:46 Aussensensor_Terrasse pressure: 1022.6
2015-04-09_16:18:46 Aussensensor_Terrasse pressure-nn: 1050.2
2015-04-09_16:18:46 Aussensensor_Terrasse luminosity: 152
2015-04-09_16:18:46 Aussensensor_Terrasse battery: ok
2015-04-09_16:18:46 Aussensensor_Terrasse batVoltage: 3.08
2015-04-09_16:16:16 Aussensensor_Terrasse temperature: 24.3
2015-04-09_16:16:16 Aussensensor_Terrasse T: 24.3 L: 202 P: 1022.7 P-NN: 1050.3
2015-04-09_16:16:16 Aussensensor_Terrasse rssi_at_HMUSB: -70
2015-04-09_16:16:16 Aussensensor_Terrasse pressure: 1022.7
2015-04-09_16:16:16 Aussensensor_Terrasse pressure-nn: 1050.3
2015-04-09_16:16:16 Aussensensor_Terrasse luminosity: 202
2015-04-09_16:16:16 Aussensensor_Terrasse battery: ok
2015-04-09_16:16:16 Aussensensor_Terrasse batVoltage: 3.05
2015-04-09_16:13:28 Aussensensor_Terrasse rssi_at_HMUSB: -52
2015-04-09_16:13:28 Aussensensor_Terrasse D-serialNr: UWS0931763
2015-04-09_16:13:28 Aussensensor_Terrasse D-firmware: 0.12
2015-04-09_16:13:28 Aussensensor_Terrasse Activity: alive
2015-04-09_16:13:06 Aussensensor_Terrasse rssi_at_HMUSB: -56
2015-04-09_16:13:06 Aussensensor_Terrasse D-serialNr: UWS0931763
2015-04-09_16:13:06 Aussensensor_Terrasse D-firmware: 0.12
2015-04-09_16:13:06 Aussensensor_Terrasse Activity: alive
2015-04-09_16:13:02 Aussensensor_Terrasse temperature: 23.7
2015-04-09_16:13:02 Aussensensor_Terrasse T: 23.7 L: 20.86 P: 1022.7 P-NN: 1050.3
2015-04-09_16:13:02 Aussensensor_Terrasse rssi_at_HMUSB: -58
2015-04-09_16:13:02 Aussensensor_Terrasse pressure: 1022.7
2015-04-09_16:13:02 Aussensensor_Terrasse pressure-nn: 1050.3
2015-04-09_16:13:02 Aussensensor_Terrasse luminosity: 20.86
2015-04-09_16:13:02 Aussensensor_Terrasse battery: ok
2015-04-09_16:13:02 Aussensensor_Terrasse batVoltage: 3.07
Nu isser erst mal draussen... und ist platt morgen früh mal schauen ob er sich wieder meldet...
Dieser macht leider ewig Probleme, was kann das jetzt sein..?
Hier mal ein list:
Internals:
CFGFN ./FHEM/Temperaturen.cfg
DEF D879E9
HMUSB_MSGCNT 13
HMUSB_RAWMSG ED879E9,0000,40DD02EC,FF,FFC5,06A270D879E91EA12100F40027F100008BAF0C0D
HMUSB_RSSI -59
HMUSB_TIME 2015-04-09 16:25:21
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 13
NAME Aussensensor_Terrasse
NR 1401
STATE T: 24.4 L: 358 P: 1022.5 P-NN: 1050.1
TYPE CUL_HM
lastMsg No:06 - t:70 s:D879E9 d:1EA121 00F40027F100008BAF0C0D
protLastRcv 2015-04-09 16:25:21
protSnd 13 last_at:2015-04-09 16:25:21
protState CMDs_done
rssi_at_HMUSB avg:-63.61 min:-71 max:-52 lst:-59 cnt:13
Readings:
2015-04-09 16:43:28 Activity dead
2015-04-09 16:13:28 D-firmware 0.12
2015-04-09 16:13:28 D-serialNr UWS0931763
2015-04-09 13:03:41 PairedTo 0x1EA121
2015-04-09 13:03:41 R-burstRx off
2015-04-09 13:03:41 R-pairCentral 0x1EA121
2015-04-09 13:03:41 RegL_00: 01:00 02:01 0A:1E 0B:A1 0C:21 00:00
2015-04-09 16:25:21 batVoltage 3.08
2015-04-09 16:25:21 battery ok
2015-04-09 16:25:21 luminosity 358
2015-04-09 16:25:21 pressure 1022.5
2015-04-09 16:25:21 pressure-nn 1050.1
2015-04-09 16:25:21 rssi_at_HMUSB -59
2015-04-09 16:25:21 state T: 24.4 L: 358 P: 1022.5 P-NN: 1050.1
2015-04-09 16:25:21 temperature 24.4
Helper:
cSnd 011EA121D879E90103
mId F102
peerIDsRaw ,00000000
rxType 132
Io:
newChn +D879E9,00,01,00
nextSend 1428589521.52095
prefIO
rxt 0
vccu
p:
D879E9
00
01
00
Mrssi:
mNo 06
Io:
HMUSB -57
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMUSB
flg A
ts 1428589521.42456
ack:
HASH(0xe78e58)
0680021EA121D879E900
Rssi:
At_hmusb:
avg -63.6153846153846
cnt 13
lst -59
max -52
min -71
Shadowreg:
Attributes:
IODev HMUSB
actCycle 000:10
actStatus dead
alias Terrasse Süden
autoReadReg 4_reqStatus
expert 2_full
firmware 0.12
group Temperatur Aussen
model HB-UW-Sen-THPL-O
peerIDs 00000000,
room AußenLicht,Temperaturen
rssiLog 1
serialNr UWS0931763
sortby 11
subType THPLSensor
Hallo Dirk,
ist die 0.14 immer noch Beta, oder habe sich dort noch Änderungen ergeben ?
Gruß Christoph
bei mir geht das Spielchen weiter, heute morgen kurz etwas gemacht und nun wieder verabschiedet.
Dirk schreib mir mal bitte was ich machen soll/kann..
2015-04-10_13:35:43 Aussensensor_Terrasse Activity: dead
2015-04-10_13:15:43 Aussensensor_Terrasse Activity: unknown
2015-04-10_11:11:42 Aussensensor_Terrasse Activity: dead
2015-04-10_11:01:42 Aussensensor_Terrasse Activity: alive
2015-04-10_11:00:04 Aussensensor_Terrasse temperature: 17.1
2015-04-10_11:00:04 Aussensensor_Terrasse T: 17.1 L: 300 P: 1018.1 P-NN: 1045.7
2015-04-10_11:00:04 Aussensensor_Terrasse rssi_at_HMUSB: -74
2015-04-10_11:00:04 Aussensensor_Terrasse pressure: 1018.1
2015-04-10_11:00:04 Aussensensor_Terrasse pressure-nn: 1045.7
2015-04-10_11:00:04 Aussensensor_Terrasse luminosity: 300
2015-04-10_11:00:04 Aussensensor_Terrasse battery: ok
2015-04-10_11:00:04 Aussensensor_Terrasse batVoltage: 3.01
Machen das bei die alle Sensoren oder nur ein bestimmter.
Wenn das nur einer ist, kann man ggf. einen Deffekt nicht ausschließen.
Gruß
Dirk
Zitat von: Dirk am 10 April 2015, 15:03:43
Machen das bei die alle Sensoren oder nur ein bestimmter.
nein nur der Aussensensor, in schöner Regelmäßigkeit meldet er sich wieder und steigt wieder aus, dass geht munter weiter so am heutigen Tag
Hallo Dirk,
seit etlichen Wochen wird bei meinem Außensensor das Reading temperature nicht mehr aktualisiert, auch wird folgedessen der SVG-Plot nicht mehr geschrieben. Komischerweise wird das Reading temperature im Threshold als Istwert verwendet also auch als "sensor_value" in den dortigen Readings aktuell angezeigt und das Ganze funktioniert. Im Reading state des Fühlers werden alle aktuell gemessenen Werte also auch die Temperatur immer aktuell angezeigt. Somit macht für mich ein Hardwarefehler wie auch ein Softwarefehler keinen Sinn. Dieses komische Verhalten trat von einem Tag auf den anderen auf, zu dem Zeitpunkt war Frmwarestand 0.12 drauf, dann 0.14 und jetzt 0.15.
Offenbar schaffe ich es nicht das Bildschirmfoto als Datei anzuhängen, das hat bei mir aber schonmal funktioniert. Vielleicht habe ich mich trotzdem bildhaft genug ausgedrückt.
Volker
Hallo,
wo liegt den die Version 0.15 und was ist geändert worden ?
Gruß Christoph
Zitat von: Bennemannc am 16 April 2015, 17:31:47
Hallo,
wo liegt den die Version 0.15 und was ist geändert worden ?
Gruß Christoph
Hallo Christoph,
Firmware liegt hier
https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release
Changelog ist nur gepflegt bis v0.14
https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Src
Gruß PeMue
Zitat von: PeMue am 16 April 2015, 17:38:54
Changelog ist nur gepflegt bis v0.14
v0.15 ist auch nicht released und daher experimentell ;)
Zitat von: volker.m am 16 April 2015, 16:57:39
Hallo Dirk,
seit etlichen Wochen wird bei meinem Außensensor das Reading temperature nicht mehr aktualisiert, auch wird folgedessen der SVG-Plot nicht mehr geschrieben. Komischerweise wird das Reading temperature im Threshold als Istwert verwendet also auch als "sensor_value" in den dortigen Readings aktuell angezeigt und das Ganze funktioniert. Im Reading state des Fühlers werden alle aktuell gemessenen Werte also auch die Temperatur immer aktuell angezeigt. Somit macht für mich ein Hardwarefehler wie auch ein Softwarefehler keinen Sinn. Dieses komische Verhalten trat von einem Tag auf den anderen auf, zu dem Zeitpunkt war Frmwarestand 0.12 drauf, dann 0.14 und jetzt 0.15.
Offenbar schaffe ich es nicht das Bildschirmfoto als Datei anzuhängen, das hat bei mir aber schonmal funktioniert. Vielleicht habe ich mich trotzdem bildhaft genug ausgedrückt.
Volker
nach deinem bild ist doch alles aktuell. temperature wurde bei der vorletzten datenübertragung auf 25.6 gesetzt. im state reading das bei der letzten aktualisierung gesetzt wurde, steht ebenfalls 25.6. du hast sicherlich event-on-change gesetzt daher wurde temperature beim letzten senden nicht aktualisiert.
seltsam finde ich eher, dass bei dir diverse register(R-)readings fehlen. entweder hast du die ".pm"-datei nicht aktualisiert, oder nach dem update der fw kein getconfig gemacht.
Hallo Frank,
das Bildschirmfoto von gestern war etwas ungünstig, wenn ich die Seite vom Sensor aufrufe haben alle Readings (Messwerte) den gleichen Zeitstempel. Einen Übertragungszyklus später waren nur die Werte mit den roten Zeitstempeln aktualisiert. Das Reading temperature zeigte aus dem Grund die richtige Temperatur an weil halt nach den zwei Minuten am Fühler sich noch nichts geändert hat. Am heutigen Bildschirmfoto sieht man schon besser was ich meine. Die HMConfig_SenTHPL.pm ist vom 25.März.
Volker
da habe ich doch gleich mal ein Frage dazu, da ich auf den Readings "humidity" ist das in der Firmware Neu, denn dieses Reading habe ich gar nicht...
Diese Sensoren gab es ja damals und da hatte keiner Feuchte
Zitat21. 21,00 € Funk-Außensensor, Batterie ohne Sensoren, ohne MAX1724, Gehäuse grau
22. 28,50 € Funk-Außensensor, Batterie mit Helligkeit, MAX1724, Gehäuse grau
23. 26,00 € Funk-Außensensor, Batterie mit Temperatur / Luftdruck, MAX1724, Gehäuse grau
24. 30,00 € Funk-Außensensor, Batterie mit Temperatur / Luftdruck, MAX1724, Gehäuse grau
25. 33,50 € Funk-Außensensor, Batterie mit Temperatur / Luftdruck, Helligkeit, MAX1724, Gehäuse grau
ich habe den letzten mit allen eigentlich
@volker.m
poste mal ein list vom sensor.
@moonsorrox
ich habe in erinnerung, dass aussensensoren, wegen dem luftdichten gehäuse, keine luftfeuchte haben. ich habe ein innensensor komplett bestückt, der hat schon immer humidity.
Hallo,
bei dem list sind natürlich wieder die Zeitstempel und die Werte der Temperaturen gleich.
Ich habe mir für den SHT10 eine kleine Platine gemacht und aufgesteckt. Die Firmware des Sensors erkennt den automatisch und verwendet dann die Temperatur nicht vom Drucksensor sondern vom Feuchtesensor.
Volker
Zitat von: frank am 16 April 2015, 20:49:44
@moonsorrox
ich habe in erinnerung, dass aussensensoren, wegen dem luftdichten gehäuse, keine luftfeuchte haben.
ja, macht Sinn..!
da er aber oben auf den Bilder bei den Attributen "HB-UW-Sen-THPL-O" drin hat wundert es mich, es sei denn er hat einen Innensensor den er als Aussensensor bezeichnet...!
Hallo,
ich habe den Sensor als Außensensor bei Dirk bestellt und gekauft, er ist in einem Außensensorgehäuse untergebracht, er hatte von Anfang an die Firmware eines Außensensors drauf (also von Dirk programmiert) und er ist ein Außensensor. In Beiträgen dutzende Seiten weiter vorne wurde darüber geschrieben in die Außengehäuse Löcher zu bohren und mit sowas http://www.extremtextil.de/catalog/Nylon-PU-beschichtet-atmungsaktiv-100den-80g-qm::1764.html?XTCsid=9b6595d7929f33c82ea51d6a84fdc802 (http://www.extremtextil.de/catalog/Nylon-PU-beschichtet-atmungsaktiv-100den-80g-qm::1764.html?XTCsid=9b6595d7929f33c82ea51d6a84fdc802) oder ähnlichem von innen zu bekleben. Nur lassen sich diese Seiten immer schlecht wiederfinden. Es gibt sogar ein Foto zu einem solchen Gehäuse. Dirk hat diese Außenfühler (ich glaube es war bei mir letzten August) wirklich nur ohne den SHT10 angeboten mit dem Hinweis daß man ihn selbst nachrüsten kann, die Lötaugen dafür waren schon vorhanden.
Vielleicht fällt Euch aber zu meinem oben beschriebenen Problem noch etwas ein. Seit dem 19. März funktioniert die Temperatur nicht mehr. Vielleicht gab es an dem Tag oder kurz davor ein Update welches damit im Zusammenhang stehen kann.
Volker
ZitatVielleicht fällt Euch aber zu meinem oben beschriebenen Problem noch etwas ein. Seit dem 19. März funktioniert die Temperatur nicht mehr.
die temperatur funktioniert ja. es werden nur keine events generiert.
du solltest als erstes mal ein getconfig anstossen, da beim sensor device fast alle registerdaten fehlen. dazu musst du aber am sensor die configtaste drücken. eventuell mehrmals bis alle befehle abgearbeitet sind (cmds_done). und vor dem getconfig machst du noch ein set clear msgEvents, da noch alte befehle anstehen. besser noch ein set clear all, da du auch noch alte reading-leichen (T, H) mitschleppst.
dann würde ich das attribut event-min mal entfernen. macht, in dieser form auch keinen sinn, da sowieso alle 2,5 min neue events kommen (zumindestens wenn es funktioniert ;) ).
mit dblog kenne ich mich nicht aus. aber testweise würde ich auch mal den eintrag dblogexclude entfernen.
autoreadreg kannst du auch auf 0 setzen, da der sensor (noch) nicht automatisch antworten kann.
Hallo frank,
ich habe jetzt mal alle Deine Schritte abgearbeitet, hat noch nicht den gewünschten Erfolg gebracht. Als Anhang der aktuelle Stand. Bei den Internals deutet etwas auf einen Fehler hin.
Volker
Auf einen Fehler deutet eigentlich nichts hin.
Ich seh aber zwei Dinge, die mir nicht gefallen:
1) du hast deinen Sensor nicht mit der Zentrale gepairt und
2) es gibt noch Befehle, die nicht abgearbeitet wurden
Ich würde einmal die msgEvents clearen und dann den Sensor neu pairen.
Sollte das geklappt haben, mache das von frank bereits vorgeschlagene getConfig und schau dann nochmal, was so ausgespuckt wird.
PS: Nicht vergessen, dass für beide Aktionen der Knopf am Sensor gedrückt werden muss.
Ich verfolge den Thread schon länger.
Ich würde gerne einen Universalsensor an eine CCU2 als Außenlichtsensor betreiben.
An wen kann ich mich wenden wenn ich einen kaufen will ? Eine PM wäre auch ok.
Ich bin nicht sicher ob die Einträge im Thread noch aktuell sind.
Danke
Eine PM an Dirk wird dir da weiterhelfen.
Hältst Du uns auf dem Laufenden ? Finde ich nämlich auch sehr interessant.
Hallo Zusammen,
leider bin ich die letzten Tage leider kam dazu gekommen hier mal wieder vorbei zu schauen.
Leider sind da auch ein paar PM's liegen geblieben, die jetzt aber beantwortet sein sollten.
Falls ich jemanden vergessen habe, bitte ich um Nachsicht. Ggf. bitte einfach noch einmal melden.
@Frank.
konntest du dein Problem denn inzwischen lösen?
Übrigens, heute ist Tag 60 mit dem meine Sensoren nach dem Update V0.14 mit dem Batteriefix.
Aktuelle Spannung sind 3 V.
Viele Grüße
Dirk
Welche FW verwendest Du ?
Die des letzten Releases. v0.14
https://github.com/kc-GitHub/Wettersensor/releases/tag/v0.14_beta
Gruß
Dirk
Was ist denn der Unterschied zur v0.15?
Andreas
Zitat von: knochenmuehle am 30 April 2015, 21:52:50
Was ist denn der Unterschied zur v0.15?
Andreas
Hallo Andreas,
diese Frage habe ich auch schon gestellt, in der v0.15 hat Dirk ein paar serielle Ausgaben zum Ermitteln des Peering mit Aktoren eingebaut (soweit ich das verstanden habe) und die Version ist noch nicht released ;)
Gruß PeMue
Zitat von: PeMue am 30 April 2015, 21:56:15
diese Frage habe ich auch schon gestellt, in der v0.15 hat Dirk ein paar serielle Ausgaben zum Ermitteln des Peering mit Aktoren eingebaut (soweit ich das verstanden habe) und die Version ist noch nicht released ;)
Korrekt.
Aktuell in Entwickling ist hier:
- Optimierte Debug-ausgaben
- Lazy config (funktioniert noch nicht richtig)
- rx_burst, wenn eingeschaltet geht der Sensor aber aktuell nicht schlafen, nach 2-3 Tagen dürfte die Batterie dann leer sein :)
Daher ist das aktuell nur eine Entwickler Version.
Gruß
Dirk
läuft mit meinen Einstellungen aber ohne Probleme seit Wochen ;)
Zitat von: Dirk am 30 April 2015, 21:10:12
Die des letzten Releases. v0.14
https://github.com/kc-GitHub/Wettersensor/releases/tag/v0.14_beta
Gruß
Dirk
Hmm, saugt bei mir immer noch die Batterien leer.
Was hast du denn für eine Spannungskurve?
Der Bugfix in V0.14 behebt den Überlauf der Millis, der dafür sorgt dass der Sensor nach ~50 Tagen nicht mehr in den Standby-Mode geht.
Somit hatte man vor V0.14 eine sehr flach verlaufende Spannungskurve, die nach ~50 Tagen steil abfällt. Nach weiteren 1-2 Tagen waren dann die Batterien leer.
Aktuell habe ich mit meinen 4 hier laufenden Sensoren auch nach über 60 Tagen eine gleichmässige sehr flache Entladekurve.
Nach wie viel Tagen sind denn deine Batterien leer?
Kannst du mal den Stromverbrauch vom Sensor messen?
Viele Grüße
Dirk
Zitat@Frank.
konntest du dein Problem denn inzwischen lösen?
hm... hatte ich ein problem? ???
Zitat von: frank am 06 Mai 2015, 08:53:46
hm... hatte ich ein problem? ???
Ach mist, Ich meinte Volker
Zitat von: volker.m am 17 April 2015, 02:07:02
Seit dem 19. März funktioniert die Temperatur nicht mehr. Vielleicht gab es an dem Tag oder kurz davor ein Update welches damit im Zusammenhang stehen kann.
Also nochmal die Frage an Volker.
Konntest du dein Problem denn inzwischen lösen?
Gruß
Dirk
Hallo Dirk,
danke für Dein Interesse. Das Problem ließ sich mit den hier genannten Hilfestellungen nicht lösen. Ich habe mittlerweile einen eigenen Nachbau Deines Fühlers (mit SHT10) im Einsatz - das gleiche Phänomen. Ich habe das Problem "gelöst" indem ich das Attribut event-on-update-reading
temperature,humidity,batVoltage,battery gesetzt habe. Jetzt bekomme ich mein Reading für die Temperatur welches auch in mysql geschrieben wird. Auf der anderen Seite wird jetzt state wie im Anhang zu erkennen ist nicht mehr aktualisiert was für mich aber kein Problem darstellt. Die Temperatur im state ist im Anhang gleich der des Readings temperature, das liegt aber daran daß ich den Screenshot jetzt schnell gemacht habe und es in der kurzen Zeit keine Temperaturänderung gab.
Volker
Universalsensor an CCU2.
Ich habe Dirk angemailt, er hat mir superschnell den Aussensensor zukommen lassen.
Patch .14 von Github eingespielt. Neue Geräte gesucht. Alles klappte auf Anhieb. Gerät gefunden, eingestellt, ins Programm eingebunden.
Ich habe noch einen halbdurchlässige helle Kunststoffplatte gebastelt, wegen der Übersteuerung bei voller Sonnenbestrahlung.
Jetzt muss ich die passenden Werte noch ermitteln, dann sollte alles gehen.
Bisher perfekt.
Was ich bisher nicht hinbekommen habe, auf einfachem Weg die Helligkeit in Pocket Control HM angezeigt zu bekommen.
Hi abu,
Zitat von: abu am 10 Mai 2015, 10:48:26
Jetzt muss ich die passenden Werte noch ermitteln, dann sollte alles gehen.
Am einfachsten misst du einmal mit Folie / Kunststoffplatte und einmal ohne.
Daraus kannst du dir dann den Korrektufaktor ermitteln.
ZitatWas ich bisher nicht hinbekommen habe, auf einfachem Weg die Helligkeit in Pocket Control HM angezeigt zu bekommen.
Könnte sein dass Pocket Control HM nur "bekannte" HM-Devices anzeigt?
Ggf. mal den Entwickler fragen.
Viele Grüße
Dirk
Hallo,
nach längerer Pause habe ich meine Helligkeitssensoren wieder in Betrieb genommen.
Diese laufen noch mit Firmware Version 0.11 und haben den Millis-Bug, der die Batterie nach 49(?) Tagen leersaugen würde.
Gibt es einen Workaround für den Fehler? (z.B. Batterie raus/rein) ?
Die Bugfix in der neueren Firmware ist ja noch nicht offiziell freigegeben (d.h. Beta)
VG
Marcus
Hi Marcus,
du kannst die V0.14 beruhigt verwenden.
Beta hatte ich das Release nur genannt, da ich noch nicht sicher war ob der Bug damit gefixt war.
Meine Sensoren laufen bei mir seit 02. März ohne Neustart durch.
Batteriespannung ist anfänglich von 3,3V auf jetzt 2,9V abgesunken.
Viele Grüße
Dirk
Kann ich bestätigen. Mit der 0.14 scheint der Bug tatsächlich gefixed. Meiner läuft einwandfrei seit deutlich über 60 Tagen mit wenig bzw. fast gar keinem Spannungsabfall.
Ja, tun brav ihren Job.
Nur das halten des Peering mit anderen Geräten funktioniert noch nicht einwandfrei.
Aber soweit ich das mitbekommen habe, gab es noch von niemanden (mich eingeschlossen) eine Rückmeldung an Dirk.
Sobald ich kommende Woche meine schriftliche Abschlussprüfung hinter mich gebracht habe, siehts zeitlich aber wieder besser aus. :-)
Hallo,
vielen Dank für die Rückmeldungen. Dann werde ich das Update mal in Angriff nehmen
Da die v0.14 als gut befunden wird, möchte ich auch ein Update "wagen". Ich habe aber leider den Überblick verloren, wie ich das Update durchführen kann. Mein Device ist derzeit v0.12 und läuft an einem CUL. Was ist zu tun?
Firmware hier aus dem ZIP rausholen: https://github.com/kc-GitHub/Wettersensor/archive/v0.14_beta.zip
Batterie aus dem Sensor raus, Configtaste drücken und beim Einlegen gedrückt halten.
Mit flash-ota aus https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb updaten.
Ich habe das Wiki mal entsprechend aktualisiert:
http://www.fhemwiki.de/wiki/Universalsensor#OTA_.28OverTheAir.29_Firmwareupdate
Viele Grüße
Dirk
Vielen Dank Jungs,
meine beiden Sensoren habe ich erfolgreich geupdated :-).
Einen schönen Abend
Frank
Wie sieht es bei Euch mit der Empfangsleistung / -Empfindlichkeit aus?
Ich habe festgestellt, dass der Innensensor einen RSSI von -57 hat. Der Außensensor ist leider mein "Problemkind": Hier komme ich bei geöffnetem Gehäuse (und gleichem Abstand wie der Innensensor) nur auf einen RSSI von -70. Mit geschlossenen Deckel (ohne Folie) auf -75 und mit Folie auf -83. Dies bedeutet leider, dass ich keinen Empfang zum Außensensor habe, wenn er draußen ist :-\.
Habt Ihr ähnliche Erfahrungen gemacht? und wie kann man den Empfangspegel erhöhen?
Hallo Frank,
mein Außensensor war die letzten Tage auch mein Problemkind, ich habe nur einen RSSI von -96 und da bin ich mir nicht sicher, ob das immer schon so war. Ich habe ihn so ausgerichtet, dass der Pegel bestmöglich ist.
Bei der Suche in den Daten habe ich heute morgen festgestellt, dass die Spannungsmessung von Firmware v0.12 und die Firmware v0.15 etwas unterschiedlich messen:
Firmware v0.12
2015-04-09_07:46:23 HM_Dach_T_P_L batVoltage: 2.44
Firmware v0.15
2015-04-09_19:46:54 HM_Dach_T_P_L batVoltage: 2.60
Dazwischen war kein Laden der Akkus (ich verwende 2 AAA Akkus).
@Dirk: Ich meine, irgendwo gelesen zu haben, dass Du da (die Formatierung) geändert hast. Hast Du auch etwas an der Messung am A/D-Wanlder verändert? Ich habe dein Eindruck, dass die Spannung in die Knie geht und sollte mal nachmessen. Leider sitzt der Sensor auf dem Dach :(
Gruß und schönen Sonntag.
PeMue
Edit:
Und noch eine Frage:
Die Firmware v0.14 des Innensensors hat folgende Readings:
Activity alive 2015-05-25 11:49:27
D-firmware 0.14 2015-05-25 11:49:27
D-serialNr UWS0616649 2015-05-25 11:49:27
Bei meinem Außensensor mit Firmware v0.15 gibt es ein paar mehr:
R-altitude 0 m 2015-04-09 12:15:23
R-burstRx off 2015-04-09 12:15:23
R-ledMode on 2015-04-09 12:15:23
R-lowBatLimitTHPL 1.6 V 2015-04-09 12:15:23
R-transmDevTryMax 3 2015-04-09 12:15:23
Liegt das an der Firmware? Ein getconfig brachte nichts weiter. Oder muss ich noch einmal pairen? Aber der Innensensor liefert Daten ...
hallo,
bin neu dabei und habe seit 2 wochen jeweils einen innen und aussensensor. beide liegen noch in 40 cm enfernung vom humusb ohne gehäuse oder folie nebeneinander. beide in v 0.14.
rssi wert: innensensor -22 aussensensor -37=15 differenz. gruss zwehn
Hallo,
nur eine kurze Rückmeldung von mir:
HMCFGUSB ist eingetroffen und ich konnte erfolgreich auf v0.14 upgraden.
VG
Marcus
Hallo,
hat den irgendjemand eine funktionierende Schritt für Schritt Anleitung in der Schublade, um vom alten seriellen Bootloader auf OTA zu kommen?
Mein Versuch mit dem Außensensor endete in einem reanimationspflichtigen Stück Elektronik, welches Dirk dankenswerter Weise ins Diesseits zurückgeholt hat. Ich hatte versucht, betateilchens Leidensweg (S. 108ff) nachzugehen und habe dann die Fuses falsch gesetzt...
Bevor ich den 2. Versuch mit meinem Innensensor starte deshalb nochmal die Frage in die Runde.
Vielen Dank
Boris
Zitat von: PeMue am 24 Mai 2015, 10:20:52
Und noch eine Frage:
Die Firmware v0.14 des Innensensors hat folgende Readings:
Activity alive 2015-05-25 11:49:27
D-firmware 0.14 2015-05-25 11:49:27
D-serialNr UWS0616649 2015-05-25 11:49:27
Bei meinem Außensensor mit Firmware v0.15 gibt es ein paar mehr:
R-altitude 0 m 2015-04-09 12:15:23
R-burstRx off 2015-04-09 12:15:23
R-ledMode on 2015-04-09 12:15:23
R-lowBatLimitTHPL 1.6 V 2015-04-09 12:15:23
R-transmDevTryMax 3 2015-04-09 12:15:23
Liegt das an der Firmware? Ein getconfig brachte nichts weiter. Oder muss ich noch einmal pairen? Aber der Innensensor liefert Daten ...
... die Devise heißt Geduld. Mittlerweile sind die Werte da.
Gruß PeMue
Zitat von: Bastel-Frank am 23 Mai 2015, 18:26:01
Habt Ihr ähnliche Erfahrungen gemacht? und wie kann man den Empfangspegel erhöhen?
ja mir geht das ganz genauso, mein Außensensor bekommt oberhalb von ich schätze mal 2,5m überhaupt gar keine Verbindung... lege ich ihn ca 2m entfernt zeigt er mir brav die Innentemperatur an :-\ ;)
Aber eigentlich soll der ja draußen sein und das sind ca. 9m
Hier mal meine "rssi_at_HMUSB -78"
Zitat von: PeMue am 24 Mai 2015, 10:20:52
Bei der Suche in den Daten habe ich heute morgen festgestellt, dass die Spannungsmessung von Firmware v0.12 und die Firmware v0.15 etwas unterschiedlich messen:
Das ist korrekt. Die Spannungsmessung hatte ich etwas angepasst. Vorher war die Messung zu niedrig..
ZitatIch meine, irgendwo gelesen zu haben, dass Du da (die Formatierung) geändert hast. Hast Du auch etwas an der Messung am A/D-Wanlder verändert?
Ich habe lediglich den Fahltor für den Spannungswandler geändert. Die übermittlung der Messdaten erfolgt jetzt auch nur nich in 0,x V und nicht mehr in 0,xx V
ZitatIch habe dein Eindruck, dass die Spannung in die Knie geht und sollte mal nachmessen.
In welchem Zeitraum?
welche FW.Version hast du drauf?
Bei v0.15 kann man burst aktivieren. Das funktioniert aber noch nicht richtig und sorgt dafür dass der sensor nicht mehr schlafen geht. Check das mal bitte.
ZitatBei meinem Außensensor mit Firmware v0.15 gibt es ein paar mehr:
Ja, hier gibt es mehr Einstellungen.
Zitat von: moonsorrox am 28 Mai 2015, 17:58:16
ja mir geht das ganz genauso, mein Außensensor bekommt oberhalb von ich schätze mal 2,5m überhaupt gar keine Verbindung
Das darf definitiv nicht sein. Seze den Sensor mal komplett zurück (reset).
Falls alles nichts hilf muss ich mir den wohl mal anschauen.
Viele Grüße
Dirk
Zitat von: Dirk am 29 Mai 2015, 10:54:27
In welchem Zeitraum?
Welche FW-Version hast du drauf?
Hallo Dirk,
ich habe bei dem Außensensor die FW 0.15 drauf. Anbei mal ein Plot, die Spannung bleibt über einen Monat stabil, ich hatte nur im Mai ein bisschen "Gezapple" zwischen 2.5 und 2.6 V:
(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=32710;image)
Man sieht schön den Wechsel zwischen FW 0.12 und FW 0.15.
Gruß PeMue
Hallo Dirk,
Zitat von: Dirk am 29 Mai 2015, 10:54:27
Ich habe lediglich den Faktor für den Spannungswandler geändert. Die Übermittlung der Messdaten erfolgt jetzt auch nur in in 0,x V und nicht mehr in 0,xx V
dann hätte ich einen Vorschlag für einen Patch von HMConfig_SenTHPL.pm
61c61
< $batVoltage = sprintf('%.2f', (($batVoltage + 0.00) / 1000));
---
> $batVoltage = sprintf('%.1f', (($batVoltage + 0.0) / 1000));Die zweistellige Anzeige nach dem Komma ist dann obsolet.
Gruß PeMue
Ich habe meine Devices von 0.12 auf 0.14 upgedatet. Wie komme ich an die neuen Einstellmöglichkeiten (z.B. ledMode)? ... das pairing habe bereits erneut durchgeführt und "getConfig" gemacht
Zitat von: PeMue am 29 Mai 2015, 21:33:01
ich hatte nur im Mai ein bisschen "Gezapple" zwischen 2.5 und 2.6 V:
Klar, weil so genau mißt der ja nicht. Dann "zappelt" es etwas. Mal sehen vielleicht baue ich in der nächsten Version eine "Zappelsperre" ein :)
Zitat von: PeMue am 30 Mai 2015, 11:07:38
dann hätte ich einen Vorschlag für einen Patch von HMConfig_SenTHPL.pm
das ist noch wegen der Rückwärtskompatibilität noch so drin.
In einer späteren Version des Moduls nehme ich die 2. Kommastelle raus.
Zitat von: Bastel-Frank am 03 Juni 2015, 08:02:23
Wie komme ich an die neuen Einstellmöglichkeiten (z.B. ledMode)? ... das pairing habe bereits erneut durchgeführt und "getConfig" gemacht
Hast du das PM-File aus dem 0.14er Tag in FHEM eingespielt?
Viele Grüße
Dirk
ZitatHast du das PM-File aus dem 0.14er Tag in FHEM eingespielt?
Nö, habe ich nicht ;D ... dann mache ich das mal.
Hi Leute,
Bin über Zufall im Wiki auf den Sensor aufmerksam geworden.
Leider konnte ich jetzt nichts finden, was die Beschaffung des ganzen angeht.
Kann ihr hierzu einer Informationen geben?
Danke und Gruß Robert
Hallo Robert,
gleich dreimal denselben Post? Bitte ggf. zwei davon löschen ;)
Einfach eine mail an Dirk, der wird Dir dann eine Mail schicken mit den Konditionen. Kann aber derzeit ein bisschen dauern ...
Gruß PeMue
Hi PeMue,
Ja leider drei mal. Tapatalk bringt immer wieder einen Fehler beim Posten.
Und bei aktualisieren bringt er auch nix neues.
Hab schon gelöscht.
Danke für den Tipp. Ich werde ihn dann mal kontaktieren.
Danke und Gruß Robert
Hallo zusammen,
ich hätte noch einen Verbesserungsvorschlag für die Software. Ab und zu habe ich folgende Messwerte:
(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=33016;image)
2015-06-05_09:23:23 HM_Dach_T_P_L T: 42.0 L: 65535 P: 991.3 P-NN: 1019.5
Wenn man im Datenblatt nachschaut, wird 65535 bei Lichtsensor ausgegeben, wenn ein Fehler bei der Messung auftritt. Passiert so ein bis zwei Mal im Monat.
Mein Vorschlag: Den vorigen gemessenen Wert speichern und nocheinmal übertragen oder im Falle von 65535 einfach nocheinmal messen.
Danke + Gruß
PeMue
ZitatMein Vorschlag: Den vorigen gemessenen Wert speichern und nocheinmal übertragen oder im Falle von 65535 einfach nocheinmal messen.
oder in fhem verarbeiten. da ist der alte wert bereits bekannt und zusätzlich hat man die info über störungen bei der messung. vielleicht sind das die ersten anzeichen eines nahenden defektes. könnte man in einem "error"-reading abbilden.
ps: bei euch ist es ja ganz schön warm. hoffentlich nicht im schatten gemessen. ;)
Zitat von: frank am 06 Juni 2015, 14:49:11
ps: bei euch ist es ja ganz schön warm. hoffentlich nicht im schatten gemessen. ;)
Hallo Frank,
keine Angst, der Sensor sitzt unterhalb der Photovoltaikanlage, da soll es warm (wegen Solar) bzw. hell (wegen Photovoltaik) sein.
Aber der Tipp mit der Verarbeitung in fhem ist gut, den schaue ich mir mal an.
Gruß PeMue
Ich hab von Dirk einen Innensensor und einen Außensensor und ich hab das Gefühl, dass der Außensensor (seit ich letzte Woche das FW-Update gemacht habe?) etwas krumme Werte anzeigt. Ich habe beide Sensoren im Moment auf dem Balkon liegen zusammen mit zwei Oregon Scientific thgr228n als Referenz.
Die beiden THGR228N zeigen momentan 23,9 °C an. Der Innensensor 24,0 °C. Der Außensensor zeigt jedoch 25,6 °C an, was schon eine ganz schöne Abweichung ist.
Luftfeuchte bei den THGR momentan 51 % bzw 52 %, Innensensor 52 %. Außensensor zeigt 58 %.
Letzte Woche direkt nach dem Aufspielen der Firmware hat sich ca. 24h lang die Luftfeuchte gar nicht mehr bewegt und hing bei 47 % fest. Da hab ich einmal Batterien rein-raus und nun tut das wieder.
Firmware ist die aktuellste (0.15?). Kennt das jemand bzw. Ideen dazu? Vielen Dank!
Zitat von: frank am 06 Juni 2015, 14:49:11
... oder in fhem verarbeiten.
Hallo Frank,
in welcher Variable ist der alte Wert denn in fhem bekannt?
Ich wäre mit userReadings ins Rennen gegangen, aber ich bräuchte dann mehrere:
- im Falle luminosity ungleich 65535 den aktuellen Wert in luminosity_last sichern
- im Falle von 65535 eine Fehlervariable luminosity_err (die sollte vorher mit Null initialisiert werden) um eins erhöhen
- im Fall von 65535 die bestehenden Readings luminosity bzw. state anpassen
Mir ist noch nicht klar, wie ich mehrere UserReadings definiere, aber das bin ich noch am suchen ;)
Oder geht es auch einfacher?
Danke + Gruß
PeMue
Zitatin welcher Variable ist der alte Wert denn in fhem bekannt?
ich hatte gedacht, die verarbeitung eventuell in HMConfig_SenTHPL.pm einzubauen. bevor das reading luminosity gesetzt wird, den neuen wert prüfen und entsprechend behandeln. ich weiss aber nicht, ob das an dieser stelle funktioniert. halt nur so ein gedanke. mit userreadings sollte es natürlich auch funktionieren. etwa so
attr my_sensor userReadings luminosity2:luminosity {(ReadingVal($name,"luminosity",0) if(ReadingVal($name,"luminosity",0)!=65535)},luminosity_err:luminosity {ReadingsVal($name,"luminosity_err",0)+1 if(ReadingVal($name,"luminosity",0)==65535)}ZitatMir ist noch nicht klar, wie ich mehrere UserReadings definiere, aber das bin ich noch am suchen
hintereinander, durch komma getrennt.
Ich versuche gerade, meine Sensoren von 0.13 auf 0.14/0.15 upzugraden. Als ich damals das Update auf 0.13 über OTA eingespielt hatte, funktionierte das einwandfrei. Nun klappt gar nichts mehr und ein Sensor meldet sich nicht mehr.
Ich mache das per flash-ota. Das Programm findet den Sensor, wenn ich ihn neu starte und überträgt die Datei (ich nehme die EQ3). Dann kommt der Reboot und das Programm beendet sich. Nun würde ich erwarten, dass mir in FHEM die Firmware 0.15 angezeigt wird. Dort steht aber immer noch 0.13. In FHEM selbst sehe ich, dass ein Sensor "fwUpdate: fail:Block1" ausgibt. Der lief jetzt seit einem Tag (aber immer noch mit der 0.13). Seit 14:00 Uhr gibt es von ihm aber keine Signale mehr. Interessant auch, dass batVoltage immer mit 3.00 übertragen wurde.
Ein anderer Sensor meldet den fwUpdate Fehler nicht, gibt aber auch sonst keinen Mucks mehr von sich. Bei beiden kann ich aber den OTA Transfer immer wiederholen. Geschrottet sind sie wohl nicht, aber die Firmware scheinen sie auch nicht richtig zu vertragen.
Hat jemand eine Idee? Was könnte ich noch versuchen? Die aktuellste PM Datei für den Sensor habe ich ins FHEM Verzeichnis gekippt. FHEM habe ich ebenfalls per Update auf den aktuellen Stand gebracht.
die fw-version wird nur gesendet, wenn du den sensor in den anlernmodus setzt. einmal (kurz?) den taster drücken.
Hallo Frank, danke. Ich habe das eben gemerkt und werde das im WIKI ergänzen. Der erste Sensor läuft wieder. Den anderen knöpfe ich mir gleich mal vor.
Nur eine kuriose Sache verbleibt: Warum wird als batVoltage immer 3.00 angezeigt? Firmware ist 0.14 bzw. 0.15. Ich dachte, dass wäre auf eine Nachkommastelle gerundet? Die tatsächliche Spannung müsste irgendwo zwischen 2.4 und 2.9 liegen. PM Datei habe ich aus dem 0.14 Archiv aktualisiert.
Kann das am MAX1724 liegen und es wird jetzt die umgewandelte Spannung angezeigt und nicht mehr die Eingangsspannung?
Zitat von: kmatthias am 07 Juni 2015, 15:40:26
Kann das am MAX1724 liegen und es wird jetzt die umgewandelte Spannung angezeigt und nicht mehr die Eingangsspannung?
Hallo Matthias,
ich habe einen Innen- (FW 0.14) und einen Außensensor (FW 0.15), die Spannung jweils 2.6 bzw. 2.7 V (ich habe Akkus drin). Lösche doch einfach mal das Reading Spannung und schau, was passiert ...
Gruß PeMue
Reading gelöscht und 3 Minuten später steht da wieder 3.00. Komisch ...
schmeiss doch mal gebrauchte/andere batterien rein.
Zitat von: PeMue am 06 Juni 2015, 14:26:02
Wenn man im Datenblatt nachschaut, wird 65535 bei Lichtsensor ausgegeben, wenn ein Fehler bei der Messung auftritt.
Was ich bisher nur bekommen habe wenn es zu hell ist, der Sensor also übersteuert.
Lauf deiner Grafik gibt es da aber einen Ziemlichen Ausreiser welchen ich mir so erstmal nicht erklären kann.
Evtl.liegt es an der automatischen Empfindlichkeitsumschaltung. Hast du die Ausreißer immer bei gleichen Helligkeitswerten?
Zitat von: frank am 06 Juni 2015, 14:49:11
ps: bei euch ist es ja ganz schön warm. hoffentlich nicht im schatten gemessen. ;)
Das ist wohl die gemessene Temperatur im Geäuse des Sensors, und daher nur bedingt zu gebrauchen :)
Zitat von: vbs am 06 Juni 2015, 16:26:35
Der Innensensor 24,0 °C. Der Außensensor zeigt jedoch 25,6 °C an, was schon eine ganz schöne Abweichung ist.
Du hast den SHT10 am Außensensor?
Wie viel Luft bekommt der?
Zitat von: kmatthias am 07 Juni 2015, 15:40:26
Nur eine kuriose Sache verbleibt: Warum wird als batVoltage immer 3.00 angezeigt? Firmware ist 0.14 bzw. 0.15. Ich dachte, dass wäre auf eine Nachkommastelle gerundet?
So ist das auch. Es werden derzeit aber noch 2 Nachkommastellen in FHEM angezeigt. Die letzte ist dann 0.
ZitatKann das am MAX1724 liegen und es wird jetzt die umgewandelte Spannung angezeigt und nicht mehr die Eingangsspannung?
Es wird die Batteriespannung gemessen. Wenn du magst kannst du das auch im Schaltplan nachprüfen :)
Zitat von: kmatthias am 07 Juni 2015, 17:27:19
Reading gelöscht und 3 Minuten später steht da wieder 3.00. Komisch ...
Dann sollten Die Batterien auch 3 V haben (+/-) Ist ja kein Präzisionsmessgerät :)
Viele Grüße
Dirk
Zitat von: Dirk am 07 Juni 2015, 18:07:24
Du hast den SHT10 am Außensensor?
Wie viel Luft bekommt der?
Ja, mit SHT10. Der liegt draußen auf der Fensterbank. Hat eigentlich viel Luft :D Meine Vergleichssensoren liegen aber auch genau daneben. Im Moment zeigt der Sensor 19,7 °C und der Oregon-Sensor 18,9 °C. Liegt vermutlich momentan im Bereich der erlaubten Toleranz? Hatte gestern wie gesagt jedoch auch schon Abweichungen um 2 °C.
Hm, momentan SHT10 bei 20,4 °C und der Oregon 17,8 °C. Schon ganz schön happig der Unterschied :( Kann es sein, dass sich das geschlossene Gehäuse irgendwie aufheizt (evtl. auch Eigenwärme?) und daher eine höhere Temperatur gemessen wird? Der Sensor liegt natürlich im Schatten bei mir.
Ich hatte jetzt gerade wieder den Fall, dass der Wert Lufteuchtigkeit seit zwei Tagen "hing". Also es kam seit zwei Tagen immer der gleiche Wert. Einmal Batterie rein-raus und jetzt tut es wieder. Das hab ich jetzt zum zweiten Mal beobachten seit der 0.15, vorher nie. Ich habe jedoch auch noch einen zweiten Sensor (auch mit 0.15). Da trat es jedoch bisher nicht auf. Hat da jemand eine Idee? Ich habe einen SHT10 dran.
Ich wollte auch updaten. Leider scheitere ich schon am herunterladen der zip Datei.
Der Link im Wiki tut bei mir nicht.
Unter Firmware Release in github stehen diverse Dateien.
Da ich mit Windows updaten will, Brötchen ich wohl die tgz Datei.
Ich nehme an, das I für indoor und O für Outdoor steht.
Aber mit rechter Maustaste Ziel speichern unter, komme ich nicht weiter.
Und einen Knopf zum Downloaden habe ich auch nicht gesehen.
Wie komme ich also nun an die Dateien?
Ok. Hab es. Sorry. Raw heißt der Knopf.
Tsss
ZitatDa ich mit Windows updaten will, Brötchen ich wohl die tgz Datei.
geht auch mit eq3-file. kann man in der win-sw einstellen.
Innen und Außensensor erfolgreich von 0.12 auf 0.15 gehoben.
Ohne Probleme.
Bin schon gespannt, wie lange die Batterien nun halten werden.
Bei mir laufen die seit Anfang April und sind immer noch voll.
NAME Umweltsensor_Innen
NR 310
STATE T: 18.6 H: 60 L: 2.59 P: 982.5 P-NN: 1023.7
TYPE CUL_HM
lastMsg No:F7 - t:70 s:A232FE d:12D2E7 00BA3C2661000001030BB8
protLastRcv 2015-06-18 19:51:18
protSnd 2282 last_at:2015-06-18 19:51:18
protState CMDs_done
rssi_at_HM1 cnt:2284 max:-64 min:-88 avg:-68.23 lst:-67
Readings:
2015-06-14 09:34:33 Activity alive
2015-03-03 09:56:07 CommandAccepted yes
2015-03-03 09:55:41 D-firmware 0.14
2015-03-03 09:55:41 D-serialNr UWS5617666
2015-03-06 18:26:14 Dämmerung 5
2014-10-10 21:08:30 PairedTo 0x12D2E7
2014-10-10 21:08:30 R-burstRx off
2015-03-03 09:55:41 R-pairCentral set_0x12D2E7
2015-03-03 09:59:56 RegL_00: 0
2015-06-18 19:51:18 batVoltage 3.00
2015-06-18 19:51:18 battery ok
2015-06-18 19:51:18 humidity 60
2015-04-04 19:38:45 lastBatChange Sat Apr 4 19:38:45 2015
2015-06-18 19:51:18 luminosity 2.59
2015-06-18 19:51:18 pressure 982.5
2015-06-18 19:51:18 pressure-nn 1023.7
2015-06-18 19:51:18 state T: 18.6 H: 60 L: 2.59 P: 982.5 P-NN: 1023.7
2015-06-18 19:51:18 temperature 18.6
Siehe lastBatChange :) (der Tag, an dem ich auf 0.14 geupdatet habe)
lg, Ici
LastBatChange ist ein userreading?
Ich vermute, Ici hat beim Batteriewechsel ein Reading angelegt, das solange hält, bis er das (nach Batteriewechsel) wieder überschreibt. Übrigens ist gestern mein Sensor auf dem Dach abgek***.
Das Ding hängt seit dem 22.03. auf dem Dach (mit Akkus), ich denke, ich muss da die Spannung anpassen, dann hätte ich gegensteuern können.
Gruß PeMue
LastBatChange ist ein userreading?
Sorry. Tapatalk.
Das wird von einem Notify gesetzt, sobald bei einem Gerät der Batterie-Status auf "ok" springt:
define BatMeldung notify .*:[Bb]attery:.* {if($EVENT !~ m/ok/i) {
if (AttrVal("$NAME","comment",0) ne 1) {
Log 3,"Bat $NAME $EVENT";
fhem "attr $NAME comment 1";
fhem "set Pushover1 msg 'Batterie' 'Bitte Batterie bei Gerät $NAME tauschen' '' 0 '' ";
}
}elsif($EVENT =~ m/ok/i) {fhem("setreading $NAME lastBatChange ".localtime);fhem("deleteattr $NAME comment")}
}
Bei den Batterie-betriebenen Devices hab ich noch überall ein event-on-change auf die [Bb]attery-Readings sitzen.
Somit hab ich bei allen Geräten immer den letzten Batterietausch im Reading.
lg, Ici
Cool. Das baue ich bei Gelegenheit auch ein. Danke.
Gibt sicher elegantere Lösungen dafür, als ein attr comment zu setzen, aber bei mir funktionierts bisher einwandfrei.
Nur darf man nicht vergessen, das event-on-change zu setzen, sonst wird der lastBatStatus ständig neu gesetzt.
Aber jetzt wieder btt :)
Info zur Verbesserung des RSSI, speziell beim Außensensor:
Ich hatte in einem vorherigen Post berichtet, dass der RSSI des nackten Moduls gut ist. Baut man das Modul in das Außengehäuse ein, so verschlechtert sich der RSSI erheblich, was bei mir dazu führt, dass der Kontakt zum eigentlichen Standort des Moduls (Gartenhaus) nicht mehr gewährleistet ist. Das Gehäuse scheint doch stärker abzuschirmen, als man vermuten würde. Ich habe daher die Antenne nach hinten durch eine kleine Bohrung herausgeführt und auf die Länge von ca. 8,5cm verlängert. Seit dem habe ich einen stabilen Empfang.
Hej Dirk,
korrigiere mich, wenn ich mich täusche, aber war nicht angedacht, dass der Sensor bei erreichen (oder unterschreiten) des lowBatLimitTHPL das Senden von Daten einstellt (wobei battery & batVoltage vielleicht auch weiter übertragen werden könnten?).
Heute in der Nacht ist bei einem meiner Sensoren (v0.14) eine der beiden Zellen zusammen gebrochen, wodurch der eingestellte Grenzwert von 1,6V klarer weise unterschritten wurde. ;-)
Die dann übertragenen Werte sehen folgendermaßen aus:
2015-06-20_04:37:17 sensorLounge batVoltage: 1.8
2015-06-20_04:37:17 sensorLounge T: 22.8 H: 44 L: 0.03
2015-06-20_04:40:45 sensorLounge batVoltage: 1.8
2015-06-20_04:40:45 sensorLounge T: 22.8 H: 44 L: 0.06
2015-06-20_04:43:56 sensorLounge batVoltage: 1.8
2015-06-20_04:43:56 sensorLounge T: 22.8 H: 44 L: 0.06
2015-06-20_04:46:50 sensorLounge batVoltage: 1.8
2015-06-20_04:46:50 sensorLounge T: 22.8 H: 44 L: 0.05
2015-06-20_04:49:29 sensorLounge batVoltage: 1.8
2015-06-20_04:49:29 sensorLounge T: 22.7 H: 44 L: 0.05
2015-06-20_04:51:51 sensorLounge batVoltage: 1.8
2015-06-20_04:51:51 sensorLounge T: 22.7 H: 44 L: 0.06
2015-06-20_04:55:09 sensorLounge batVoltage: 1.8
2015-06-20_04:55:09 sensorLounge T: 22.7 H: 44 L: 0.04
2015-06-20_04:55:18 sensorLounge batVoltage: 0.6
2015-06-20_04:55:18 sensorLounge T: 22.3 H: 43 L: 0.04
2015-06-20_04:55:25 sensorLounge batVoltage: 0.5
2015-06-20_04:55:25 sensorLounge T: -39.7 H: 27 L: 0.04
2015-06-20_05:05:19 sensorLounge batVoltage: 0.5
2015-06-20_05:05:19 sensorLounge T: 97.3 L: 0.05
2015-06-20_05:05:26 sensorLounge batVoltage: 0.5
2015-06-20_05:05:26 sensorLounge T: 27.3 H: 10 L: 0.05
2015-06-20_05:05:34 sensorLounge batVoltage: 0.5
2015-06-20_05:05:34 sensorLounge T: 23.5 H: 38 L: 0.05
.
.
.
2015-06-20_05:38:07 sensorLounge batVoltage: 0.5
2015-06-20_05:38:07 sensorLounge T: 102.4 L: 0.3
2015-06-20_05:38:14 sensorLounge batVoltage: 0.5
2015-06-20_05:38:14 sensorLounge T: 68.2 L: 0.3
2015-06-20_05:38:22 sensorLounge batVoltage: 0.5
2015-06-20_05:38:22 sensorLounge T: 85.1 L: 0.3
2015-06-20_11:21:27 sensorLounge batVoltage: 2.4
2015-06-20_11:21:27 sensorLounge T: 25.7 H: 44 L: 4.18
2015-06-20_11:23:57 sensorLounge batVoltage: 2.4
2015-06-20_11:23:57 sensorLounge T: 25.4 H: 44 L: 1.35
2015-06-20_11:27:23 sensorLounge batVoltage: 2.4
2015-06-20_11:27:23 sensorLounge T: 25.3 H: 44 L: 1.84
2015-06-20_11:30:32 sensorLounge batVoltage: 2.4
2015-06-20_11:30:32 sensorLounge T: 25.0 H: 44 L: 1.48
2015-06-20_11:33:25 sensorLounge batVoltage: 2.4
2015-06-20_11:33:25 sensorLounge T: 24.9 H: 45 L: 1.71
Vielleicht liegt das Problem auch darin, dass die eine Batterie komplett weggebrochen ist und der eingestellte Grenzwert übersprungen wurde.
Aber wenn dann plötzlich Phantasiewerte (vorallem bei der Temperatur) übermittelt werden, kann das bei div. Automatisierungsabläufen zu interessanten Side-Effects führen. :-)
Wäre super, wenn du etwas Licht ins Dunkel bringen könntest. :-)
Vielen Dank!
Hallo zusammen,
mal wieder was zur Batterie. Ist das richtig, dass das Reading
R-lowBatLimitTHPL 1.6 V 2015-05-27 02:35:
mit der Einheit Volt angegeben werden muss, das eigentliche Reading vom Sensor
batVoltage 2.7 2015-06-20 15:39:47 einheitenlos ist.
Ich möchte nur, dass die Software richtig rechnet, ich habe nämlich nicht erkannt, dass die Batterie leer ist.
Danke + Gruß
PeMue
Hallo zusammen,
auch wieder eine Kleinigkeit, aber vielleicht gibt es irgendwas, mit dem man das abfangen kann.
Ich logge den state (da sind dann alle Werte in einer Zeile) und da fehlt ab und an der Wert für die Helligkeit:
2015-06-28_04:50:48 HM_WZ_T_P_H_L T: 19.8 H: 68 L: 0 P: 992.1 P-NN: 1020.3
2015-06-28_04:54:02 HM_WZ_T_P_H_L T: 19.8 H: 68 P: 992.1 P-NN: 1020.3
(Ich habe hier Leerzeichen eingefügt, um das zu verdeutlichen). Meine Vermutung ist, dass das Reading nicht vorhanden ist und daher nicht mit in den String eingebaut wird.
Wenn jemand einen Tipp hat - auch wie ich intelligenter den Fehler logge - sehr gerne.
Da ich spaltenweise plotte fällt natürlich sofort auf, wenn in einem Graph der falsche Wert geplottet wird ;)
Gruß PeMue
Edit: Das passiert etwa einmal pro Tag, aber ich logge nicht alle Daten mit ...
Ich hab irgendwie nach wie vor Probleme mit der Temperaturanzeige meines Außensensors (mit SHT-10). Hier mal ein Graph mit zwei Vergleichssensoren. Der blaue ist ein OregonScientific und der grüne ein Innensensor von Dirk. Die beiden Vergleichssensoren liegen immer ziemlich nah beieinander. Der Außensensor weicht aber davon merklich ab. Sieht so aus, als würde er in Abwärtsphasen ziemlich gut messen. Aber bei steigenden Temperatur gibt es die Abweichungen. Insgesamt ist die Kurve sehr "unruhig". Alle drei Sensoren liegen nebeneinander auf der Fensterbank auf dem Balkon. Den SHT-10 des "Problemsensors" habe ich bereits aus dem Gehäuse heraus geführt.
Fällt evtl. jemandem dazu etwas ein?
Hallo,
habe immer noch das Problem das ich nicht weiß wie ich die Firmware unter Windows mit dem seriellem Bootloader updaten kann.
Habe hier einen extra fred aufgemacht: http://forum.fhem.de/index.php/topic,38016.0.html ist wohl irgendwie unter gegangen.
Die Sensoren funktionieren soweit sehr gut, nur das die Spannung der Batterien immer von Heute auf morgen zusammen bricht (firmware o.12)
Vielleicht kann mir ja jemand unter die schwitzigen Arme greifen ;)
Gruß Holgi
hallo,
bei mir ist ein innensensor, der aussen unterm dach sitzt, während eines gewitters ausgefallen. seit 2 stunden gab es keine meldungen mehr. die led war auf dauer-on. ich dachte erst, dass der sensor voll wasser wäre. aber nein, innen komplett trocken. eine batterie raus und wieder rein, nun funktioniert er wieder. :)
was kann ein dauer-on der led auslösen?
edit: kurz nach 20:00 uhr war die letzte meldung. ich glaube 1,9 volt. sieht aus, als hätte einer die batterie aufgeladen. 22:45 habe ich ihn reannimiert. der sensor hat nach der pause dann als erstes wohl 1,5 volt gemeldet. macht ja sinn, wenn die led 2,5 std gebrannt hat.
(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=34455;image)
gruss frank
Zitat von: The-Holgi am 03 Juli 2015, 11:33:46
... habe immer noch das Problem das ich nicht weiß wie ich die Firmware unter Windows mit dem seriellem Bootloader updaten kann.
Hallo Holgi,
ich habe mir mal folgendes notiert:
bin\avrdude.exe -Cbin\avrdude.conf -patmega328p -carduino -P COM5
-b57600 -D -Uflash:w:HB-UW-Sen-THPL_update_V0_15_000_150303.hex:iwobei Du den seriellen Port anpassen solltest bzw. vermutlich auch die Firmware v0.14 reichen würde. Ggf. noch den Pfad für avrdude anpassen ...
Brauchst Du auch die Verkabelung? Ich meine, ich hätte mal ein Bild (diverse) Seiten vorher gepostet.
Gruß PeMue
Edit:
Hier hatten wir schon mal die Diskussion über das Thema avrdude für Windows ;)
http://forum.fhem.de/index.php/topic,20620.msg281346.html#msg281346
Hallo PeMue, danke für den Tipp. Wusste gar nicht das es avrdude für Windows gibt, das werde ich mir mal ansehen. Die Verkabelung steht und sollte so funktionieren.
Gruß Holgi
Hallo,
habe die firmwarefiles aus dem zip archiv in den avrdude Ordner kopiert.
Müssen hier die rar Dateien aus dem zip Archiv eigentlich auch noch entpackt werden ?
Dann per Eingabeaufforderung zum avrdude Verzeichnis navigiert und anschließend:
avrdude.exe -C\avrdude.conf -patmega328p -carduino -P COM5 -b57600 -D -Uflash:w:HB-UW-Sen-THPL_update_V0_15_000_150303.hex:i
eingegeben.
Ergebnis:
avrdude.exe: can´t open config file No such file or directory
error reading configuration file
Denke da passt was mit dem config file nicht. :-\
Vom atmega328p findet sich in meinem config file auch kein Eintrag.
Edit: Da bin ich schonmal weiter hat sich doch ein \ zuviel eingeschlichen.
jetzt findet er den comport wohl nicht.
Gruß Holgi
Zitat von: The-Holgi am 09 Juli 2015, 14:32:11
Jetzt findet er den comport wohl nicht.
Einfach mal im Windows
Gerätemanager unter
Anschlüsse (COM & LPT) nachschauen und entsrprechend ändern ;)
Gruß PeMue
Ja, hatte nicht gesehen das der comport garnicht passt.
Bekomme jetzt die Meldung:
avrdude.exe: stk500_getsync<>: not in sync: resp=0X00
Kann es sein das man vorm flashen noch den Taster am Sensor betätigen muß oder ähnliches ?
Gruß Holgi
Guten Abend allerseits,
erst mal SUPI was ihr da geleistet habt. Is nur echt schwierig sich durch die ganzen Antworten zu wuseln.
Ich suche nach einer Möglichkeit die Platinen zu bekommen, das wird nirgends so richtig beschrieben und das scheint auch
irgendwie nur an einer einzelnen Person zu hängen. Ich hätte nämlich Interesse an einigen Innen und Aussensensor Platinen.
Also wenn wieder einmal eine Bestellung ausgelöst wird oder aber noch welche vorhanden sind würde ich mich da gerne hinein hängen :-)
Besten Dank schon einmal.
Gruß Andreas
Am besten ists, du schreibst Dirk direkt an.
Hallo,
habe jetzt meinen Innensensor auch von 0.11 auf Version 0.14 upgedated, habe die HMConfig_SenTHPL.pm aus dem Contrib Verzeichnis in mein FHEM kopiert, FHEM neu gestartet und den Sensor wie beschrieben neu gepairt. Soweit alles gut bis auf die Helligkeit, ich bekomme jetzt keine Helligkeitswerte mehr.
Hat jemand ein Idee?
Danke
Gruß
Karl
... eventuell beim Zusammenbauen etwas dazischengeklemmt? Mein Innensensor zeigt Faktor 3-4 weniger an als ein Luxmeter. Aber es zeigt etwas an.
Hast Du diesen Plexiglas-Stift eingebaut?
Gruß PeMue
Hallo Pemue
der Sensor hat ja bis zum Upgrade funktioniert, ich würde jetzt ein HW Problem ausschliessen. Ein zweiter Sensor mit 0.11 funktioniert auch einwandfrei.
Gruß
Karl
Sent from my iPhone using Tapatalk
Hallo
habe jetzt mal Firmware 0.15 ausprobiert, selbes Verhalten, Luminosity = 0
Habe dann meinen zweiten Sensor upgedated, auch von 0.11 auf 0.15. Exakt dasselbe Verhalten, nach dem Updaten keine Helligkeitswerte.
hat noch jemand eine Idee?
Danke und Gruß
Karl
Nachtrag, habe auch nochmal 0.12 ausprobiert, keine Änderung. Habe leider die Version 0.11 nicht gefunden. Also mit 0.12, 0.14, und 0.15 jeqweils das selbe Ergebnis, keine Helligkeitswerte
Deckel falsch draufgesetzt?
Andreas
schon mal werksreset probiert?
beim ersten ist der Deckel richtig drauf, beim zweiten habe ich derzeit keinen Deckel drauf.
Ja, Werksreset habe ich auch bei beiden ausprobiert.
Und es ist hell genug um mehr als 0 Lux anzuzeigen.
Habe auch versucht die Rohdaten aufzuzeichnen, kann damit aber nichts anfangen:
2015.07.21 22:19:23 5: HMLAN/RAW: /E9DB5B5,0000,06C64B48,FF,FFC6,0BA2709DB5B510F5FB012B380000000000000CE4
2015.07.21 22:19:23 5: HMLAN_Parse: HMLAN R:E9DB5B5 stat:0000 t:06C64B48 d:FF r:FFC6 m:0B A270 9DB5B5 10F5FB 012B380000000000000CE4
2015.07.21 22:19:23 5: HMLAN dispatch A140BA2709DB5B510F5FB012B380000000000000CE4::-58:HMLAN
Hallo Karl,
auf github liegt nur die v0.10 (https://github.com/kc-GitHub/Wettersensor/releases/tag/v0.10), ich muss mal schauen, ob ich die v0.11 zu Hause abgelegt habe.
Gruß PeMue
Zitat von: PeMue am 22 Juli 2015, 13:46:32
Hallo Karl,
auf github liegt nur die v0.10 (https://github.com/kc-GitHub/Wettersensor/releases/tag/v0.10), ich muss mal schauen, ob ich die v0.11 zu Hause abgelegt habe.
Gruß PeMue
Danke, obwohl ich fast nicht glaube dass es an der Firmware liegt, dann wäre ich ja nicht der einzige. Ich hatte zuerst noch gedacht das auch noch Version von HMConfig_SenTHPL.pm eine Rolle spielt, aber bei der neusten Version funktionierte auch der Sensor mit 0.11 (mit Ausnahme der neuen Einstellungsmöglichkeiten)
Gruß
Karl
So, der Urlaub ist nun wieder vorbei :(
@schka17
konntest du dein Problem inzwischen lösen?
Viele Grüße
Dirk
Hej Dirk,
mittlerweile ist schon etwas Zeit ins Land gezogen, aber eine Lösung haben wir bislang noch nicht gefunden.
Es geht um die Peering-Problematik mit den RTs.
Wie genau kann ich dich unterstützen, was soll ich tun?
Vielleicht könnte ich das Wochenende bereits etwas beitragen. :-)
Zitat von: Mr. P am 07 August 2015, 12:39:36Es geht um die Peering-Problematik mit den RTs.
Ah, ja. Da war doch noch was. Das Problem habe ich im Prinzip auch. Vielleicht hilft folgende Beobachtung: Ich habe mal den Sensor nicht direkt mit dem RT gepeert, sondern mir in FHEM ein virtuelles Device gemacht, das die Daten vom Sensor übernimmt. Das habe ich dann mit dem RT gepeert und es hat recht stabil funktioniert. D.h. was auch immer in FHEM implementiert ist funktioniert besser als was der Sensor macht.
(Bis darauf, dass der Sensor wenn die Batterie zur Neige geht blödsinnige Werte sendet, aber das ist ein anderes Problem.)
Gruß,
Thorsten
Zitat von: Mr. P am 07 August 2015, 12:39:36
mittlerweile ist schon etwas Zeit ins Land gezogen, aber eine Lösung haben wir bislang noch nicht gefunden.
Es geht um die Peering-Problematik mit den RTs.
Hast du schon mal die 0.15er Version getestet?
die letzten Meldungen waren dass es damit wohl funktioniert. Scheinbar auch nicht nur bei mir.
ZitatVielleicht könnte ich das Wochenende bereits etwas beitragen. :-)
Dieses Wochenende bin ich noch nicht wieder voll einsatzfähig. Falls die 0.15er bei dir aber noch nicht funktioniert, könntest du aber mal den Funkverkehr zwischen beiden Modulen aufzeichen. Mit Microsekunden. Am besten mit einem 2. CUL.
@Thorsten. Könntest du hier bitte auch mal die 0.15er Version testen?
Zitat(Bis darauf, dass der Sensor wenn die Batterie zur Neige geht blödsinnige Werte sendet, aber das ist ein anderes Problem.)
Ja, das muss ich mir auch noch mal ansehen. Mit FW > 0.13 sollte das aktuell hoffentlich nur noch alle 1-2 Jahre passieren :)
Viele Grüße
Dirk
Hej Dirk,
Zitat von: Dirk am 07 August 2015, 13:48:58
Hast du schon mal die 0.15er Version getestet?
Auf irgend einem der Sensoren hab ich die schon drauf. Wobei ich jetzt nicht einmal weiß, ob das einer mit einem RT gepeerter ist. Hatte das Update damals nicht forciert, da ich im Hinterkopf hatte, dass zwischen der 0.14 und der 0.15 nur Logging-Sachen von dir eingebaut wurden.
Zitat von: Dirk am 07 August 2015, 13:48:58
Dieses Wochenende bin ich noch nicht wieder voll einsatzfähig. Falls die 0.15er bei dir aber noch nicht funktioniert, könntest du aber mal den Funkverkehr zwischen beiden Modulen aufzeichen. Mit Microsekunden. Am besten mit einem 2. CUL.
Bitte nicht falsch verstehen... Ich wollte nur das Wochenende nutzen, um endlich ein paar Daten zu liefern. :-)
Und das mit dem Update ist ja kein großes Problem. Ich hol das heute ggf. gleich nach, beobachte es 24 Stunden und geb dir dann entweder mit oder ohne Roh-Daten eine Rückmeldung. :-)
Zitat von: Mr. P am 07 August 2015, 14:03:33
Hatte das Update damals nicht forciert, da ich im Hinterkopf hatte, dass zwischen der 0.14 und der 0.15 nur Logging-Sachen von dir eingebaut wurden.
Da waren ein paar "komische Sachen" im Logging, so dass da etwas durcheinander gewürfelt wurde.
Da ich aber schon ein paar Meldungen bekommen hatte dass das Pairing mit der 0.15 zu funktionieren scheint, könnte es sein das es da noch Sideeffekte gab die sich dadurch mit erledigt haben.
Daher hoffe ich ein bisschen das die 0.15 bei dir und Thorsten auch funktionieren. Dann könnte ich den Bug schließen und an das Release der 0.16 gehen.
ZitatBitte nicht falsch verstehen... Ich wollte nur das Wochenende nutzen, um endlich ein paar Daten zu liefern. :-)
nö :)
Bei der 0.15er Version solltest du nur aufpassen das Burst ausgeschaltet ist. Das lässt den Sensor ansonsten permanent eingeschaltet. Incl. dem damit verbundenen Batterieverbrauch.
ZitatUnd das mit dem Update ist ja kein großes Problem. Ich hol das heute ggf. gleich nach, beobachte es 24 Stunden und geb dir dann entweder mit oder ohne Roh-Daten eine Rückmeldung. :-)
Falls das der Fehler noch da sein sollte, am besten mit FHEM und den Debugausgaben aus dem Sensor gleichzeitig aufzeichen.
Dich brauche da dann nur ein Event mit den ich das FHEM- und das Sensorlog Synchronisieren kann, da das Sensorlog nur einen relativen Timestamp hat.
Einmal die Configtaste drücken sollte ausreichen.
Viele Grüße
Dirk
Zitat von: Dirk am 07 August 2015, 15:15:09
Da waren ein paar "komische Sachen" im Logging, so dass da etwas durcheinander gewürfelt wurde.
Da ich aber schon ein paar Meldungen bekommen hatte dass das Pairing mit der 0.15 zu funktionieren scheint, könnte es sein das es da noch Sideeffekte gab die sich dadurch mit erledigt haben.
Daher hoffe ich ein bisschen das die 0.15 bei dir und Thorsten auch funktionieren. Dann könnte ich den Bug schließen und an das Release der 0.16 gehen.
Ich geb dir Bescheid. Und ich bin auch schon wieder neugierig... was für Änderungen soll die 0.16er bringen? :-)
Zitat von: Dirk am 07 August 2015, 15:15:09
Bei der 0.15er Version solltest du nur aufpassen das Burst ausgeschaltet ist. Das lässt den Sensor ansonsten permanent eingeschaltet. Incl. dem damit verbundenen Batterieverbrauch.
Stimmt, sollte man nicht darauf vergessen. :-)
Zitat von: Dirk am 07 August 2015, 15:15:09
Falls das der Fehler noch da sein sollte, am besten mit FHEM und den Debugausgaben aus dem Sensor gleichzeitig aufzeichen.
Dich brauche da dann nur ein Event mit den ich das FHEM- und das Sensorlog Synchronisieren kann, da das Sensorlog nur einen relativen Timestamp hat.
Einmal die Configtaste drücken sollte ausreichen.
Ahja, die Debugnachrichten vom Sensor.... Muss ich schauen, dass ich irgendwo eine serielle Schnittstelle her bekomme, da mein Bastel-RPi zZ nicht greifbar ist.
Aber mal abwarten, ob das überhaupt noch notwendig ist. :-)
Zitat von: Mr. P am 07 August 2015, 15:30:19
was für Änderungen soll die 0.16er bringen? :-)
Den Burstmode will ich fertig machen und dann möchte ich den Helligkeitssensor Event-fähig machen.
Also dass der Helligkeitsänderungen mit entsprechendem Schwellwert selbstständig erkennt und dann entsprechende Aktionen auslöst. Ggf. auch mit der Möglichkeit das mit schaltaktoren ö.ä. Pairen zu können. Kann aber sein dass das erst mit einer Version > 0.16 kommt.
Hallo Dirk,
ich überlege mir gerade, ob es möglich ist, einen UV Sensor https://www.dfrobot.com/wiki/index.php?title=UV_sensor_SKU:_SEN0162 mit einzubauen. Die Pins 10 bzw. 11 vom Atmega328P liegen ja (wenn ich mich nicht verschaut habe) auf der Pinleiste.
Hattest Du Dir schon Gedanken gemacht, ob Du in die Firmware auch Analogsensoren integrierst? Wenn nicht, versuche ich erst mal mit PanStamp zu testen ... :)
Gruß und schönes Wochenende.
PeMue
ZitatDen Burstmode will ich fertig machen
also ferngesteuert pairen, peeren, konfigurieren, updaten. :) :) :)
ZitatAlso dass der Helligkeitsänderungen mit entsprechendem Schwellwert selbstständig erkennt und dann entsprechende Aktionen auslöst. Ggf. auch mit der Möglichkeit das mit schaltaktoren ö.ä. Pairen zu können.
:) :) :)
ZitatKann aber sein dass das erst mit einer Version > 0.16 kommt.
:'(
Zitat von: PeMue am 07 August 2015, 16:31:11
Hallo Dirk,
ich überlege mir gerade, ob es möglich ist, einen UV Sensor https://www.dfrobot.com/wiki/index.php?title=UV_sensor_SKU:_SEN0162 mit einzubauen. Die Pins 10 bzw. 11 vom Atmega328P liegen ja (wenn ich mich nicht verschaut habe) auf der Pinleiste.
Das ist ne schöne Idee.
AD-Ports sollten noch genügend frei sein.
Es braucht dann aber noch einen kleinen Stepup-Wandler 3,3 > 5V. damit das Ganze Stromsparend bleibt könnte man den Sensor mit einem zusätzlichen Pin dann ein- und ausschalten.
Ggf. sollte man noch einen OVP vor den Sensor schalten, damit man die 1V mit der Vollen Auflösung abtasten kann. ansonsten hat man nur 1/3 des Messbereiches.
ZitatHattest Du Dir schon Gedanken gemacht, ob Du in die Firmware auch Analogsensoren integrierst? Wenn nicht, versuche ich erst mal mit PanStamp zu testen ... :)
Firmwaretechnisch sollte das recht einfach zu integrieren sein. Die Batteriespannung wird aktuell auch analog gemessen.
Gruß
Dirk
Zitat von: frank am 07 August 2015, 16:34:51
also ferngesteuert pairen, peeren, konfigurieren, updaten.
Konfigurieren und Peeren funktioniert auch mit lazy config. Das hab ich aber auch noch nicht implementiert.
Updaten, mal schauen. Das halte ich aus Sicherheitsgründen immer noch für zumindest unschön, solange das entsprechende Device kein AES unterstützt.
Und der Platz für AES könnte schon recht knapp sein. Mal sehen.
Burst hatte ich eher dafür gedacht die Sensordaten on demand zu holen.
Gruß
Dirk
hallo dirk,
hoffentlich gut erholt und bis in die fingerspitzen motiviert. ;)
ZitatUpdaten, mal schauen. Das halte ich aus Sicherheitsgründen immer noch für zumindest unschön, solange das entsprechende Device kein AES unterstützt.
um soetwas abzusichern habe ich mir für die fw des sw1pbu folgendes kleine bootmenü überlegt, das mit dem configtaster zu bedienen ist. siehe: http://forum.fhem.de/index.php/topic,18071.msg275891.html#msg275891 (http://forum.fhem.de/index.php/topic,18071.msg275891.html#msg275891).
grundgedanke ist, dass ein remote update ausschliesslich durch eine manuelle konfiguration am device freigeschaltet werden kann. default ist die funktion abgeschaltet. also wer hier manuell konfiguriert, weiss was er tut. und versehentlich dürfte man die option wahrscheinlich auch sehr schlecht freischalten können. das flag müsste natürlich noch im eeprom gespeichert werden. unklar war mir dann auch wie man in der asksin lib register in fhem anzeigen kann, aber nicht ändern, um zu sehen wie der aktuelle zustand des flag ausschaut.
gruss frank
Hallo Dirk,
leider kein Erfolg, habe jetzt auf beiden Sensoren 0.15 drauf, habe auch viel herumgespielt, Sensoren resetten, löschen, mit autocreaten neu anlegen, pairen usw., kein Erfolg. Nach wie vor keine Helligkeitswerte mehr.
Gruß
Karl
Sent from my iPhone using Tapatalk
Hej Dirk,
habe jetzt einmal ein paar Sensoren mit der neuen Version versorgt und bislang läuft alles problemlos (ca. 2 Stunden).
Werde es weiter beobachten und morgen am Abend wieder berichten! :-)
Nachdem Thorsten es gestern schon erwähnt hat und es mir vorhin nach einem Update auch wieder aufgefallen ist:
Wäre super, wenn in der v0.16 nur Messdaten gesendet werden, solange batVoltage >= lowBatLimitTHPL ist. Danach sollte mMn nur noch die aktuelle batVoltage und battery:low übermittelt werden.
Zitat von: schka17 am 07 August 2015, 19:45:39
leider kein Erfolg, habe jetzt auf beiden Sensoren 0.15 drauf, habe auch viel herumgespielt, Sensoren resetten, löschen, mit autocreaten neu anlegen, pairen usw., kein Erfolg.
Hm, das ist merkwürdig. Vor allem das es 2 Sensoren gleichzeitig betrifft.
Es gab in den Versionen > 0.12 zwar eine Hardware-bezogene Änderung bzgl. des Helligkeitssensors. Allerdings würde der Sensor dann nicht mehr starten, wenn das bei dir relevant währ.
ZitatHabe auch versucht die Rohdaten aufzuzeichnen, kann damit aber nichts anfangen:
Könntest du die Rohdaten nochmal aufzeichnen, dazu bitte noch die interpretierten Daten von FHEM damit ich das verifizieren kann.
Evtl. kannst du mir ja auch mal die Debugmeldungen vom Sensor über die serielle Schnittstelle schicken. Mit der 0.15er Version sollte da genügend drinn stehen.
Darüber können wir sicher feststellen ob es an der Hardware liegt.
Zitat von: Mr. P am 08 August 2015, 01:54:23
habe jetzt einmal ein paar Sensoren mit der neuen Version versorgt und bislang läuft alles problemlos (ca. 2 Stunden).
Ich bin schon gespannt.
Zitat
Wäre super, wenn in der v0.16 nur Messdaten gesendet werden, solange batVoltage >= lowBatLimitTHPL ist. Danach sollte mMn nur noch die aktuelle batVoltage und
Das muss ich mir nochmal genau ansehen. Ich hatte diese Phänomen hier noch nicht. Mal sehen ob ich das reproduziert bekomme.
Gruß
Dirk
Zitat von: Dirk am 09 August 2015, 10:07:32
Ich bin schon gespannt.
Na dann will ich dich mal nicht länger auf die Folter spannen.
Ich hab jetzt einmal die Temperaturwerte aus beiden Logfiles (einmal THPL und einmal RT) extrahiert und gemeinsam anzeigen lassen. Das Ergebnis stimmt mich zufrieden und ich denke, dir geht es ebenso. :-)
2015-08-08_00:00:29 thpl 29.4
2015-08-08_00:01:28 rt-dn 29.4
2015-08-08_00:03:50 thpl 29.4
2015-08-08_00:04:05 rt-dn 29.4
2015-08-08_00:06:28 rt-dn 29.4
2015-08-08_00:06:55 thpl 29.4
2015-08-08_00:08:36 rt-dn 29.4
2015-08-08_00:09:44 thpl 29.4
2015-08-08_00:11:34 rt-dn 29.4
2015-08-08_00:12:17 thpl 29.3
2015-08-08_00:14:17 rt-dn 29.3
2015-08-08_00:14:33 thpl 29.3
2015-08-08_00:16:46 rt-dn 29.3
2015-08-08_00:17:46 thpl 29.3
2015-08-08_00:19:01 rt-dn 29.3
2015-08-08_00:20:42 thpl 29.3
2015-08-08_00:21:01 rt-dn 29.3
2015-08-08_00:23:22 thpl 29.3
2015-08-08_00:23:51 rt-dn 29.3
2015-08-08_00:25:45 thpl 29.3
2015-08-08_00:26:26 rt-dn 29.3
2015-08-08_00:28:47 rt-dn 29.3
2015-08-08_00:29:05 thpl 29.3
2015-08-08_00:30:54 rt-dn 29.3
2015-08-08_00:32:08 thpl 29.4
2015-08-08_00:33:50 rt-dn 29.4
2015-08-08_00:34:55 thpl 29.4
2015-08-08_00:36:31 rt-dn 29.4
2015-08-08_00:37:26 thpl 29.3
2015-08-08_00:38:58 rt-dn 29.3
2015-08-08_00:40:53 thpl 29.3
2015-08-08_00:41:11 rt-dn 29.3
2015-08-08_00:44:02 thpl 29.3
2015-08-08_00:44:13 rt-dn 29.3
2015-08-08_00:46:57 thpl 29.3
2015-08-08_00:47:01 rt-dn 29.3
2015-08-08_00:49:34 thpl 29.3
2015-08-08_00:49:35 rt-dn 29.3
2015-08-08_00:51:56 thpl 29.3
2015-08-08_00:53:59 rt-dn 29.3
2015-08-08_00:55:13 thpl 29.3
2015-08-08_00:56:53 rt-dn 29.3
2015-08-08_00:58:14 thpl 29.3
2015-08-08_00:59:33 rt-dn 29.3
2015-08-08_01:00:59 thpl 29.3
2015-08-08_01:01:58 rt-dn 29.3
2015-08-08_01:03:28 thpl 29.3
2015-08-08_01:04:09 rt-dn 29.3
2015-08-08_01:06:53 thpl 29.3
2015-08-08_01:07:10 rt-dn 29.3
2015-08-08_01:09:56 rt-dn 29.3
2015-08-08_01:10:01 thpl 29.3
2015-08-08_01:12:27 rt-dn 29.3
2015-08-08_01:12:53 thpl 29.4
2015-08-08_01:15:28 thpl 29.3
2015-08-08_01:16:47 rt-dn 29.3
2015-08-08_01:17:48 thpl 29.3
2015-08-08_01:19:40 rt-dn 29.3
2015-08-08_01:21:03 thpl 29.3
2015-08-08_01:22:18 rt-dn 29.3
2015-08-08_01:24:02 thpl 29.3
2015-08-08_01:24:41 rt-dn 29.3
2015-08-08_01:26:51 rt-dn 29.3
2015-08-08_01:29:12 thpl 29.3
2015-08-08_01:29:49 rt-dn 29.3
2015-08-08_01:32:34 rt-dn 29.3
2015-08-08_01:32:34 thpl 29.3
2015-08-08_01:35:03 rt-dn 29.3
2015-08-08_01:35:41 thpl 29.3
2015-08-08_01:37:19 rt-dn 29.3
2015-08-08_01:38:30 thpl 29.2
2015-08-08_01:39:20 rt-dn 29.2
2015-08-08_01:41:04 thpl 29.3
2015-08-08_01:42:10 rt-dn 29.3
2015-08-08_01:43:22 thpl 29.3
2015-08-08_01:44:47 rt-dn 29.3
2015-08-08_01:46:35 thpl 29.3
2015-08-08_01:47:08 rt-dn 29.3
2015-08-08_01:49:16 rt-dn 29.3
2015-08-08_01:49:32 thpl 29.3
2015-08-08_01:52:13 rt-dn 29.3
2015-08-08_01:52:13 thpl 29.3
2015-08-08_01:54:37 thpl 29.3
2015-08-08_01:54:55 rt-dn 29.3
2015-08-08_01:57:23 rt-dn 29.3
2015-08-08_01:57:58 thpl 29.3
2015-08-08_01:59:37 rt-dn 29.3
2015-08-08_02:01:02 thpl 29.3
2015-08-08_02:02:40 rt-dn 29.3
2015-08-08_02:03:50 thpl 29.3
2015-08-08_02:05:29 rt-dn 29.3
2015-08-08_02:06:21 thpl 29.2
2015-08-08_02:08:03 rt-dn 29.2
2015-08-08_02:09:49 thpl 29.2
2015-08-08_02:10:23 rt-dn 29.2
2015-08-08_02:12:29 rt-dn 29.2
2015-08-08_02:13:00 thpl 29.2
2015-08-08_02:15:24 rt-dn 29.2
2015-08-08_02:15:55 thpl 29.3
2015-08-08_02:18:04 rt-dn 29.3
2015-08-08_02:18:34 thpl 29.3
2015-08-08_02:20:31 rt-dn 29.3
2015-08-08_02:20:56 thpl 29.3
2015-08-08_02:22:42 rt-dn 29.3
2015-08-08_02:24:15 thpl 29.2
2015-08-08_02:25:44 rt-dn 29.2
2015-08-08_02:27:17 thpl 29.2
2015-08-08_02:28:31 rt-dn 29.2
2015-08-08_02:30:03 thpl 29.2
2015-08-08_02:31:03 rt-dn 29.2
2015-08-08_02:32:32 thpl 29.2
2015-08-08_02:33:22 rt-dn 29.2
2015-08-08_02:35:25 rt-dn 29.2
2015-08-08_02:35:58 thpl 29.2
2015-08-08_02:38:19 rt-dn 29.2
2015-08-08_02:39:07 thpl 29.2
2015-08-08_02:40:57 rt-dn 29.2
2015-08-08_02:42:00 thpl 29.2
2015-08-08_02:43:22 rt-dn 29.2
2015-08-08_02:44:37 thpl 29.2
2015-08-08_02:45:32 rt-dn 29.2
2015-08-08_02:46:57 thpl 29.2
2015-08-08_02:48:31 rt-dn 29.2
2015-08-08_02:50:14 thpl 29.2
2015-08-08_02:51:17 rt-dn 29.2
2015-08-08_02:53:14 thpl 29.2
2015-08-08_02:53:47 rt-dn 29.2
2015-08-08_02:55:58 thpl 29.2
2015-08-08_02:56:04 rt-dn 29.2
2015-08-08_02:58:06 rt-dn 29.2
2015-08-08_02:58:25 thpl 29.2
2015-08-08_03:01:49 thpl 29.2
2015-08-08_03:03:34 rt-dn 29.2
2015-08-08_03:04:56 thpl 29.2
2015-08-08_03:05:57 rt-dn 29.2
2015-08-08_03:07:47 thpl 29.2
2015-08-08_03:08:05 rt-dn 29.2
2015-08-08_03:10:21 thpl 29.2
2015-08-08_03:11:03 rt-dn 29.2
2015-08-08_03:12:40 thpl 29.1
2015-08-08_03:13:46 rt-dn 29.1
2015-08-08_03:15:54 thpl 29.2
2015-08-08_03:16:15 rt-dn 29.2
2015-08-08_03:18:30 rt-dn 29.2
2015-08-08_03:18:52 thpl 29.2
2015-08-08_03:20:30 rt-dn 29.2
2015-08-08_03:21:34 thpl 29.1
2015-08-08_03:23:19 rt-dn 29.1
2015-08-08_03:23:59 thpl 29.1
2015-08-08_03:25:55 rt-dn 29.1
2015-08-08_03:27:21 thpl 29.1
2015-08-08_03:28:15 rt-dn 29.1
2015-08-08_03:30:22 rt-dn 29.1
2015-08-08_03:30:26 thpl 29.1
2015-08-08_03:33:15 thpl 29.1
2015-08-08_03:33:18 rt-dn 29.1
2015-08-08_03:35:48 thpl 29.1
2015-08-08_03:35:59 rt-dn 29.1
2015-08-08_03:38:04 thpl 29.1
2015-08-08_03:38:27 rt-dn 29.1
2015-08-08_03:40:39 rt-dn 29.1
2015-08-08_03:41:16 thpl 29.1
2015-08-08_03:43:42 rt-dn 29.1
2015-08-08_03:44:12 thpl 29.1
2015-08-08_03:46:29 rt-dn 29.1
2015-08-08_03:46:52 thpl 29.1
2015-08-08_03:49:03 rt-dn 29.1
2015-08-08_03:49:15 thpl 29.1
2015-08-08_03:51:22 rt-dn 29.1
2015-08-08_03:52:35 thpl 29.1
2015-08-08_03:53:26 rt-dn 29.1
2015-08-08_03:55:38 thpl 29.1
2015-08-08_03:56:21 rt-dn 29.1
2015-08-08_03:58:25 thpl 29.0
2015-08-08_03:59:00 rt-dn 29.0
2015-08-08_04:00:55 thpl 29.1
2015-08-08_04:01:26 rt-dn 29.1
2015-08-08_04:03:37 rt-dn 29.1
2015-08-08_04:04:22 thpl 29.1
2015-08-08_04:06:37 rt-dn 29.1
2015-08-08_04:07:32 thpl 29.0
2015-08-08_04:09:24 rt-dn 29.0
2015-08-08_04:10:26 thpl 29.0
2015-08-08_04:11:55 rt-dn 29.0
2015-08-08_04:13:04 thpl 29.0
2015-08-08_04:14:12 rt-dn 29.0
2015-08-08_04:15:25 thpl 29.0
2015-08-08_04:16:15 rt-dn 29.0
2015-08-08_04:18:42 thpl 29.0
2015-08-08_04:19:07 rt-dn 29.0
2015-08-08_04:21:43 thpl 29.0
2015-08-08_04:21:45 rt-dn 29.0
2015-08-08_04:24:08 rt-dn 29.0
2015-08-08_04:24:28 thpl 29.0
2015-08-08_04:26:17 rt-dn 29.0
2015-08-08_04:26:57 thpl 29.0
2015-08-08_04:29:16 rt-dn 29.0
2015-08-08_04:30:21 thpl 29.0
2015-08-08_04:32:00 rt-dn 29.0
2015-08-08_04:33:30 thpl 29.0
2015-08-08_04:34:30 rt-dn 29.0
2015-08-08_04:36:21 thpl 29.0
2015-08-08_04:36:46 rt-dn 29.0
2015-08-08_04:38:47 rt-dn 29.0
2015-08-08_04:38:57 thpl 29.0
2015-08-08_04:41:17 thpl 29.0
2015-08-08_04:41:37 rt-dn 29.0
2015-08-08_04:44:13 rt-dn 29.0
2015-08-08_04:44:32 thpl 29.0
2015-08-08_04:46:35 rt-dn 29.0
2015-08-08_04:47:31 thpl 29.0
2015-08-08_04:48:42 rt-dn 29.0
2015-08-08_04:50:14 thpl 29.0
2015-08-08_04:51:39 rt-dn 29.0
2015-08-08_04:52:40 thpl 29.0
2015-08-08_04:54:21 rt-dn 29.0
2015-08-08_04:56:02 thpl 29.0
2015-08-08_04:56:49 rt-dn 29.0
2015-08-08_04:59:03 rt-dn 29.0
2015-08-08_04:59:09 thpl 29.0
2015-08-08_05:01:58 thpl 29.0
2015-08-08_05:02:06 rt-dn 29.0
2015-08-08_05:04:32 thpl 29.0
2015-08-08_05:04:55 rt-dn 29.0
2015-08-08_05:06:49 thpl 28.9
2015-08-08_05:07:29 rt-dn 28.9
2015-08-08_05:09:49 rt-dn 28.9
2015-08-08_05:10:03 thpl 29.0
2015-08-08_05:11:55 rt-dn 29.0
2015-08-08_05:13:00 thpl 29.0
2015-08-08_05:14:50 rt-dn 29.0
2015-08-08_05:15:40 thpl 29.0
2015-08-08_05:17:30 rt-dn 29.0
2015-08-08_05:18:05 thpl 29.0
2015-08-08_05:19:56 rt-dn 29.0
2015-08-08_05:21:25 thpl 29.0
2015-08-08_05:22:08 rt-dn 29.0
2015-08-08_05:24:29 thpl 29.0
2015-08-08_05:25:10 rt-dn 29.0
2015-08-08_05:27:17 thpl 29.0
2015-08-08_05:27:56 rt-dn 29.0
2015-08-08_05:29:48 thpl 28.9
2015-08-08_05:30:29 rt-dn 28.9
2015-08-08_05:32:47 rt-dn 28.9
2015-08-08_05:33:16 thpl 28.9
2015-08-08_05:34:51 rt-dn 28.9
2015-08-08_05:36:27 thpl 28.9
2015-08-08_05:37:44 rt-dn 28.9
2015-08-08_05:39:22 thpl 29.0
2015-08-08_05:40:23 rt-dn 29.0
2015-08-08_05:42:01 thpl 28.9
2015-08-08_05:42:47 rt-dn 28.9
2015-08-08_05:44:23 thpl 28.9
2015-08-08_05:44:57 rt-dn 28.9
2015-08-08_05:47:42 thpl 29.0
2015-08-08_05:47:57 rt-dn 29.0
2015-08-08_05:50:42 rt-dn 29.0
2015-08-08_05:50:44 thpl 29.0
2015-08-08_05:53:12 rt-dn 29.0
2015-08-08_05:53:29 thpl 28.9
2015-08-08_05:55:14 rt-dn 28.9
2015-08-08_05:55:59 thpl 28.9
2015-08-08_05:57:16 rt-dn 28.9
2015-08-08_05:59:24 thpl 29.0
2015-08-08_06:00:07 rt-dn 29.0
2015-08-08_06:02:33 thpl 29.0
2015-08-08_06:02:44 rt-dn 29.0
2015-08-08_06:05:07 rt-dn 29.0
2015-08-08_06:05:26 thpl 29.0
2015-08-08_06:07:15 rt-dn 29.0
2015-08-08_06:08:03 thpl 29.0
2015-08-08_06:10:13 rt-dn 29.0
2015-08-08_06:10:23 thpl 28.9
2015-08-08_06:12:56 rt-dn 28.9
2015-08-08_06:13:40 thpl 29.0
2015-08-08_06:15:25 rt-dn 29.0
2015-08-08_06:16:40 thpl 28.9
2015-08-08_06:17:40 rt-dn 28.9
2015-08-08_06:19:23 thpl 28.9
2015-08-08_06:19:39 rt-dn 28.9
2015-08-08_06:21:51 thpl 28.9
2015-08-08_06:22:29 rt-dn 28.9
2015-08-08_06:25:04 rt-dn 28.9
2015-08-08_06:25:14 thpl 28.9
2015-08-08_06:27:25 rt-dn 28.9
2015-08-08_06:28:21 thpl 29.0
2015-08-08_06:29:31 rt-dn 29.0
2015-08-08_06:31:12 thpl 28.9
2015-08-08_06:32:27 rt-dn 28.9
2015-08-08_06:33:47 thpl 28.9
2015-08-08_06:35:08 rt-dn 28.9
2015-08-08_06:36:05 thpl 28.9
2015-08-08_06:37:35 rt-dn 28.9
2015-08-08_06:39:19 thpl 28.9
2015-08-08_06:39:48 rt-dn 28.9
2015-08-08_06:42:17 thpl 28.8
2015-08-08_06:42:50 rt-dn 28.8
2015-08-08_06:44:59 thpl 28.9
2015-08-08_06:45:38 rt-dn 28.9
2015-08-08_06:47:24 thpl 28.9
2015-08-08_06:48:11 rt-dn 28.9
2015-08-08_06:50:30 rt-dn 28.9
2015-08-08_06:50:45 thpl 28.9
2015-08-08_06:52:35 rt-dn 28.9
2015-08-08_06:53:50 thpl 28.9
2015-08-08_06:55:29 rt-dn 28.9
2015-08-08_06:56:40 thpl 28.9
2015-08-08_06:58:09 rt-dn 28.9
2015-08-08_06:59:11 thpl 28.9
2015-08-08_07:00:34 rt-dn 28.9
2015-08-08_07:01:28 thpl 29.0
2015-08-08_07:02:45 rt-dn 29.0
2015-08-08_07:04:39 thpl 28.9
2015-08-08_07:05:45 rt-dn 28.9
2015-08-08_07:07:35 thpl 28.9
2015-08-08_07:08:31 rt-dn 28.9
2015-08-08_07:10:15 thpl 28.9
2015-08-08_07:11:03 rt-dn 28.9
2015-08-08_07:12:38 thpl 28.9
2015-08-08_07:13:20 rt-dn 28.9
2015-08-08_07:15:23 rt-dn 28.9
2015-08-08_07:15:57 thpl 29.0
2015-08-08_07:18:15 rt-dn 29.0
2015-08-08_07:19:00 thpl 29.0
2015-08-08_07:20:53 rt-dn 29.0
2015-08-08_07:21:46 thpl 29.0
2015-08-08_07:23:16 rt-dn 29.0
2015-08-08_07:24:17 thpl 29.0
2015-08-08_07:25:25 rt-dn 29.0
2015-08-08_07:27:43 thpl 28.9
2015-08-08_07:28:23 rt-dn 28.9
2015-08-08_07:30:53 thpl 29.0
2015-08-08_07:31:08 rt-dn 29.0
2015-08-08_07:33:38 rt-dn 29.0
2015-08-08_07:33:47 thpl 29.0
2015-08-08_07:35:53 rt-dn 29.0
2015-08-08_07:36:25 thpl 29.0
2015-08-08_07:37:54 rt-dn 29.0
2015-08-08_07:38:46 thpl 28.9
2015-08-08_07:40:44 rt-dn 28.9
2015-08-08_07:42:03 thpl 29.0
2015-08-08_07:43:20 rt-dn 29.0
2015-08-08_07:45:04 thpl 28.9
2015-08-08_07:45:42 rt-dn 28.9
2015-08-08_07:47:49 rt-dn 29.0
2015-08-08_07:47:49 thpl 29.0
2015-08-08_07:50:17 thpl 29.0
2015-08-08_07:50:46 rt-dn 29.0
2015-08-08_07:53:09 rt-dn 29.0
2015-08-08_07:53:42 thpl 29.0
2015-08-08_07:55:17 rt-dn 29.0
2015-08-08_07:56:50 thpl 29.0
2015-08-08_07:59:20 thpl 29.0
2015-08-08_08:00:58 rt-dn 29.0
2015-08-08_08:02:45 thpl 29.0
2015-08-08_08:03:27 rt-dn 29.0
2015-08-08_08:05:42 rt-dn 29.0
2015-08-08_08:05:55 thpl 29.0
2015-08-08_08:07:42 rt-dn 29.0
2015-08-08_08:08:48 thpl 29.0
2015-08-08_08:10:32 rt-dn 29.0
2015-08-08_08:11:25 thpl 29.0
2015-08-08_08:13:07 rt-dn 29.0
2015-08-08_08:13:45 thpl 29.0
2015-08-08_08:15:28 rt-dn 29.0
2015-08-08_08:17:02 thpl 29.0
2015-08-08_08:17:35 rt-dn 29.0
2015-08-08_08:20:02 thpl 29.0
2015-08-08_08:20:31 rt-dn 29.0
2015-08-08_08:22:46 thpl 29.0
2015-08-08_08:23:13 rt-dn 29.0
2015-08-08_08:25:13 thpl 29.0
2015-08-08_08:25:40 rt-dn 29.0
2015-08-08_08:27:53 rt-dn 29.0
2015-08-08_08:28:37 thpl 29.0
2015-08-08_08:30:55 rt-dn 29.0
2015-08-08_08:31:45 thpl 29.1
2015-08-08_08:33:43 rt-dn 29.1
2015-08-08_08:34:36 thpl 29.1
2015-08-08_08:36:17 rt-dn 29.1
2015-08-08_08:37:11 thpl 29.2
2015-08-08_08:38:36 rt-dn 29.2
2015-08-08_08:39:29 thpl 29.3
2015-08-08_08:40:41 rt-dn 29.3
2015-08-08_08:42:43 thpl 29.2
2015-08-08_08:43:35 rt-dn 29.2
2015-08-08_08:45:41 thpl 29.2
2015-08-08_08:46:15 rt-dn 29.2
2015-08-08_08:48:23 thpl 29.1
2015-08-08_08:48:40 rt-dn 29.1
2015-08-08_08:50:49 thpl 29.1
2015-08-08_08:50:51 rt-dn 29.1
2015-08-08_08:53:52 rt-dn 29.1
2015-08-08_08:54:10 thpl 29.1
2015-08-08_08:56:38 rt-dn 29.1
2015-08-08_08:57:16 thpl 29.1
2015-08-08_08:59:10 rt-dn 29.1
2015-08-08_09:00:05 thpl 29.1
2015-08-08_09:01:27 rt-dn 29.1
2015-08-08_09:02:37 thpl 29.1
2015-08-08_09:03:30 rt-dn 29.1
2015-08-08_09:04:54 thpl 29.1
2015-08-08_09:06:23 rt-dn 29.1
2015-08-08_09:06:34 rt-dn 29.1
2015-08-08_09:08:07 thpl 29.1
2015-08-08_09:08:57 rt-dn 29.1
2015-08-08_09:11:03 thpl 29.0
2015-08-08_09:11:07 rt-dn 29.0
2015-08-08_09:13:42 thpl 29.1
2015-08-08_09:14:05 rt-dn 29.1
2015-08-08_09:16:06 thpl 29.1
2015-08-08_09:16:50 rt-dn 29.1
2015-08-08_09:19:20 rt-dn 29.1
2015-08-08_09:19:25 thpl 29.1
2015-08-08_09:21:35 rt-dn 29.1
2015-08-08_09:22:29 thpl 29.1
2015-08-08_09:23:36 rt-dn 29.1
2015-08-08_09:25:16 thpl 29.0
2015-08-08_09:26:27 rt-dn 29.0
2015-08-08_09:27:46 thpl 29.1
2015-08-08_09:29:03 rt-dn 29.1
2015-08-08_09:31:13 thpl 29.1
2015-08-08_09:31:25 rt-dn 29.1
2015-08-08_09:33:32 rt-dn 29.1
2015-08-08_09:34:24 thpl 29.1
2015-08-08_09:36:29 rt-dn 29.1
2015-08-08_09:37:18 thpl 29.1
2015-08-08_09:39:12 rt-dn 29.1
2015-08-08_09:39:55 thpl 29.1
2015-08-08_09:41:41 rt-dn 29.1
2015-08-08_09:42:17 thpl 29.1
2015-08-08_09:43:54 rt-dn 29.1
2015-08-08_09:45:35 thpl 29.1
2015-08-08_09:46:57 rt-dn 29.1
2015-08-08_09:48:36 thpl 29.1
2015-08-08_09:49:46 rt-dn 29.1
2015-08-08_09:51:21 thpl 29.1
2015-08-08_09:52:20 rt-dn 29.1
2015-08-08_09:53:49 thpl 29.1
2015-08-08_09:54:40 rt-dn 29.1
2015-08-08_09:56:46 rt-dn 29.1
2015-08-08_09:57:14 thpl 29.1
2015-08-08_09:59:41 rt-dn 29.1
2015-08-08_10:00:22 thpl 29.1
2015-08-08_10:02:22 rt-dn 29.1
2015-08-08_10:03:14 thpl 29.1
2015-08-08_10:04:48 rt-dn 29.1
2015-08-08_10:05:50 thpl 29.1
2015-08-08_10:07:00 rt-dn 29.1
2015-08-08_10:08:09 thpl 29.1
2015-08-08_10:10:01 rt-dn 29.1
2015-08-08_10:11:25 thpl 29.1
2015-08-08_10:14:24 thpl 29.1
2015-08-08_10:15:21 rt-dn 29.1
2015-08-08_10:17:07 thpl 29.1
2015-08-08_10:17:39 rt-dn 29.1
2015-08-08_10:19:34 thpl 29.1
2015-08-08_10:19:43 rt-dn 29.1
2015-08-08_10:22:36 rt-dn 29.1
2015-08-08_10:22:56 thpl 29.1
2015-08-08_10:25:15 rt-dn 29.1
2015-08-08_10:26:03 thpl 29.2
2015-08-08_10:27:40 rt-dn 29.2
2015-08-08_10:28:53 thpl 29.2
2015-08-08_10:31:26 thpl 29.2
2015-08-08_10:32:50 rt-dn 29.2
2015-08-08_10:33:01 rt-dn 29.2
2015-08-08_10:33:44 thpl 29.2
2015-08-08_10:35:31 rt-dn 29.2
2015-08-08_10:36:57 thpl 29.2
2015-08-08_10:37:48 rt-dn 29.2
2015-08-08_10:39:50 rt-dn 29.2
2015-08-08_10:39:54 thpl 29.2
2015-08-08_10:40:01 rt-dn 29.2
2015-08-08_10:42:35 thpl 29.2
2015-08-08_10:42:38 rt-dn 29.2
2015-08-08_10:45:00 thpl 29.2
2015-08-08_10:45:01 rt-dn 29.2
2015-08-08_10:47:09 rt-dn 29.2
2015-08-08_10:48:20 thpl 29.1
2015-08-08_10:50:07 rt-dn 29.1
2015-08-08_10:51:25 thpl 29.1
2015-08-08_10:52:50 rt-dn 29.1
2015-08-08_10:54:13 thpl 29.1
2015-08-08_10:55:19 rt-dn 29.1
2015-08-08_10:56:44 thpl 29.0
2015-08-08_10:57:34 rt-dn 29.0
2015-08-08_10:59:34 rt-dn 29.0
2015-08-08_11:00:12 thpl 29.0
2015-08-08_11:02:24 rt-dn 29.0
2015-08-08_11:03:23 thpl 29.1
2015-08-08_11:04:59 rt-dn 29.1
2015-08-08_11:06:18 thpl 29.1
2015-08-08_11:07:20 rt-dn 29.1
2015-08-08_11:08:57 thpl 29.0
2015-08-08_11:09:27 rt-dn 29.0
2015-08-08_11:11:20 thpl 29.0
2015-08-08_11:12:23 rt-dn 29.0
2015-08-08_11:14:38 thpl 29.0
2015-08-08_11:15:04 rt-dn 29.0
2015-08-08_11:17:31 rt-dn 29.0
2015-08-08_11:17:41 thpl 29.0
2015-08-08_11:19:44 rt-dn 29.0
2015-08-08_11:20:26 thpl 29.0
2015-08-08_11:22:46 rt-dn 29.0
2015-08-08_11:22:56 thpl 29.0
2015-08-08_11:25:34 rt-dn 29.0
2015-08-08_11:26:22 thpl 29.0
2015-08-08_11:28:08 rt-dn 29.0
2015-08-08_11:29:31 thpl 29.0
2015-08-08_11:30:27 rt-dn 29.0
2015-08-08_11:32:24 thpl 29.0
2015-08-08_11:32:32 rt-dn 29.0
2015-08-08_11:35:01 thpl 29.0
2015-08-08_11:35:26 rt-dn 29.0
2015-08-08_11:37:21 thpl 29.0
2015-08-08_11:38:06 rt-dn 29.0
2015-08-08_11:40:31 rt-dn 29.0
2015-08-08_11:40:38 thpl 29.0
2015-08-08_11:42:42 rt-dn 29.0
2015-08-08_11:43:38 thpl 29.0
2015-08-08_11:45:43 rt-dn 29.0
2015-08-08_11:46:22 thpl 29.0
2015-08-08_11:48:29 rt-dn 29.0
2015-08-08_11:48:49 thpl 28.9
2015-08-08_11:51:00 rt-dn 28.9
2015-08-08_11:52:13 thpl 28.9
2015-08-08_11:53:18 rt-dn 28.9
2015-08-08_11:55:20 rt-dn 28.9
2015-08-08_11:55:20 thpl 28.9
2015-08-08_11:58:12 thpl 28.8
2015-08-08_11:58:13 rt-dn 28.8
2015-08-08_12:00:46 thpl 28.9
2015-08-08_12:03:04 thpl 28.9
2015-08-08_12:03:14 rt-dn 28.9
2015-08-08_12:05:24 rt-dn 28.9
2015-08-08_12:06:19 thpl 28.9
2015-08-08_12:08:22 rt-dn 28.9
2015-08-08_12:09:17 thpl 28.9
2015-08-08_12:11:07 rt-dn 28.9
2015-08-08_12:11:58 thpl 28.9
2015-08-08_12:13:36 rt-dn 28.9
2015-08-08_12:14:24 thpl 28.9
2015-08-08_12:15:52 rt-dn 28.9
2015-08-08_12:17:46 thpl 28.9
2015-08-08_12:17:53 rt-dn 28.9
2015-08-08_12:20:51 thpl 28.9
2015-08-08_12:23:20 rt-dn 28.9
2015-08-08_12:23:40 thpl 28.9
2015-08-08_12:25:41 rt-dn 28.9
2015-08-08_12:26:12 thpl 28.8
2015-08-08_12:27:49 rt-dn 28.8
2015-08-08_12:28:29 thpl 28.9
2015-08-08_12:30:46 rt-dn 28.9
2015-08-08_12:31:41 thpl 28.9
2015-08-08_12:33:28 rt-dn 28.9
2015-08-08_12:34:37 thpl 28.9
2015-08-08_12:35:56 rt-dn 28.9
2015-08-08_12:37:17 thpl 28.9
2015-08-08_12:38:10 rt-dn 28.9
2015-08-08_12:39:40 thpl 28.9
2015-08-08_12:41:13 rt-dn 28.9
2015-08-08_12:43:00 thpl 28.8
2015-08-08_12:44:02 rt-dn 28.8
2015-08-08_12:46:03 thpl 28.8
2015-08-08_12:46:36 rt-dn 28.8
2015-08-08_12:48:50 thpl 28.9
2015-08-08_12:48:56 rt-dn 28.9
2015-08-08_12:51:02 rt-dn 28.9
2015-08-08_12:51:21 thpl 28.8
2015-08-08_12:53:57 rt-dn 28.8
2015-08-08_12:54:47 thpl 28.9
2015-08-08_12:56:37 rt-dn 28.9
2015-08-08_12:57:57 thpl 28.9
2015-08-08_12:59:04 rt-dn 28.9
2015-08-08_13:00:52 thpl 28.9
2015-08-08_13:03:29 thpl 28.9
2015-08-08_13:04:17 rt-dn 28.9
2015-08-08_13:05:51 thpl 28.8
2015-08-08_13:07:04 rt-dn 28.8
2015-08-08_13:09:08 thpl 28.8
2015-08-08_13:09:36 rt-dn 28.8
2015-08-08_13:11:55 rt-dn 28.8
2015-08-08_13:12:09 thpl 28.8
2015-08-08_13:13:58 rt-dn 28.8
2015-08-08_13:14:54 thpl 28.8
2015-08-08_13:16:52 rt-dn 28.8
2015-08-08_13:17:23 thpl 28.8
2015-08-08_13:19:30 rt-dn 28.8
2015-08-08_13:20:47 thpl 28.8
2015-08-08_13:21:55 rt-dn 28.8
2015-08-08_13:23:56 thpl 28.8
2015-08-08_13:24:05 rt-dn 28.8
2015-08-08_13:26:47 thpl 28.8
2015-08-08_13:27:04 rt-dn 28.8
2015-08-08_13:29:23 thpl 28.8
2015-08-08_13:29:50 rt-dn 28.8
2015-08-08_13:31:43 thpl 28.8
2015-08-08_13:32:20 rt-dn 28.8
2015-08-08_13:34:37 rt-dn 28.8
2015-08-08_13:34:58 thpl 28.8
2015-08-08_13:36:39 rt-dn 28.8
2015-08-08_13:37:57 thpl 28.8
2015-08-08_13:39:30 rt-dn 28.8
2015-08-08_13:40:40 thpl 28.8
2015-08-08_13:42:07 rt-dn 28.8
2015-08-08_13:43:06 thpl 28.8
2015-08-08_13:44:30 rt-dn 28.8
2015-08-08_13:46:29 thpl 28.8
2015-08-08_13:46:38 rt-dn 28.8
2015-08-08_13:49:35 thpl 28.8
2015-08-08_13:49:36 rt-dn 28.8
2015-08-08_13:52:19 rt-dn 28.8
2015-08-08_13:52:25 thpl 28.8
2015-08-08_13:54:48 rt-dn 28.8
2015-08-08_13:54:59 thpl 28.8
2015-08-08_13:57:03 rt-dn 28.8
2015-08-08_13:57:16 thpl 28.8
2015-08-08_13:59:03 rt-dn 28.8
2015-08-08_14:00:29 thpl 28.8
2015-08-08_14:03:27 thpl 28.8
2015-08-08_14:04:28 rt-dn 28.8
2015-08-08_14:06:07 thpl 28.8
2015-08-08_14:06:48 rt-dn 28.8
2015-08-08_14:08:32 thpl 28.8
2015-08-08_14:08:55 rt-dn 28.8
2015-08-08_14:11:51 rt-dn 28.8
2015-08-08_14:11:52 thpl 28.8
2015-08-08_14:14:32 rt-dn 28.8
2015-08-08_14:14:56 thpl 28.8
2015-08-08_14:17:00 rt-dn 28.8
2015-08-08_14:17:44 thpl 28.7
2015-08-08_14:19:12 rt-dn 28.7
2015-08-08_14:20:16 thpl 28.8
2015-08-08_14:22:15 rt-dn 28.8
2015-08-08_14:23:43 thpl 28.8
2015-08-08_14:25:02 rt-dn 28.8
2015-08-08_14:26:55 thpl 28.8
2015-08-08_14:27:36 rt-dn 28.8
2015-08-08_14:29:50 thpl 28.8
2015-08-08_14:29:55 rt-dn 28.8
2015-08-08_14:31:59 rt-dn 28.8
2015-08-08_14:32:28 thpl 28.7
2015-08-08_14:34:51 thpl 28.8
2015-08-08_14:34:54 rt-dn 28.8
2015-08-08_14:37:33 rt-dn 28.8
2015-08-08_14:38:09 thpl 28.7
2015-08-08_14:39:59 rt-dn 28.7
2015-08-08_14:42:10 rt-dn 28.7
2015-08-08_14:43:57 thpl 28.7
2015-08-08_14:45:10 rt-dn 28.7
2015-08-08_14:46:26 thpl 28.8
2015-08-08_14:47:56 rt-dn 28.8
2015-08-08_14:49:51 thpl 28.8
2015-08-08_14:50:28 rt-dn 28.8
2015-08-08_14:52:45 rt-dn 28.8
2015-08-08_14:53:00 thpl 28.8
2015-08-08_14:54:48 rt-dn 28.8
2015-08-08_14:55:53 thpl 28.8
2015-08-08_14:57:40 rt-dn 28.8
2015-08-08_14:58:29 thpl 28.8
2015-08-08_15:00:18 rt-dn 28.8
2015-08-08_15:00:50 thpl 28.8
2015-08-08_15:02:42 rt-dn 28.8
2015-08-08_15:04:06 thpl 28.8
2015-08-08_15:04:50 rt-dn 28.8
2015-08-08_15:07:06 thpl 28.8
2015-08-08_15:07:49 rt-dn 28.8
2015-08-08_15:09:49 thpl 28.8
2015-08-08_15:10:33 rt-dn 28.8
2015-08-08_15:12:17 thpl 28.8
2015-08-08_15:13:03 rt-dn 28.8
2015-08-08_15:15:19 rt-dn 28.8
2015-08-08_15:15:40 thpl 28.8
2015-08-08_15:17:20 rt-dn 28.8
2015-08-08_15:18:47 thpl 28.8
2015-08-08_15:20:10 rt-dn 28.8
2015-08-08_15:21:38 thpl 28.8
2015-08-08_15:22:46 rt-dn 28.8
2015-08-08_15:24:12 thpl 28.8
2015-08-08_15:25:08 rt-dn 28.8
2015-08-08_15:26:30 thpl 28.8
2015-08-08_15:27:15 rt-dn 28.8
2015-08-08_15:29:45 thpl 28.9
2015-08-08_15:30:12 rt-dn 28.9
2015-08-08_15:32:43 thpl 28.9
2015-08-08_15:32:54 rt-dn 28.9
2015-08-08_15:35:22 rt-dn 28.9
2015-08-08_15:35:24 thpl 28.8
2015-08-08_15:37:36 rt-dn 28.8
2015-08-08_15:37:50 thpl 28.8
2015-08-08_15:40:39 rt-dn 28.8
2015-08-08_15:41:11 thpl 28.8
2015-08-08_15:43:28 rt-dn 28.8
2015-08-08_15:44:16 thpl 28.8
2015-08-08_15:46:02 rt-dn 28.8
2015-08-08_15:47:05 thpl 28.8
2015-08-08_15:48:22 rt-dn 28.8
2015-08-08_15:49:37 thpl 28.8
2015-08-08_15:50:28 rt-dn 28.8
2015-08-08_15:51:53 thpl 28.8
2015-08-08_15:53:23 rt-dn 28.8
2015-08-08_15:55:05 thpl 28.8
2015-08-08_15:56:03 rt-dn 28.8
2015-08-08_15:58:01 thpl 28.8
2015-08-08_15:58:29 rt-dn 28.8
2015-08-08_16:00:40 thpl 28.8
2015-08-08_16:00:41 rt-dn 28.8
2015-08-08_16:03:04 thpl 28.8
2015-08-08_16:03:42 rt-dn 28.8
2015-08-08_16:06:23 thpl 28.8
2015-08-08_16:06:29 rt-dn 28.8
2015-08-08_16:09:02 rt-dn 28.8
2015-08-08_16:09:26 thpl 28.8
2015-08-08_16:12:13 thpl 28.8
2015-08-08_16:13:24 rt-dn 28.8
2015-08-08_16:14:43 thpl 28.8
2015-08-08_16:16:17 rt-dn 28.8
2015-08-08_16:18:09 thpl 28.8
2015-08-08_16:18:56 rt-dn 28.8
2015-08-08_16:21:20 rt-dn 28.8
2015-08-08_16:21:20 thpl 28.8
2015-08-08_16:23:30 rt-dn 28.8
2015-08-08_16:24:13 thpl 28.8
2015-08-08_16:26:30 rt-dn 28.8
2015-08-08_16:26:51 thpl 28.9
2015-08-08_16:29:12 thpl 28.9
2015-08-08_16:29:15 rt-dn 28.9
2015-08-08_16:31:45 rt-dn 28.9
2015-08-08_16:32:29 thpl 28.9
2015-08-08_16:34:02 rt-dn 28.9
2015-08-08_16:35:30 thpl 28.9
2015-08-08_16:36:03 rt-dn 28.9
2015-08-08_16:38:15 thpl 28.8
2015-08-08_16:38:55 rt-dn 28.8
2015-08-08_16:40:43 thpl 28.9
2015-08-08_16:41:32 rt-dn 28.9
2015-08-08_16:43:54 rt-dn 28.9
2015-08-08_16:44:08 thpl 28.9
2015-08-08_16:46:03 rt-dn 28.9
2015-08-08_16:47:15 thpl 28.9
2015-08-08_16:49:00 rt-dn 28.9
2015-08-08_16:50:07 thpl 28.9
2015-08-08_16:51:44 rt-dn 28.9
2015-08-08_16:52:43 thpl 28.9
2015-08-08_16:54:12 rt-dn 28.9
2015-08-08_16:55:02 thpl 28.9
2015-08-08_16:56:27 rt-dn 28.9
2015-08-08_16:58:17 thpl 28.9
2015-08-08_16:58:27 rt-dn 28.9
2015-08-08_17:01:16 rt-dn 28.9
2015-08-08_17:01:16 thpl 28.9
2015-08-08_17:03:52 rt-dn 28.9
2015-08-08_17:03:59 thpl 28.9
2015-08-08_17:06:12 rt-dn 28.9
2015-08-08_17:06:25 thpl 28.9
2015-08-08_17:08:19 rt-dn 28.9
2015-08-08_17:09:47 thpl 28.8
2015-08-08_17:11:15 rt-dn 28.8
2015-08-08_17:12:53 thpl 28.9
2015-08-08_17:13:56 rt-dn 28.9
2015-08-08_17:16:23 rt-dn 28.9
2015-08-08_17:18:16 thpl 28.9
2015-08-08_17:18:36 rt-dn 28.9
2015-08-08_17:20:33 thpl 28.9
2015-08-08_17:21:38 rt-dn 28.9
2015-08-08_17:23:47 thpl 28.9
2015-08-08_17:24:26 rt-dn 28.9
2015-08-08_17:26:43 thpl 28.9
2015-08-08_17:29:18 rt-dn 28.9
2015-08-08_17:29:24 thpl 28.8
2015-08-08_17:31:23 rt-dn 28.8
2015-08-08_17:31:48 thpl 28.9
2015-08-08_17:34:17 rt-dn 28.9
2015-08-08_17:35:08 thpl 28.9
2015-08-08_17:36:56 rt-dn 28.9
2015-08-08_17:38:12 thpl 28.9
2015-08-08_17:39:22 rt-dn 28.9
2015-08-08_17:41:00 thpl 28.9
2015-08-08_17:41:32 rt-dn 28.9
2015-08-08_17:43:31 thpl 28.9
2015-08-08_17:44:33 rt-dn 28.9
2015-08-08_17:46:59 thpl 28.9
2015-08-08_17:47:19 rt-dn 28.9
2015-08-08_17:49:50 rt-dn 28.9
2015-08-08_17:52:08 rt-dn 28.9
2015-08-08_17:53:04 thpl 28.9
2015-08-08_17:55:43 thpl 28.9
2015-08-08_17:57:03 rt-dn 28.9
2015-08-08_17:58:05 thpl 28.9
2015-08-08_17:59:40 rt-dn 28.9
2015-08-08_18:01:24 thpl 28.9
2015-08-08_18:02:04 rt-dn 28.9
2015-08-08_18:04:14 rt-dn 28.9
2015-08-08_18:04:26 thpl 28.9
2015-08-08_18:07:11 rt-dn 28.9
2015-08-08_18:07:11 thpl 28.9
2015-08-08_18:09:41 thpl 28.9
2015-08-08_18:09:56 rt-dn 28.9
2015-08-08_18:12:25 rt-dn 28.9
2015-08-08_18:13:06 thpl 28.9
2015-08-08_18:14:41 rt-dn 28.9
2015-08-08_18:16:15 thpl 28.9
2015-08-08_18:16:42 rt-dn 28.9
2015-08-08_18:19:08 thpl 29.0
2015-08-08_18:19:32 rt-dn 29.0
2015-08-08_18:21:45 thpl 28.9
2015-08-08_18:22:08 rt-dn 28.9
2015-08-08_18:24:05 thpl 28.9
2015-08-08_18:24:30 rt-dn 28.9
2015-08-08_18:26:37 rt-dn 28.9
2015-08-08_18:27:22 thpl 28.9
2015-08-08_18:29:34 rt-dn 28.9
2015-08-08_18:30:22 thpl 29.0
2015-08-08_18:31:57 rt-dn 29.0
2015-08-08_18:33:05 thpl 29.0
2015-08-08_18:34:05 rt-dn 29.0
2015-08-08_18:35:33 thpl 28.9
2015-08-08_18:37:03 rt-dn 28.9
2015-08-08_18:38:56 thpl 29.0
2015-08-08_18:39:46 rt-dn 29.0
2015-08-08_18:44:54 rt-dn 29.0
2015-08-08_18:44:54 thpl 29.0
2015-08-08_18:44:55 rt-dn 29.0
2015-08-08_18:44:55 thpl 28.9
2015-08-08_18:44:56 rt-dn 29.0
2015-08-08_18:44:56 thpl 29.0
2015-08-08_18:44:58 rt-dn 29.0
2015-08-08_18:44:58 thpl 28.9
2015-08-08_18:46:30 rt-dn 28.9
2015-08-08_18:47:29 thpl 28.9
2015-08-08_18:49:20 rt-dn 28.9
2015-08-08_18:49:47 thpl 28.9
2015-08-08_18:51:55 rt-dn 28.9
2015-08-08_18:53:01 thpl 28.9
2015-08-08_18:54:17 rt-dn 28.9
2015-08-08_18:55:59 thpl 28.9
2015-08-08_18:56:23 rt-dn 28.9
2015-08-08_18:58:41 thpl 28.9
2015-08-08_18:59:19 rt-dn 28.9
2015-08-08_19:01:06 thpl 29.0
2015-08-08_19:02:01 rt-dn 29.0
2015-08-08_19:04:27 thpl 28.9
2015-08-08_19:04:28 rt-dn 28.9
2015-08-08_19:06:41 rt-dn 28.9
2015-08-08_19:07:33 thpl 28.9
2015-08-08_19:09:43 rt-dn 28.9
2015-08-08_19:10:21 thpl 28.9
2015-08-08_19:12:31 rt-dn 28.9
2015-08-08_19:12:54 thpl 28.9
2015-08-08_19:15:05 rt-dn 28.9
2015-08-08_19:15:10 thpl 28.9
2015-08-08_19:17:24 rt-dn 28.9
2015-08-08_19:18:22 thpl 28.9
2015-08-08_19:19:29 rt-dn 28.9
2015-08-08_19:21:18 thpl 28.9
2015-08-08_19:22:23 rt-dn 28.9
2015-08-08_19:23:58 thpl 28.9
2015-08-08_19:25:03 rt-dn 28.9
2015-08-08_19:26:21 thpl 28.9
2015-08-08_19:27:28 rt-dn 28.9
2015-08-08_19:29:39 rt-dn 28.9
2015-08-08_19:29:41 thpl 28.8
2015-08-08_19:32:40 rt-dn 28.8
2015-08-08_19:32:44 thpl 28.8
2015-08-08_19:35:26 rt-dn 28.8
2015-08-08_19:35:30 thpl 28.8
2015-08-08_19:37:58 rt-dn 28.8
2015-08-08_19:38:01 thpl 28.8
2015-08-08_19:40:15 rt-dn 28.8
2015-08-08_19:41:27 thpl 28.8
2015-08-08_19:42:18 rt-dn 28.8
2015-08-08_19:44:38 thpl 28.8
2015-08-08_19:45:10 rt-dn 28.8
2015-08-08_19:47:32 thpl 28.8
2015-08-08_19:47:48 rt-dn 28.8
2015-08-08_19:50:09 thpl 28.8
2015-08-08_19:50:12 rt-dn 28.8
2015-08-08_19:52:21 rt-dn 28.8
2015-08-08_19:52:30 thpl 28.8
2015-08-08_19:55:20 rt-dn 28.8
2015-08-08_19:55:47 thpl 28.8
2015-08-08_19:58:04 rt-dn 28.8
2015-08-08_19:58:48 thpl 28.8
2015-08-08_20:00:34 rt-dn 28.8
2015-08-08_20:01:33 thpl 28.7
2015-08-08_20:02:50 rt-dn 28.7
2015-08-08_20:04:02 thpl 28.8
2015-08-08_20:04:51 rt-dn 28.8
2015-08-08_20:07:26 thpl 28.8
2015-08-08_20:07:42 rt-dn 28.8
2015-08-08_20:10:18 rt-dn 28.8
2015-08-08_20:10:34 thpl 28.8
2015-08-08_20:12:40 rt-dn 28.8
2015-08-08_20:13:04 thpl 28.8
2015-08-08_20:14:47 rt-dn 28.8
2015-08-08_20:16:30 thpl 28.8
2015-08-08_20:17:44 rt-dn 28.8
2015-08-08_20:19:39 thpl 28.8
2015-08-08_20:20:27 rt-dn 28.8
2015-08-08_20:22:32 thpl 28.8
2015-08-08_20:22:55 rt-dn 28.8
2015-08-08_20:25:08 rt-dn 28.8
2015-08-08_20:25:09 thpl 28.7
2015-08-08_20:27:29 thpl 28.8
2015-08-08_20:28:12 rt-dn 28.8
2015-08-08_20:30:46 thpl 28.8
2015-08-08_20:31:00 rt-dn 28.8
2015-08-08_20:33:35 rt-dn 28.8
2015-08-08_20:33:46 thpl 28.8
2015-08-08_20:35:55 rt-dn 28.8
2015-08-08_20:36:30 thpl 28.8
2015-08-08_20:38:00 rt-dn 28.8
2015-08-08_20:38:58 thpl 28.8
2015-08-08_20:40:56 rt-dn 28.8
2015-08-08_20:42:21 thpl 28.8
2015-08-08_20:43:36 rt-dn 28.8
2015-08-08_20:45:29 thpl 28.8
2015-08-08_20:46:03 rt-dn 28.8
2015-08-08_20:48:15 rt-dn 28.8
2015-08-08_20:48:20 thpl 28.8
2015-08-08_20:50:55 thpl 28.8
2015-08-08_20:51:17 rt-dn 28.8
2015-08-08_20:53:13 thpl 28.8
2015-08-08_20:54:03 rt-dn 28.8
2015-08-08_20:56:28 thpl 28.8
2015-08-08_20:56:36 rt-dn 28.8
2015-08-08_20:58:54 rt-dn 28.8
2015-08-08_20:59:26 thpl 28.8
2015-08-08_21:00:58 rt-dn 28.8
2015-08-08_21:02:08 thpl 28.8
2015-08-08_21:03:51 rt-dn 28.8
2015-08-08_21:04:33 thpl 28.8
2015-08-08_21:06:30 rt-dn 28.8
2015-08-08_21:07:55 thpl 28.8
2015-08-08_21:08:54 rt-dn 28.8
2015-08-08_21:11:00 thpl 28.8
2015-08-08_21:11:04 rt-dn 28.8
2015-08-08_21:13:49 thpl 28.8
2015-08-08_21:14:04 rt-dn 28.8
2015-08-08_21:14:17 rt-dn 28.8
2015-08-08_21:16:22 thpl 28.8
2015-08-08_21:16:48 rt-dn 28.8
2015-08-08_21:18:38 thpl 28.8
2015-08-08_21:19:05 rt-dn 28.8
2015-08-08_21:21:07 rt-dn 28.8
2015-08-08_21:21:51 thpl 28.8
2015-08-08_21:23:58 rt-dn 28.8
2015-08-08_21:24:47 thpl 28.8
2015-08-08_21:26:35 rt-dn 28.8
2015-08-08_21:26:46 rt-dn 28.8
2015-08-08_21:27:27 thpl 28.8
2015-08-08_21:28:55 rt-dn 28.8
2015-08-08_21:29:50 thpl 28.8
2015-08-08_21:31:52 rt-dn 28.8
2015-08-08_21:33:10 thpl 28.8
2015-08-08_21:34:36 rt-dn 28.8
2015-08-08_21:36:13 thpl 28.8
2015-08-08_21:37:05 rt-dn 28.8
2015-08-08_21:39:00 thpl 28.8
2015-08-08_21:39:19 rt-dn 28.8
2015-08-08_21:41:20 rt-dn 28.8
2015-08-08_21:41:31 thpl 28.8
2015-08-08_21:44:09 rt-dn 28.8
2015-08-08_21:44:57 thpl 28.8
2015-08-08_21:46:45 rt-dn 28.8
2015-08-08_21:48:08 thpl 28.8
2015-08-08_21:49:06 rt-dn 28.8
2015-08-08_21:51:02 thpl 28.8
2015-08-08_21:51:12 rt-dn 28.8
2015-08-08_21:53:39 thpl 28.8
2015-08-08_21:54:08 rt-dn 28.8
2015-08-08_21:56:01 thpl 28.8
2015-08-08_21:56:50 rt-dn 28.8
2015-08-08_21:59:17 rt-dn 28.8
2015-08-08_21:59:19 thpl 28.8
2015-08-08_22:01:30 rt-dn 28.8
2015-08-08_22:02:20 thpl 28.9
2015-08-08_22:04:32 rt-dn 28.9
2015-08-08_22:05:05 thpl 28.9
2015-08-08_22:07:20 rt-dn 28.9
2015-08-08_22:07:33 thpl 28.9
2015-08-08_22:09:53 rt-dn 28.9
2015-08-08_22:10:58 thpl 28.9
2015-08-08_22:12:12 rt-dn 28.9
2015-08-08_22:14:06 thpl 29.0
2015-08-08_22:14:17 rt-dn 29.0
2015-08-08_22:16:58 thpl 29.0
2015-08-08_22:17:11 rt-dn 29.0
2015-08-08_22:19:34 thpl 29.0
2015-08-08_22:19:51 rt-dn 29.0
2015-08-08_22:21:53 thpl 29.1
2015-08-08_22:22:17 rt-dn 29.1
2015-08-08_22:24:28 rt-dn 29.1
2015-08-08_22:25:09 thpl 29.0
2015-08-08_22:27:28 rt-dn 29.0
2015-08-08_22:28:08 thpl 29.1
2015-08-08_22:30:14 rt-dn 29.1
2015-08-08_22:30:51 thpl 29.1
2015-08-08_22:32:46 rt-dn 29.1
2015-08-08_22:33:18 thpl 29.1
2015-08-08_22:35:03 rt-dn 29.1
2015-08-08_22:36:40 thpl 29.2
2015-08-08_22:37:06 rt-dn 29.2
2015-08-08_22:39:47 thpl 29.1
2015-08-08_22:39:58 rt-dn 29.1
2015-08-08_22:42:37 thpl 29.2
2015-08-08_22:45:00 rt-dn 29.2
2015-08-08_22:45:10 thpl 29.2
2015-08-08_22:47:09 rt-dn 29.2
2015-08-08_22:47:28 thpl 29.2
2015-08-08_22:50:08 rt-dn 29.2
2015-08-08_22:50:41 thpl 29.3
2015-08-08_22:52:52 rt-dn 29.3
2015-08-08_22:53:38 thpl 29.3
2015-08-08_22:55:22 rt-dn 29.3
2015-08-08_22:56:19 thpl 29.3
2015-08-08_22:57:37 rt-dn 29.3
2015-08-08_22:58:43 thpl 29.3
2015-08-08_22:59:38 rt-dn 29.3
2015-08-08_23:02:04 thpl 29.3
2015-08-08_23:02:29 rt-dn 29.3
2015-08-08_23:05:05 rt-dn 29.3
2015-08-08_23:05:08 thpl 29.3
2015-08-08_23:07:27 rt-dn 29.3
2015-08-08_23:07:56 thpl 29.3
2015-08-08_23:09:34 rt-dn 29.3
2015-08-08_23:10:28 thpl 29.3
2015-08-08_23:12:31 rt-dn 29.3
2015-08-08_23:13:56 thpl 29.3
2015-08-08_23:15:14 rt-dn 29.3
2015-08-08_23:17:07 thpl 29.3
2015-08-08_23:17:42 rt-dn 29.3
2015-08-08_23:19:55 rt-dn 29.3
2015-08-08_23:20:02 thpl 29.3
2015-08-08_23:22:41 thpl 29.4
2015-08-08_23:22:59 rt-dn 29.4
2015-08-08_23:25:04 thpl 29.3
2015-08-08_23:25:48 rt-dn 29.3
2015-08-08_23:28:22 rt-dn 29.3
2015-08-08_23:28:22 thpl 29.3
2015-08-08_23:30:42 rt-dn 29.3
2015-08-08_23:31:24 thpl 29.4
2015-08-08_23:32:47 rt-dn 29.4
2015-08-08_23:34:10 thpl 29.4
2015-08-08_23:35:42 rt-dn 29.4
2015-08-08_23:36:40 thpl 29.3
2015-08-08_23:38:23 rt-dn 29.3
2015-08-08_23:40:06 thpl 29.4
2015-08-08_23:40:49 rt-dn 29.4
2015-08-08_23:43:01 rt-dn 29.4
2015-08-08_23:43:15 thpl 29.3
2015-08-08_23:46:03 rt-dn 29.3
2015-08-08_23:46:08 thpl 29.4
2015-08-08_23:48:45 thpl 29.4
2015-08-08_23:48:49 rt-dn 29.4
2015-08-08_23:51:06 thpl 29.4
2015-08-08_23:51:22 rt-dn 29.4
2015-08-08_23:53:40 rt-dn 29.4
2015-08-08_23:54:22 thpl 29.4
2015-08-08_23:55:44 rt-dn 29.4
2015-08-08_23:57:22 thpl 29.4
2015-08-08_23:58:37 rt-dn 29.4Kann auch an den derzeit kuscheligen Temperaturen liegen, aber mir wäre keine Abweichung aufgefallen. :-)
Thx a lot, Dirk!
Bei mir läuft das Peering mit dem RT-DN seit Monaten stabil, seit dem Update auf v15.
Tobias
Gesendet von iPad mit Tapatalk
Bei mir läuft das Peering mit dem RT-DN seit Monaten stabil, seit dem Update auf v15.
Tobias
Gesendet von iPad mit Tapatalk
Zitat von: Mr. P am 09 August 2015, 10:40:42
Das Ergebnis stimmt mich zufrieden und ich denke, dir geht es ebenso. :-)
Na cool.
Zitat von: tpm88 am 09 August 2015, 16:51:06
Bei mir läuft das Peering mit dem RT-DN seit Monaten stabil, seit dem Update auf v15.
Na das hättest du ja schon mal eher sagen können :)
Danke euch.
Ich habe das im Github gleich mal dokumentiert und das zugehörige Issue geschlossen
Viele Grüße
Dirk
Hallo Frank,
Zitat von: frank am 07 August 2015, 18:22:13
grundgedanke ist, dass ein remote update ausschliesslich durch eine manuelle konfiguration am device freigeschaltet werden kann.
Die Idee ist grundsätzlich interessant vor allem für Geräte bei denen man mal nicht so schnell die Spannungsversorgung abklemmen kann/möchte. Allerdings für den Sensor aus meiner Sicht nur eingeschränkt sinnvoll. Wenn ich denn schon am Sensor und am Konfigurationstaster angekommen bin, kann man dann auch noch mal kurz die Batterie raus- und wieder reinmachen.
Gruß
Dirk
hi dirk,
ZitatDie Idee ist grundsätzlich interessant vor allem für Geräte bei denen man mal nicht so schnell die Spannungsversorgung abklemmen kann/möchte.
dafür ist die 1. option gedacht. denn beim sw1pbu müsste man sonst mit einer hand am schalter drücken und mit der anderen am sicherungsautomaten. :) das wäre beim sensor nicht so wichtig.
ZitatAllerdings für den Sensor aus meiner Sicht nur eingeschränkt sinnvoll. Wenn ich denn schon am Sensor und am Konfigurationstaster angekommen bin, kann man dann auch noch mal kurz die Batterie raus- und wieder reinmachen.
ja und nein. wenn man sicherheitsbewusst arbeiten möchte, also vor jedem update einschalten und hinterher wieder ausschalten, ist es quasi überflüssig. daher auch default ausgeschaltet. wer aber das "risiko" eingehen möchte, kann die option dauerhaft einschalten. eventuell auch nur ein paar tage, um vielleicht ein paar fw auszuprobieren. dieser sensor hängt ja gerne mal unter dem dachfirst. jedenfalls könnte man so allen gerecht werden.
gruss frank
Zitat von: Dirk am 09 August 2015, 18:18:03
Na das hättest du ja schon mal eher sagen können :)
Das habe ich 8) - siehe hier: http://forum.fhem.de/index.php/topic,34948.msg298863.html#msg298863 (http://forum.fhem.de/index.php/topic,34948.msg298863.html#msg298863)
Da du dort im Mai auch mitgelesen hast, dachte ich, Du hättest das gesehen.
Zitat
Danke euch.
Ich habe das im Github gleich mal dokumentiert und das zugehörige Issue geschlossen
WIR sagen danke!
Gruß
Tobias
Hallo zusammen.
gibt es eine möglichkeit den Sensor auch an der CCU2 zu verbinden.
Habe Versucht das ADDON von hier zu verwenden.
https://github.com/kc-GitHub/Wettersensor/tree/master/Contrib/CCU
Leider ist es mir nicht gelungen die Sensoren an die CCU2 anzulernen.
Mache ich da was falsch ?
Gruß Gerd
Hi Gerd,
ich meine mit dem letzten Update der CCU2 Firmware hat das Addon noch ein paar Probleme.
Dort lässt es sich derzeit noch nicht über den "normalen Weg" installieren.
Workaround:
Die "hb_uw_sen_thpl.xml" von Hand auf die CCU kopieren.
Dafür muss das Filesystem der CCU erst im Schreibmodus gemountet werden (Per SSH auf der CCU):
mount -o remount,rw /
Anschliessend die XML-Datei nach "/firmware/rftypes/" kopieren.
Nach einem Neustart der CCU kann der Sensor dann angelernt werden.
Einziger "Nachteil" dieser Methode:
Das Device hat dann kein schönes Bildchen in der Geräteübersicht.
Viele grüße
Dirk
Hey Dirk,
Danke es hat nun teilweise funktioniert.
Was mich irretiert hat das CCU2 sagt das die FW nicht erfolgreich geflasht wurde.
Aber nach ablernen und neune anlernen (CCU2) und neu anlernen FHEM wurde auch die richtige FW angezeigt.
Habe bis jetzt 2 von 6 upgedatet : Update von 0.12 auf 0.15
Wollte zuerst mit dem HM USB Adapter und dem Win Flashtool .... aber da habe ich keine richtigen Todo gefunden.
soweit ich verstanden habe in dem WinFlash tool
flash.cmd avrdude HB-UW-Sen-THPL_update_V0_15_000_150303.hex HMTYPE ??? HMID??? USBSTICK????
Gruß Gerd
Zitat von: Inputsammler am 13 August 2015, 18:25:17
soweit ich verstanden habe in dem WinFlash tool
Ja, aber nur wenn dein Sensor den seriellen Bootloader drauf hat.
Wenn der AskSin Bootloader drauf ist, kannst du das Firmwareupdate auch mit der CCU2 machen.
Hallo,
ich verfolge dieses äußerst interessante Projekt seit einiger Zeit - wenn auch nicht ganz regelmäßig ...
Dazu jetzt mal eine Frage: ist ein Sensor (oder auch mehrere ;-)) immer noch bestellbar, und wenn ja, ist die Liste vom 11. September 2014 (http://forum.fhem.de/index.php/topic,20620.msg199288.html#msg199288) immer noch aktuell? Eine Suche in diesem Fred hat jedenfalls nichts anderes zu Tage gebracht ...
Gruß, Christoph
Hey Dirk,
Habe bei einen Sensor ein immer wieder Spannung Schwankungen.
habe auch schon eine neue Batterie eingebaut und auch die FW von ,12 auf die ,15 upgedatet.
Hast du da für mich eine Idee. Siehe Bilder (Plots)
Gruß Gerd
Hej Gerd,
ich hatte das selbe auch einmal bei einem meiner Sensoren. Ebenso wie du auch die Batterien getauscht, doch keine Besserung.
Erst ein weiterer Batterietausch brachte eine "Heilung" und seither ist alles so, wie auch bei allen anderen.
Den selben Effekt konnte ich testweise auch bei einigen anderen meiner Sensoren mit diesen Batterien feststellen. Laut Multimeter alles gut und doch gab es Probleme mit denen. :-/
Könnte auch sein, dass eine der Zellen eine "Macke" hat.
Zitat von: caldir65 am 14 August 2015, 20:45:25
Dazu jetzt mal eine Frage: ist ein Sensor (oder auch mehrere ;-)) immer noch bestellbar
ja. hast ne PM :)
Viele Grüße
Dirk
Hallo zusammen
das hört sich sehr gut an, werde ich morgen früh (heute morgen) gleich testen.
Ich leg mal jetzt neue GUTE Batterien ein und dann sehen was passiert.
Rückmeldung kommt Nachmittag.
Dank euch
Gruß Gerd
Zitat von: Dirk am 09 August 2015, 10:07:32
Hm, das ist merkwürdig. Vor allem das es 2 Sensoren gleichzeitig betrifft.
Es gab in den Versionen > 0.12 zwar eine Hardware-bezogene Änderung bzgl. des Helligkeitssensors. Allerdings würde der Sensor dann nicht mehr starten, wenn das bei dir relevant währ.
Könntest du die Rohdaten nochmal aufzeichnen, dazu bitte noch die interpretierten Daten von FHEM damit ich das verifizieren kann.
Evtl. kannst du mir ja auch mal die Debugmeldungen vom Sensor über die serielle Schnittstelle schicken. Mit der 0.15er Version sollte da genügend drinn stehen.
Darüber können wir sicher feststellen ob es an der Hardware liegt.
Ich bin schon gespannt.
Das muss ich mir nochmal genau ansehen. Ich hatte diese Phänomen hier noch nicht. Mal sehen ob ich das reproduziert bekomme.
Gruß
Dirk
Hallo Dirk,
ich würde gerne die debug Meldungen der seriellen Schnittstellen senden, aber ich werde nicht schlau aus dem Platinenlayout, wo soll ich die Daten abgreifen?
Meine Sensoren sind Rev 1.3 07/2014
Gruß
Karl
Zitat von: schka17 am 19 August 2015, 14:07:29
... ich würde gerne die debug Meldungen der seriellen Schnittstellen senden, aber ich werde nicht schlau aus dem Platinenlayout, wo soll ich die Daten abgreifen?
Hallo Karl,
der "Umriss" der Ardunio-Platine müsste einem Arduino pro mini entsprechen, siehe
https://github.com/kc-GitHub/Wettersensor/raw/master/Schematic/Schematic-RF.pdf
J1 die Pins 11 und 12. Das müssten die beiden gelb eingerahmten Pins sein. Bitte den 3,3 V Pegel beachten ;)
Gruß PeMue
Hallo zusammen,
erstaunlich, wie lange die Kiste auch mit einer Zelle durchhält, ich habe heute mal die Akkus gewechselt, der eine war tiefentladen, aber die Daten wurden trotzdem noch bis heute abend übermittelt. Allerdings logge ich die Batteriespannung nur einmal pro Tag ...
Gruß PeMue
Zitat von: PeMue am 19 August 2015, 20:35:42
J1 die Pins 11 und 12. Das müssten die beiden gelb eingerahmten Pins sein. Bitte den 3,3 V Pegel beachten ;)
So ist es. der linke der gelb eingerahmten Pins ist 12, der rechte 11. Weiter rechts daneben ist 10 und wieder rechts daneben 9. usw.
Der Pin 12 ist die TX-Leitung. Das ist die interessante. 11 ist RX die braucht man zum Empfangen der Debugmessages nicht.
Du musst also nur den Pin 12 mit dem RX-Eingang eines USB-UART-Adapter verbinden. Und natürlich noch GND bzw. Masse. diese liegt an Pin 9 an.
Wenn du also nur Pin 12 und Masse mit dem USB-UART-Adapter verbindest, brauchst du dir auch keine Gedanken um den Spannungspegel zu machen da geht dann auch gefahrlos ein USB-UART-Adapter der mit 5V Betrieben wird. Falls du auch Pin 11 verbindest muss der USB-UART-Adapter mit 3,3 V Pegeln arbeiten.
An deinem Terminalprogramm musst als Baudrate noch 57600 einstellen.
Dann solltest du die Debugmeldungen dort sehen.
Gruß
Dirk
Zitat von: Dirk am 19 August 2015, 23:43:16
So ist es. der linke der gelb eingerahmten Pins ist 12, der rechte 11. Weiter rechts daneben ist 10 und wieder rechts daneben 9. usw.
Der Pin 12 ist die TX-Leitung. Das ist die interessante. 11 ist RX die braucht man zum Empfangen der Debugmessages nicht.
Du musst also nur den Pin 12 mit dem RX-Eingang eines USB-UART-Adapter verbinden. Und natürlich noch GND bzw. Masse. diese liegt an Pin 9 an.
Wenn du also nur Pin 12 und Masse mit dem USB-UART-Adapter verbindest, brauchst du dir auch keine Gedanken um den Spannungspegel zu machen da geht dann auch gefahrlos ein USB-UART-Adapter der mit 5V Betrieben wird. Falls du auch Pin 11 verbindest muss der USB-UART-Adapter mit 3,3 V Pegeln arbeiten.
An deinem Terminalprogramm musst als Baudrate noch 57600 einstellen.
Dann solltest du die Debugmeldungen dort sehen.
Gruß
Dirk
Hallo Dirk, ich hoffe daraus etwas erkennen. Hier die Ausgabe der Debugmeldungen, start des Sensor und die erste Übermittlung von Daten aufgezeichnet.
AskSin OTA Bootloader V0.6.1
Start App
Starting sketch...
freeMem: 995 byte
powerMode: 3
Config changed. Data: (L:0)
lowBatLimit: 16
ledMode: 1
burstRx: 0
transmDevTryMax: 3
altitude: 0
<- 14 00 A2 70 9D B5 B5 10 F5 FB 01 11 30 00 00 00 00 00 00 0C 80 (L:21) (M:1366)
-> 0A 00 80 02 10 F5 FB 9D B5 B5 00 (L:11) (M:1509)
<- 14 01 A2 70 9D B5 B5 10 F5 FB 01 0C 2F 00 00 00 00 00 00 0C 80 (L:21) (M:126871)
-> 0A 01 80 02 10 F5 FB 9D B5 B5 00 (L:11) (M:127015)
und hier der list des Devices in FHEM
Internals:
CUNO1_MSGCNT 78
CUNO1_RAWMSG A1402A2709DB5B510F5FB010A2F0000000000000C80::-73.5:CUNO1
CUNO1_RSSI -73.5
CUNO1_TIME 2015-08-20 17:05:35
DEF 9DB5B5
HMLAN_MSGCNT 107
HMLAN_RAWMSG E9DB5B5,0000,A02A918D,FF,FFC8,02A2709DB5B510F5FB010A2F0000000000000C80
HMLAN_RSSI -56
HMLAN_TIME 2015-08-20 17:05:35
IODev HMLAN
LASTInputDev CUNO1
MSGCNT 185
NAME TF_IS1
NR 2439
NTFY_ORDER 50-TF_IS1
STATE <font color="red"> 26.6 °C </font><br><font colo r="lightblue"> 47 % <br><font color="yellow"> 0 Lux</font>
TYPE CUL_HM
lastMsg No:02 - t:70 s:9DB5B5 d:10F5FB 010A2F0000000000000C80
protCmdDel 3
protLastRcv 2015-08-20 17:05:35
protResnd 3 last_at:2015-08-20 11:15:08
protResndFail 1 last_at:2015-08-20 11:17:41
protSnd 111 last_at:2015-08-20 17:05:35
protState CMDs_done
rssi_at_CUNO1 avg:-82.96 min:-94.5 max:-72.5 lst:-73.5 cnt:78
rssi_at_HMLAN avg:-50.22 min:-61 max:-46 lst:-56 cnt:107
Readings:
2015-08-20 11:08:11 Activity alive
2015-08-02 22:27:18 CommandAccepted yes
2015-08-02 22:27:35 D-firmware 0.15
2015-08-02 22:27:35 D-serialNr UWS8345473
2015-08-02 22:27:36 PairedTo 0x10F5FB
2015-08-02 22:22:21 R-altitude 0 m
2015-08-02 22:22:21 R-burstRx off
2015-08-02 22:22:21 R-ledMode on
2015-08-02 22:22:21 R-lowBatLimitTHPL 1.6 V
2015-08-02 22:27:36 R-pairCentral 0x10F5FB
2015-08-02 22:22:21 R-transmDevTryMax 3
2015-08-20 17:05:35 batVoltage 3.20
2015-08-20 17:05:35 battery ok
2015-08-20 17:05:35 humidity 47
2015-08-20 17:05:35 luminosity 0
2015-08-20 17:05:35 normalizedLuminosity 0
2015-08-13 00:31:41 pressure 4119.1
2015-08-13 00:31:41 pressure-nn 4149.7
2015-08-20 16:59:57 statHumidityTendency 1h: +1 2h: +0 3h: -1 6h: -1
2015-08-20 16:59:57 statPressureTendency 1h: +0.0 2h: +0.0 3h: +0.0 6h: +0.0
2015-08-20 16:59:57 statTemperatureTendency 1h: +0.4 2h: +1.1 3h: +1.9 6h: +1.4
2015-08-20 17:05:35 state T: 26.6 H: 47 L: 0
2015-08-20 17:05:35 temperature 26.6
Helper:
HM_CMDNR 2
PONtest 1
_98_statistics STATISTICS
cSnd 0110F5FB9DB5B5010E,0110F5FB9DB5B5010E
getCfgListNo
mId F101
rxType 156
Io:
newCh 1
newChn +9DB5B5,00,00,00
nextSend 1440083135.89035
rxt 2
vccu VCCU
p:
9DB5B5
00
00
00
prefIO:
HMLAN
Mrssi:
mNo 02
Io:
CUNO1 -73.5
HMLAN -54
Prt:
bErr 0
sProc 0
sleeping 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN
flg A
ts 1440083135.61948
ack:
HASH(0x500e438)
02800210F5FB9DB5B500
Rssi:
At_cuno1:
avg -82.9679487179487
cnt 78
lst -73.5
max -72.5
min -94.5
At_hmlan:
avg -50.2242990654206
cnt 107
lst -56
max -46
min -61
Attributes:
IODev HMLAN
IOgrp VCCU:HMLAN
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 0.15
group Wohnzimmer
icon temp_inside
model HB-UW-Sen-THPL-I
peerIDs
room Wohnzimmer
serialNr UWS8345473
stateFormat <font color="red"> temperature °C </font><br><font colo r="lightblue"> humidity % <br><font color="yellow"> luminosity Lux</font>
subType THPLSensor
userReadings normalizedLuminosity {my $t=ReadingsVal($name,"luminosity",-0.55)/0.55;;int($t*100+0.5)/100;;}
Zitat von: Dirk am 17 August 2015, 01:02:17
Könnte auch sein, dass eine der Zellen eine "Macke" hat.
ja. hast ne PM :)
Viele Grüße
Dirk
Darfst mir gerne auch eine PM schicken, bin auch neugierig auf das Teil :)
Viele Grüße
Jorge
Hallo Karl,
Zitat von: schka17 am 20 August 2015, 17:03:44
Hallo Dirk, ich hoffe daraus etwas erkennen. Hier die Ausgabe der Debugmeldungen, start des Sensor und die erste Übermittlung von Daten aufgezeichnet.
Da sind echt keine Helligkkeitsdaten in den Debugausgaben.
Das ist ziemlich merkwürdig Kann dann eigentlich nur ein Hardwareproblem sein. Daher kann ich dir nur einen Austausch/Reperatur der Sensoren anbieten.
Ich schicke die dazu eine PM.
Zitat von: Jorge3711 am 24 August 2015, 14:22:55
Darfst mir gerne auch eine PM schicken, bin auch neugierig auf das Teil :)
Ist unterwegs.
Viele Grüße
Dirk
Hallo Zusammen,
ich bin grade am überlegen ob ich der Firmware vom Sensor die Möglichkeit spendiere "beliebige" analoge Werte zu verarbeiten.
Die Platine vom Sensor hat mindestens drei und maximal 5 Analog-Digitaleingänge verfügbar.
Damit könnte man dann Spannungen von 0-3 V messen. mit einem passenden Spannungsteiler davor auch entsprechend mehr.
Hier könnte man dann z.B. zusätzliche analoge Sensoren (UV, Bodenfeuchte o. ä.) anschließen.
Bestünde an so was generelles Interesse?
Viele grüße
Dirk
Zitat von: Dirk am 28 August 2015, 16:22:30
... ich bin grade am überlegen ob ich der Firmware vom Sensor die Möglichkeit spendiere "beliebige" analoge Werte zu verarbeiten.
... aber gerne doch. Wie würdest Du das machen wollen? Den Analogwert schicken und dann im fhem Modul per attrib eine Gleichung spendieren? Oder in der Firmware rechnen?
Danke + Gruß
PeMue
Entweder so, vermutlich wird das auch die erste Umsetzung, oder man lässt das direkt im Sensor umrechnen. Der min/max-Wert würde dann per Register gesetzt.
Das funktioniert dann aber nur für liniere Werte.
ein kleines 5-kanal-funk-spannungs-messgerät wäre schon eine feine sache. 8)
pro kanal einen einstellbaren fensterkomparator aktivierbar, der ggf trigger an einen peer sendet (siehe energie-messsteckdose), würde ich nicht ablehnen wollen.
gruss frank
Den Fensterkomparator merk ich mir für eine spätere Version :)
Ggf. wird das dann auch eine eigene FW-Version
ZitatGgf. wird das dann auch eine eigene FW-Version
wegen speicherplatz? müsste ja nicht unbedingt für alle kanäle sein. zb 2 unabhängige komparatoren, die man den messkanälen zuordnen kann. oder 1-2 messkanäle mit diesem feature festlegen.
du wirst das schon schaukeln. ;)
Daran wäre ich auch interessiert
Zitat von: frank am 28 August 2015, 20:21:01
wegen speicherplatz? müsste ja nicht unbedingt für alle kanäle sein. zb 2 unabhängige komparatoren, die man den messkanälen zuordnen kann. oder 1-2 messkanäle mit diesem feature festlegen.
Ja. Der ist aktuell schon knapp. Die Anzahl der Kanäle ist da eher unrelevent.
ZitatJa. Der ist aktuell schon knapp. Die Anzahl der Kanäle ist da eher unrelevent.
aha ..., du planst, den vorhandenen universalsensor um eine spgsmessung zu erweitern. also, mit entsprechender fw könnte man dann an dem schon vorhandenen sensor zusätzlich die ad-pins nutzen. alles klar.
Hej Dirk,
Vielen Dank für deine Motivation zur Weiterentwicklung. Interesse besteht auf alle Fälle! :-)
Zwei Dinge, die ich gerne noch mit deinem Universalsensor messen würde um endlich ohne 1-wire auszukommen:
1) Bodenfeuchte (hast du schon erwähnt)
2) Windgeschwindigkeit (zB mit diesem hier (http://www.eservice-online.de/produkte/umweltsensoren/123/windsensor-windrad) - müsste mit dem Sensor doch auch möglich sein, wenn auch kein analoges Signal - oder?)
Bin gespannt! :-)
Hallo Dirk,
auch von mir einen großen Dank für dieses Teil !!
Was ich mir noch vorstellen könnte, wäre die Anbindung eines Ultraschallsensors zur Entfernungsmessung (wenn das denn überhaupt geht), um so z.B. die Füllstände von Öltanks oder Wasserzisternen zu messen.
Viele Grüße
Christoph.
Zitat von: Mr. P am 02 September 2015, 10:33:35
2) Windgeschwindigkeit (zB mit diesem hier (http://www.eservice-online.de/produkte/umweltsensoren/123/windsensor-windrad) - müsste mit dem Sensor doch auch möglich sein, wenn auch kein analoges Signal - oder?)
Das Teil gibt einfach Impulse aus. Pro Umdrehung 4.
Diese muss man "nur" zählen und entsprechend auswerten.
Die Zählung kann man recht einfach realisieren, indem man den Sensor einen der freien IO-Pins anschliesst. Ein Impuls muss dann dafür sorgen das der AVR da dann aufwacht, zählt und wieder schlafen geht.
Ein paar Details muss man dann in der Firmware noch verändern, wie das Aufwachen beim externen Impuls. Das Sollte aber recht einfach machbar sein.
Zitat von: CQuadrat am 02 September 2015, 10:37:37
Was ich mir noch vorstellen könnte, wäre die Anbindung eines Ultraschallsensors zur Entfernungsmessung (wenn das denn überhaupt geht), um so z.B. die Füllstände von Öltanks oder Wasserzisternen zu messen.
Das sollte z.B. hiermit schon funktionieren: http://www.amazon.de/Aukru-Ultraschall-HC-SR04-Distance-Raspberry/dp/B00R2U8HK6
Allerdings braucht das Teil 5V als Versorgungsspannung. Man müsste ausprobieren o der mit 3,3V auch noch funktioniert. Alternativ braucht man einen Kleinen Stepup-Wandler von 3,3V -> 5V. Laut Beschreibung liefert das Teil je nach Entfernung ein analoges Signal von VCC bis 0V. Das könnte man dann einfach mit dem AD-Wandler messen.
Mit einem Zusätzlichen freien Pin könnte man das Teil dann nur bei Messungen Einschalten. Dann funktioniert das Ganze sogar Batteriebetrieben.
Viele Grüße
Dirk
Zitat von: Dirk am 02 September 2015, 13:06:56
Das Teil gibt einfach Impulse aus. Pro Umdrehung 4.
Diese muss man "nur" zählen und entsprechend auswerten.
So ist es, und mit Angabe der "1,5 Hz pro 10 km/h" kann man dann recht einfach ans gewünschte Ergebnis kommen.
Zitat von: Dirk am 02 September 2015, 13:06:56
Die Zählung kann man recht einfach realisieren, indem man den Sensor einen der freien IO-Pins anschliesst. Ein Impuls muss dann dafür sorgen das der AVR da dann aufwacht, zählt und wieder schlafen geht.
Ein paar Details muss man dann in der Firmware noch verändern, wie das Aufwachen beim externen Impuls. Das Sollte aber recht einfach machbar sein.
Wie realistisch ist deiner Meinung nach damit ein Batteriebetrieb? Ich mein, der HM-WDS100-C6-O läuft zwar mit 4,5V - wird diese Messung wohl aber auch nicht viel anders machen und kommt laut Hersteller ~2 Jahre damit aus.
Der AVR im Sensor wacht jetzt schon alle 300ms auf um den internen Zähler zu aktualisieren. Damit wird derzeit die Syncronisierung der Kommunikation zum Thermostat berechnet.
Daher ist der Batteriebetrieb damit durchaus realistisch. > 1 Jahr sollte man mit 2 AA-Zellen sicher auch erreichen.
Ggf. würde ich das Windrad versuchen umzubauen, das das nur noch 1 oder 2 Impuls pro Umdrehung sendet.
Zitat von: Dirk am 02 September 2015, 13:06:56
Das sollte z.B. hiermit schon funktionieren: http://www.amazon.de/Aukru-Ultraschall-HC-SR04-Distance-Raspberry/dp/B00R2U8HK6
Ja, das tut's auch, wie ich auch schon selber erfolgreich umsetzen konnte.
Allerdings würde mir die Übertragung der Daten per HM besser gefallen,
Zitat von: Dirk am 02 September 2015, 13:43:45
Ggf. würde ich das Windrad versuchen umzubauen, das das nur noch 1 oder 2 Impuls pro Umdrehung sendet.
Würde von der Genauigkeit bestimmt genügen... Fragt sich nur, ob sich solche Plastik-Press-Dinger soweit zerlegen, manipulieren und dann vorallem wieder zusammen bauen lassen. :-)
Hallo Dirk,
evtl wäre es möglich dann 2 statt einem "Schalteingang" noch unterzubringen?
Ich bin da wieder bei meinem Bewegungsmelder. Leider habe ich die Programmierung nicht verstanden, aber dann würde ich den Umbau meiner Sensoren noch angehen.
1 Schalteingang Bewegungsmelder
2 Schalteingang Fenster/Tür Schalter
bzw kann man das ja dann selber flexibel in Fhem entscheiden wie man die nutzt als Wandschalter ginge ja auch.
Zitat von: PeMue am 07 August 2015, 16:31:11
... ich überlege mir gerade, ob es möglich ist, einen UV Sensor https://www.dfrobot.com/wiki/index.php?title=UV_sensor_SKU:_SEN0162 mit einzubauen.
Hallo zusammen,
das Break-Out Board von Aliexpress ist da, ist geringfügig anders als im Link oben. Der Verstärker ist ein Transimpedanzverstärker und sollte auch mit 3,3 V funktionieren, Stromaufnahme ist bei 3,3 V etwa 10 mA.
Meine Frage an die Experten:
Ist das PC von diesen (http://www.elv.de/industrie-aufputz-gehaeuse-ip65-modell-g203c.html) Gehäusen überhaupt UV (Wellenlängenbereich 280 .... 360 nm) durchlässig? Wenn nein, braucht es ein anderes Gehäuse oder eine andere Lösung >:(
Gruß PeMue
Zitat von: CQuadrat am 02 September 2015, 14:15:06
Allerdings würde mir die Übertragung der Daten per HM besser gefallen,
Hast du so ein Teil schon da?
Kannst du mal schauen ob das bei 3,3V auch noch funktioniert?
Zitat von: Mr. P am 02 September 2015, 15:03:45
Fragt sich nur, ob sich solche Plastik-Press-Dinger soweit zerlegen, manipulieren und dann vorallem wieder zusammen bauen lassen. :-)
Das müsste man mal sehen.
Vermutlich sind hier vier Magnete drinn die über einem Reedkontakt vorbei laufen. Da sollte es reichen drei der Magnete zu entfernen.
Zitat von: santalaus am 03 September 2015, 09:47:19
evtl wäre es möglich dann 2 statt einem "Schalteingang" noch unterzubringen?
Das wird vermutlich aus Platzgründen auch auf eine eigene FW-Version hinauslaufen.
Zitat von: PeMue am 04 September 2015, 09:26:44
Der Verstärker ist ein Transimpedanzverstärker und sollte auch mit 3,3 V funktionieren, Stromaufnahme ist bei 3,3 V etwa 10 mA.
Dden Sensor könnte man dann ggf. über einen AVR-Pin versorgen. Dann könntest du den nur bei einer Messung aktivieren.
Zitat
Meine Frage an die Experten:
Ist das PC von diesen (http://www.elv.de/industrie-aufputz-gehaeuse-ip65-modell-g203c.html) Gehäusen überhaupt UV (Wellenlängenbereich 280 .... 360 nm) durchlässig?
Im Zweifelsfall nein. Das Datenblatt schweigt sich hier leider aus. Daher wird man das wohl testen müssen.
Viele Grüße
Dirk
ZitatDas wird vermutlich aus Platzgründen auch auf eine eigene FW-Version hinauslaufen.
da könnte man langsam mal über eine modulare firmware nachdenken.
zb in register.h "sensor/feature-apps" auswählbar machen. dann könnte sich jeder einfach eine kollektion zusammen stellen. :)
Hallo,
wäre auch an dem Universalsensor interessiert, nur finde ich keine Eagle-Files zum nachmachen der Leiterplatte. Gibt es irgendwo einen Link.
Danke
Zitat von: Dirk am 04 September 2015, 09:46:43
Hast du so ein Teil schon da?
Kannst du mal schauen ob das bei 3,3V auch noch funktioniert?
Ja, und es funktioniert auch.
Leider habe ich im Moment kein Bastelzeug zuhause, um den Sensor bei 3,3V zu testen. Es würde mich aber wundern, wenn es funktioniert. Ein kurzer Blick ins Netz scheint das auch zu bestätigen.
Und mit einem Pegelwandler zu arbeiten, macht die Sache dann wohl wieder zu kompliziert....
Hallo Dirk,
Vielen Dank für die Superarbeit. Ich bin echt begeistert wie viel hier in diesem Forum selber gebastelt wird.
Ich würde jetzt auch gern mit deinem Sensor starten.
Gibt es irgendwo eine zusammengefasste Teile Liste und vor allem eine Eagledatei.
Ich bräuchte die Daten nämlich als Rohdaten um Gerber zu erstellen.
Im Wiki finde ich nur die Jpeg-Bilder.
Danke
Hallo,
Wollte auch mal einigee Idee äußern.
Ich habe über LogoV7 und ihren 0 - 10V Eingange einen Lichtsensor gekoppelt, der genau auf den südlichen Himmel ausgerichtet ist
http://www.ebay.de/itm/Lichtsensor-Messbereich-0-100-klux-Ausgang-0-10-V-Wetterstation-Ub-24VDC-AC-/161632979225?hash=item25a2138919
Messbereich 0 - 100.000 Lux.
Interessant dabei ist nur das die Helligkeit bei Sonnenschein > 100.000 Lux ist.
Wenn ich die Daten richtig deute, schafft der TSL2561 max. 40.000 Lux.
Was habt ihr für Erfahrungen gemacht mit voller Sonneneinstrahlung?
Habe hier noch einen GY-30 der hat max. 65.000 Lux könnte ihn aber noch nicht testen.
Da ich mir auch gerne eine vollwertige kleine Wetterstation basteln möchte, ich auch schon radioaktiv Strahlung messe, und mich noch weitere Messwerte interessieren bin ich auch mal über einen Windsensor gestolpert, aber habe leider keine weiteren Daten gefunden wie die Daten übermittelt werden, ob Impuls oder Bus System
http://www.eltako.com/fileadmin/downloads/de/Datenblatt/H_datenblatt_WS.pdf
Einen Regenzähler würde ich mir aus einer alten defekten KS300 bauen, den Magnetkontakt einfach zählen, da es ja pro 1x umkippen 0,295l/m² regen ist, sollte das einfach sein.
Hier vielleicht noch ganz interessant GY-ML8511 Ultraviolet Light UV
http://www.dx.com/p/gy-ml8511-ultraviolet-light-uv-sensor-breakout-test-module-detector-blue-394373
Weitere interessante Sensoren wären der TGS 2600, MQ-7,
http://www.dx.com/p/mq-7-combustible-gas-co-detector-sensor-module-for-arduino-179457
Mit einem Mikrofon könnte man auch noch die Geräuschkulisse wenn man an einer Straße wohnt registrieren.
Zitat von: Edi77 am 19 September 2015, 00:43:58
Interessant dabei ist nur das die Helligkeit bei Sonnenschein > 100.000 Lux ist.
Wenn ich die Daten richtig deute, schafft der TSL2561 max. 40.000 Lux.
Was habt ihr für Erfahrungen gemacht mit voller Sonneneinstrahlung?
Habe hier noch einen GY-30 der hat max. 65.000 Lux könnte ihn aber noch nicht testen.
Hallo Edi,
bei mir hängt der Sensor unter meiner Photovoltaikanlage und ich habe eine Filterfolie davorgeschaltet. Vorher hat der Helligkeitssensor immer übersteuert, jetzt könnte ich sogar gegen die Wetterstation im KIT in Karlsruhe kalibrieren.
@Dirk:
Ich wollte die Pinbelegung des I2C Busses bzw. des Erweiterungssteckers anhand vom Layout
https://github.com/kc-GitHub/Wettersensor/raw/master/Schematic/Schematic-RF.pdf
herausbekommen. Allerdings passt m.A.n. die Hardware nicht zu dem, was in Github eingestellt ist:
Layout:
(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=37639;image)
Hardware:
(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=37645;image)
Oder der Außensensor hat ein anderes Layout als der Innensensor ;)
Wäre toll, wenn Du das bei Gelegenheit klären könntest.
Gruß PeMue
Edit:
Nehme alles zurück, im Wiki war ein Bild, siehe http://www.fhemwiki.de/wiki/Datei:Universalsensor-CC1101-Aussen_platine.jpg. Allerdings die Unstimmigkeit im Layout würde mich trotzdem interessieren ...
Hej PeMue,
du vergleichst ein Photo von Revision 1.0 mit dem Layout von 1.2.
Ich würde sagen... Ist einfach ein "altes" Photo. ;-)
Gesendet mit Tapatalk
Hallo,
@CQuadrat
Ich hab mir jetzt mal ein Paar von denen hier bestellt:
http://de.aliexpress.com/item/US-100-ultrasonic-sensor-module-temperature-compensation-Distance-Measuring/1873033459.html?adminSeq=201492522&shopNumber=612195
ZitatBetriebsspannung dc 2.4v~5.5v
Diese sollten sich dann "einfach so" an den Sensor Klemmen lassen.
Damit währ dann auch ohne Probleme ein Batteriebetrieb realisierbar.
Wenn die Teile da sind werde ich damit mal etwas experimentieren.
@FEHMPiDi, @Maxl, @Pemue
Ich habe die Eagle-Fiels jetzt mal mit ins Git gestellt.
Zitat von: Edi77 am 19 September 2015, 00:43:58
Wenn ich die Daten richtig deute, schafft der TSL2561 max. 40.000 Lux.
Ja, daher gibt es dann noch die Filterfolie. Die lässt nur 25% der Sonne durch.
ZitatIch wollte die Pinbelegung des I2C Busses bzw. des Erweiterungssteckers anhand vom Layout
https://github.com/kc-GitHub/Wettersensor/raw/master/Schematic/Schematic-RF.pdf
herausbekommen. Allerdings passt m.A.n. die Hardware nicht zu dem, was in Github eingestellt ist:
Schau mal in die Eagle-Files. Ich denke das sollte helfen.
Viele Grüße
Dirk
Zitat von: Dirk am 23 September 2015, 11:30:58
@FEHMPiDi, @Maxl, @Pemue
Ich habe die Eagle-Fiels jetzt mal mit ins Git gestellt.
Hallo Dirk,
vielen Dank. Zwei Schlussfolgerungen meinerseits:
- Außen- und Innensensor haben unterschiedliche Layouts
- Die I2C Schnittstelle ist so wie im Wiki-Bild beschrieben
Gruß PeMue
Hallo,
irgendwie habe ich noch eine Verständnislücke:
Habe Wettersensor aus dem GIT-Repository heruntergeladen und alle Libraries installiert.
Da ich alles erstmal "fliegend" testen will, habe ich "USE_ADRESS_SECTION" in AskSin.h und WetterSesnor.h auf 0 gesetzt.
Es lässt sich auch alles soweit per Arduino IDE hochladen und in FHEM eingebunden gibt es beim Pairing dann Schwierigkeiten:
Der Sensor wird nicht mit den gesetzten Werten erkannt, sondern so:
CUL_HM pair: HM_212120 , model unknown serialNr
Firmwareversion und serialNr passen dann auch in der Anzeige in FHEM nicht:
D-firmware 6.6
D-serialNr mode BUR
Hat irgendwer eine Idee, woran das liegen kann? Vor vielen Seiten in diesem Thread hatte jemand auch schon das Problem und er hat wohl leider aufgegeben :-(
Ich verstehe es doch schon richtig, dass ich den (OTA) Bootloader nicht zwingend brauche, um das ganze testweise zum laufen zu bekommen?
Grüße,
Chris
Hallo Chris,
wenn ich das noch richtig im Kopf habe, flashst Du die Seriennummer mit dem Flash-Skript mit. Die Version der Firmware sollte vom Sketch kommen, bin mir aber nicht wirklich sicher, da ich nur die HEX-Dateien flashe ...
Gruß PeMue
Hi,
aber ich würde ja gerne die Daten aus dem Code verwenden:
#if USE_ADRESS_SECTION == 0
//#define DEVICE_TYPE 0xF1, 0x02 // The model-ID 0xF1 0x01 = DIY (HB-UW-Sen-THPL-O)
#define DEVICE_TYPE 0xF1, 0x01 // The model-ID 0xF1 0x01 = DIY (HB-UW-Sen-THPL-I)
#define DEVICE_SERIAL 'H','B','0','D','e','f','a','u','l','t' // The serial 10 bytes, needed for pairing (Default for serial flash tool)
#define DEVICE_ADDRESS 0xAB, 0xCD, 0xEF // The HM-ID 3 bytes, needed for pairing (Default for flash tool)
#endif
Aber das wird wohl eben trotzdem nicht angezogen :-(
VG
Chris
Hallo Chris,
wenn Du seriell flashst, dann sind die Default-Werte (aus dem Sketch) im Bootloader. Sprich: lass die Werte so stehen und flashe mit dem Flash-Tool und gib da Deine Adressen an ...
Viel Erfolg.
Gruß PeMue
Dh. allein durch Upload des Sketches werde ich das nie zum laufen bekommen?
Doch, das sollte gehen.
/**
* Must set in AskSinMain.h to !!!
Hast du das beachtet?
USE_ADRESS_SECTION muss in der WetterSensor.h und AskSinMain.h auf 1 0 gesetzt werden.
Gruß
Dirk
Hi,
ja, ist auch in AskSinMain.h gesetzt:
#define USE_ADRESS_SECTION 0
VG,
Chris
Dann muss ich mir das mal ansehen.
Zumindest bei den letzten Tests hat das so funktioniert.
Mit welcher Arduino-IDE-Version Arbeitest du?
Hi,
ich verwende arduino-1.6.5-r5.
Habe es aber auch schon mit älteren Versionen probiert (arduino-1.6.5-r2, arduino-1.5.5-r2, arduino-1.0.5-r2).
Komischerweise wird beim bauen mit arduino-1.0.5-r2 folgendes gesetzt:
firmware 2.0
model HM-LC-SW2-SM
serialNr bytefre
VG
Christian
Hallo,
vielleicht könnt Ihr mir helfen. Ich hatte das Problem, dass der Innensensor die Batterien in Stunden leergesaugt hat. Eine Messung ergab eine Stromaufnahme von mehr als 26 mA permanent und ein feines Pfeifen ist zu hören.
Ich meinte mich zu erinnern, dass das erst nach dem Einspielen der V0.15 Firmware (via CCU2) so war. Ich entschloss mich daher eine ältere FW aufzuspielen leider klappt das irgendwie nicht. Egal was ich so aufspiele, der Sensor landet immer wieder im OTA Update-Modus.
Ich führe lediglich dieses Kommando aus:
kaktus@elefant-lin:~/Downloads/HomeMatic/Funkkonfiguratonsadapter USB (HM-CFG-USB-2)/hmcfgusb-master-18e63b2$ sudo ./flash-ota -f "/local/home/kaktus/Downloads/HomeMatic/Selbstbau HM_WDS10_TH_O/Wettersensor-master_V0.15/Firmware-Release/HB-UW-Sen-THPL_update_V0_15_000_150303.eq3" -s UWS05923xy
HomeMatic OTA flasher version 0.097-git
Reading firmware from /local/home/kaktus/Downloads/HomeMatic/Selbstbau HM_WDS10_TH_O/Wettersensor-master_V0.15/Firmware-Release/HB-UW-Sen-THPL_update_V0_15_000_150303.eq3...
Firmware with 224 blocks successfully read.
Rebooting HM-CFG-USB to avoid running out of credits
HM-CFG-USB not in bootloader mode, entering bootloader.
Waiting for device to reappear...
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB in bootloader mode, rebooting
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB opened
HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial UWS05923xy
Device with serial UWS05923xy (hmid: 10281z) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Missing ACK!
Missing ACK!
Missing ACK!
Missing ACK!
No!
Entering 10k-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 224 blocks: 0015/0224 /
Missing ACK!
Flashing 224 blocks: 0017/0224 /
Missing ACK!
Flashing 224 blocks: 0068/0224 /
Missing ACK!
Flashing 224 blocks: 0162/0224 /
Missing ACK!
Flashing 224 blocks: 0173/0224 /
Missing ACK!
Flashing 224 blocks: 0175/0224 /
Missing ACK!
Flashing 224 blocks: 0176/0224 /
Missing ACK!
Flashing 224 blocks: 0176/0224 /
Missing ACK!
Flashing 224 blocks: 0179/0224 /
Missing ACK!
Flashing 224 blocks: 0179/0224 /
Missing ACK!
Flashing 224 blocks: 0220/0224 /
Missing ACK!
Flashing 224 blocks: 0224/0224 -
Entering 10k-mode
Waiting for device to reboot
bzw.
kaktus@elefant-lin:~/Downloads/HomeMatic/Funkkonfiguratonsadapter USB (HM-CFG-USB-2)/hmcfgusb-master-18e63b2$ sudo ./flash-ota -f "/local/home/ktus/Downloads/HomeMatic/Selbstbau HM_WDS10_TH_O/Wettersensor-master_V0.15/Firmware-Release/HB-UW-Sen-THPL_update_V0_14_001_150301.eq3" -s UWS05923xy
kaktus@elefant-lin:~/Downloads/HomeMatic/Funkkonfiguratonsadapter USB (HM-CFG-USB-2)/hmcfgusb-master-18e63b2$ sudo ./flash-ota -f "/local/home/kaktus/Downloads/HomeMatic/Selbstbau HM_WDS10_TH_O/Wettersensor-master_V0.13/Firmware-Release/HB-UW-Sen-THPL_update_V0_13_000_141006.eq3" -s UWS05923xy
Hat jemand eine Idee, was ich noch tun könnte ?
Vielen Dank schon mal im Voraus.
lg.
TF
Die 0.15er Version verhält sich nur so, wenn BurstRx vom Sensor eingeschaltet ist. Das funktioniert noch nicht.
Das muss ausgeschaltet sein. Denn dann geht der Sensor nicht mehr in den Schlafmode.
~25 mA sind der typische Verbrauch wenn der Sensor aktiv ist.
Das leise pfeifen kann von der Spule des Schaltreglers kommen.
Ansonsten Beim Update nicht zu nah an den Sender ran gehen. Da sollten > 50cm Abstand sein.
Viele Grüße
Dirk
Hallo Dirk,
vielen Dank. >50 cm waren bei mir der Nebenraum und dann auch zwei Versuche. BurstRX schalte ich wie ein bzw. aus ?
lg.
TF
In der CCU in den Geräteeinstellungen "Wake-On-Radio" ausschalten.
Zitat>50 cm waren bei mir der Nebenraum
Dann kannst du ruhig mal näher rangehen.
Vor allem Wenn noch andere HM-Geräte dazwischenfunken dürfte das die Übertragungssicherheit erhöhen.
Alternativ den Sensor in den "Auslieferungszustand" versetzen (Reset).
http://www.fhemwiki.de/wiki/Universalsensor#Firmware (Abschnitt Configtaster)
Aua, da habe ich mich wohl sehr ungünstig ausgedrückt. Ich wollte sagen, ich musste den Sensor in den Nebenraum legen, dann habe ich zwei mal das ota Update laufen lassen, dann hat es geklappt. Empfiehlst Du eigentlich die HB-UW-Sen-THPL_update_V0_14_001_150301.eq3 oder die HB-UW-Sen-THPL_update_V0_15_000_150303.eq3 ?
Nochmals vielen Dank !
ZitatEmpfiehlst Du eigentlich die HB-UW-Sen-THPL_update_V0_14_001_150301.eq3 oder die HB-UW-Sen-THPL_update_V0_15_000_150303.eq3
Auf Grund des Bugs mit dem BurstRx empfehle ich aktuell die V0.14 zu benutzen.
Wenn du den Sensor aber mit einem HM-CC-RT-DN Pairen willst, dann muss man die 0.15 benutzen wobei dann BurstRx ausgeschaltet sein muss.
Viele Grüße
Dirk
Es ist vermutlich eine blöde Frage. Mit welchen Ziel paare ich den Sensor mit dem Thermostaten ?
Man kann den Sensor dann als abgesetzten Temperaturfühler verwenden. Dann wird die Temperatur nicht mehr an der Heizung im Thermostat gemessen sondern an einer Stelle deiner Wahl.
OK, dann habe ich das richtig verstanden. Danke.
BurstRx ist erst ab V0.15 drin oder macht erst ab da Probleme ?
Erst ab V0.15 wird das BurstRx-Register vom Sensor verarbeitet. Vorher wird das einfach ignoriert.
Ich bekomme gerade die Krise.
Ich habe einen HB-UW-Sen-TH Innenversion und letztes Jahr auch bereits an meine ccu2 angelernt.
Gestern habe ich meine ccu2 auf die aktuelle Version 2.15.2 upgedatet.
Jetzt habe ich festgestellt, dass der HB-UW-Sen-TH nicht mehr in der Geräteliste auftaucht.
Das hoffentlich aktuelle Addon für die CCU habe ich per Zusatzsoftware installiert.
Den Sensor kann ich aber nicht an der ccu2 anlernen.
Was habe ich vergessen?
Kann mir jemand weiterhelfen?
THX
_cv
Zitat von: _cv am 10 Oktober 2015, 22:33:43
Das hoffentlich aktuelle Addon für die CCU habe ich per Zusatzsoftware installiert.
Wurde die Zusatzsoftware mal in der Übersicht angezeigt?
Wird sie jetzt in der Übersicht angezeigt?
Ich gehe davon aus, dass die in der aktuellen Version nicht richtig eingebunden wird.
Zitat von: _cv am 10 Oktober 2015, 22:33:43
Gestern habe ich meine ccu2 auf die aktuelle Version 2.15.2 upgedatet.
Mit der aktuellen CCU-Version gibt es wohl ein Problem bei der Installation des Addons. Das hab ich noch nicht lösen können.
Die wichtige Datei im Addon ist die XML-Datei "hb_uw_sen_thpl.xml" diese muss dann manuell auf die CCU kopiert werden.
Die Datei kommt in das Verzeichniss "/firmware/rftypes/"
Der Sensor funktioniert dann wieder, hat aber erstmal kein Icon.
Viele Grüße
Dirk
Ich bin beim "Manipulieren" der ccu2 unerfahren.
Nach /firmware kann nicht geschrieben werden, da ro eingehangen. Sollte da über einen anderen Mountpoint geschrieben werden oder als rw einhängen?
Zitat von: Dirk am 11 Oktober 2015, 10:08:18
Mit der aktuellen CCU-Version gibt es wohl ein Problem bei der Installation des Addons. Das hab ich noch nicht lösen können.
Die wichtige Datei im Addon ist die XML-Datei "hb_uw_sen_thpl.xml" diese muss dann manuell auf die CCU kopiert werden.
Die Datei kommt in das Verzeichniss "/firmware/rftypes/"
Der Sensor funktioniert dann wieder, hat aber erstmal kein Icon.
Viele Grüße
Dirk
Okay, kannst Du mir bitte darstellen, wie ich die xml direkt auf das Verzeichnis kopieren kann?
THX
_cv
Ich glaube ich habe den Fehler im CCU Addon gefunden.
Die aktualisierte Version ist im Github oder hier:
https://github.com/kc-GitHub/Wettersensor/raw/master/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon.tgz
Zitat von: Ralli am 11 Oktober 2015, 07:32:40
Wurde die Zusatzsoftware mal in der Übersicht angezeigt?
Wird sie jetzt in der Übersicht angezeigt?
Da es sich hier um ein Firmwarepatch handelt, wird das nach der Installation hier nicht angezeigt.
Auch muss das Addon nach jedem Firmwareupdate neu installiert werden
Wenn die Installation auf der CCU2 funktioniert hat, sag bitte mal bescheid.
Ich konnte das nur auf meiner CCU1 bzw. auf der LXCCU testen.
Viele Grüße
Dirk
Nach der Installation liegen nun die beiden XML-Dateien in /firmware/rftypes, scheint also zu klappen (habe den Sensor nicht an der CCU2 angelernt bisher).
Das Einspielen Deines veränderten CCU-Addons hat auf meine CCU2 wieder funktioniert. Vielen Dank !
Hallo Dirk,
ich habe exakt das gleicheProblem wie Chris und bin froh, dass ich nicht der einzigste bin, der das Problem beim Kompilieren und Hochladen mit der Arduino IDE hat. Ich habe das Problem schon einmal vor einigen Monaten angesprochen, da ich aber absolut nicht weiter gekommen bin, hatte ich das Ganze erst einmal bei Seite gelegt.
Nach dem Kompilieren und Flashen der Version 0.14 erhalte ich ebenfals die gleichen Einträge in FHEM
CUL_HM pair: HM_212120 ,
model unknown serialNr
D-firmware 6.6
D-serialNr mode BUR
Obwohl ich ebenfalls die Variable "USE_ADRESS_SECTION" in AskSin.h und WetterSesnor.h auf 0 gesetzt habe, benutzt die Software andere Werte als die, die in den Variablen gesetzt sind. Auch das setzen anderer Werte in den Variablen ändert nichts an den Werten mit denen sich der Sensor bei FHEM registriert. Bis jetzt habe ich nicht herausgefunden wo die Sofware diese Werte herbekommt. Allerdings habe ich festgestellt, dass die Werte mit denen sich der Sensor bei FHEM registriert ändern, wenn ich einige Zeilen in das Programm einfüge, um die Variablen über die serielle Schnittstelle an den PC zu schicken.
Deshalb vermute ich, dass es doch ein Softwareproblem ist und nicht, wie ich die ganze Zeit vermutet hatte, ein Problem mit meinem fliegendem Testaufbau.
Viele Grüße
Helmut
Zitat von: Dirk am 12 Oktober 2015, 00:10:47
Ich glaube ich habe den Fehler im CCU Addon gefunden.
Die aktualisierte Version ist im Github oder hier:
https://github.com/kc-GitHub/Wettersensor/raw/master/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon.tgz
Da es sich hier um ein Firmwarepatch handelt, wird das nach der Installation hier nicht angezeigt.
Auch muss das Addon nach jedem Firmwareupdate neu installiert werden
Wenn die Installation auf der CCU2 funktioniert hat, sag bitte mal bescheid.
Ich konnte das nur auf meiner CCU1 bzw. auf der LXCCU testen.
Viele Grüße
Dirk
Vielen Dank, es hat funktioniert (dass das Symbol fehlt ist nicht schlimm).
THX
_cv
Hallo noch mal,
Hat jemand schon mal an den Innensensor einen HC-SR501 bzw. Bewegungsmelder mit gekoppelt, als Präsenzmelder für einen Raum?
Zitat von: _cv am 12 Oktober 2015, 22:57:06
Vielen Dank, es hat funktioniert (dass das Symbol fehlt ist nicht schlimm).
THX
_cv
Welches denn ?
Hi Helmut und Chris.
Zitat von: Poquito am 12 Oktober 2015, 21:27:05
ich habe exakt das gleicheProblem wie Chris und bin froh, dass ich nicht der einzigste bin, der das Problem beim Kompilieren und Hochladen mit der Arduino IDE hat. Ich habe das Problem schon einmal vor einigen Monaten angesprochen, da ich aber absolut nicht weiter gekommen bin,
Das hatte ich komplett aus den Augen verloren.
Ich schaue mir das die Tage noch mal an.
Zitat von: _cv am 12 Oktober 2015, 22:57:06
Vielen Dank, es hat funktioniert (dass das Symbol fehlt ist nicht schlimm).
Hast du zufällg eine CCU1?
Das Root-FS der CCU1 ist seit einem der letzten Updates wohl ziemlich am Anschlag.
Daher schlägt das Patchen der Js-Datei welche für die Bildanzeige verantwortlich ist fehl.
Ich habe das Updatescript vom Addon noch mal angepasst. Einfach noch mal installieren. Damit sollten auch die Icons auf der CCU1 wieder angezeigt werden.
https://github.com/kc-GitHub/Wettersensor/raw/master/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon.tgz
Ansonsten: mal den Browsercache löschen.
Zitat von: Edi77 am 13 Oktober 2015, 00:57:15
Hat jemand schon mal an den Innensensor einen HC-SR501 bzw. Bewegungsmelder mit gekoppelt, als Präsenzmelder für einen Raum?
Ich haba da schon mal angefangen. Allerdings bin ich da noch nicht weit gekommen.
Das Teil ist auf alle Fälle interessant. Vermutlich wird das aber auf ein eigenes Device hinaus laufen.
Der Speicher von der Sensor-Firmware ist schon ziemlich ausgelastet. Und vor allem beim Bewegungsmelder ist auch das Thema AES interessant. Und direktes Peering zu den Aktoren ist da sicher auch nicht uninteressant. Da sind wir beim Entwickeln der Asksin-Lib aber schon ein gutes Stück voran gekommen.
Ein ganz faches Triggern sollte damit aber machbar sein.
Viele Grüße
Dirk
Zitat
ich habe exakt das gleicheProblem wie Chris und bin froh, dass ich nicht der einzigste bin, der das Problem beim Kompilieren und Hochladen mit der Arduino IDE hat. Ich habe das Problem schon einmal vor einigen Monaten angesprochen, da ich aber absolut nicht weiter gekommen bin,
Das hatte ich komplett aus den Augen verloren.
Ich schaue mir das die Tage noch mal an.
Super... Wenn ich etwas testen soll, stehe ich bereit ...
Hallo,
ich habe auch Interesse an einem Selbstbau Außensensor. Ist er noch bestellbar.
Wie siehts mit der Reichweite aus? Zwischen dem HMUSB und dem Sensor sind dann 2 Wände und ein Fenster mit Rolladen.
Neben dem Fenster ist ein "HM-LC-Bl1PBU-FM" mit den folgenden Werten:
rssi_at_hmusb avg:-62 min:-68 max:-57 lst:-63 cnt:114
rssi_hmusb avg:-60.45 min:-65 max:-57 lst:-61 cnt:57
Gruß Ralf
Hallo
hat von euch eigentlich wer mal das SHT11 Breakout Board in ein extra Gehäuse gebaut ?
Wenn ja, in welches ?
Bin da grad was unschlüssig was ich da nehmen soll ...
Danke,
Gruß
Marco
Habe so einen: http://www.aliexpress.com/item/Wholesale-10piece-a-lot-Humidity-Sensor-plastic-pcb-enclosures-for-plastic-box-electronics-60-27-16mm/1526251357.html?spm=2114.01020208.3.42.uYHBiQ&ws_ab_test=searchweb201556_2,searchweb201527_4_71_72_73_74_75,searchweb201560_4
Zitat von: Ralf9 am 18 Oktober 2015, 18:12:59
Hallo,
ich habe auch Interesse an einem Selbstbau Außensensor. Ist er noch bestellbar.
Hi zusammen,
wie Ralf habe ich auch großes Interesse an zwei Selbstbau-Sensoren. @Dirk, bietest du noch an?
Viele Grüße
Daniel
Hallo Ralf9 und ndaniel,
Zitat von: ndaniel am 20 Oktober 2015, 16:46:58
@Dirk, bietest du noch an?
ich baue immer mal wieder Sensoren zusammen. Daher Ja.
Die Außensensoren dauert aktuell aber etwas länger.
Da muss ich erst wieder neue Plainen nachbestellen
Zitat von: Ralf9 am 18 Oktober 2015, 18:12:59
ich habe auch Interesse an einem Selbstbau Außensensor. Ist er noch bestellbar.
Wie siehts mit der Reichweite aus?
Ich schätze die Reichweite sollte so wie bei anderen Geräten sein.
Viele Grüße
Dirk
Ich würde mich auch anschließen. Dann lohnt die Bestellung auch. ;)
Zitat von: Dirk am 22 Oktober 2015, 10:27:22
Die Außensensoren dauert aktuell aber etwas länger. Da muss ich erst wieder neue Plainen nachbestellen
Da hab ich aber Glück gehabt ;D ... (gestern angekommen, vielen Dank)
@Ralf9, @ndaniel und @Gunther,
schickt mir mal eine PM. Dann nehme ich euch mit in die Liste mit auf :)
Viele Grüße
Dirk
Hi Dirk,
könntest Du bitte mal einen Link zu den aktuellen FW Ständen posten..... bevor ich hier alles durchsuche ;)
Meine Sensoren hatte lange rufe vor mir ... jetzt ist es Zeit für´n update !
Danke
klaus
Zitat von: Poquito am 12 Oktober 2015, 21:27:05
ich habe exakt das gleicheProblem wie Chris und bin froh, dass ich nicht der einzigste bin, der das Problem beim Kompilieren und Hochladen mit der Arduino IDE hat.
Da war tatsächlich ein unbemerkter Bug im Code. Das Sollte jetzt funktionieren. Bitte auch das Subrepo mit der Lib aktualisieren.
Tut mir leid das es länger gedauert hat.
Dafür kann der Sensor jetzt aber auch, für die Freunde der Füllstandsmessung, experimentell Entfernungen messen.
Darüber später mehr :)
Edit:
Zitat von: kvo1 am 23 Oktober 2015, 16:11:14
könntest Du bitte mal einen Link zu den aktuellen FW Ständen posten..... bevor ich hier alles durchsuche ;)
Sorry, vergessen: https://github.com/kc-GitHub/Wettersensor
Viele Grüße
Dirk
Zitat von: Dirk am 23 Oktober 2015, 18:29:08
Da war tatsächlich ein unbemerkter Bug im Code. Das Sollte jetzt funktionieren. Bitte auch das Subrepo mit der Lib aktualisieren.
Tut mir leid das es länger gedauert hat.
Dafür kann der Sensor jetzt aber auch, für die Freunde der Füllstandsmessung, experimentell Entfernungen messen.
Darüber später mehr :)
Edit:Sorry, vergessen: https://github.com/kc-GitHub/Wettersensor
Viele Grüße
Dirk
Hallo Dirk,
viele Dank - jetzt funktioniert es :-)
Sensor ist in fhem sichtbar und die Werte (derzeit zumindest die vom BMP180 - jedoch noch nicht die vom helligkeitssensor - aber da muss ich erstmal meine Schaltung prüfen).
Vg
Chris
Hallo,
ist die Version 0.15 jetzt stabil ? Es gab da doch Probleme. Macht es Sinn von 0.14 auf 0.15 zu wechseln ? Wo sind die Unterschiede ?
Gruß Christoph
Hallo Zusammen,
Zitat von: Dirk am 23 Oktober 2015, 18:29:08
Dafür kann der Sensor jetzt aber auch, für die Freunde der Füllstandsmessung, experimentell Entfernungen messen.
Ich habe den Universalsensor bzw. die 0.15er Firmware jetzt fit gemacht, dass man diesen jetzt auch als Entfernungsmesser benutzen kann.
Das Ganze ist zwar noch experimentell. funktioniert hier aber recht gut.
Da diese Thread hier schon recht lang ist, habe ich dafür mal einen eigenen Thred gestartet:
http://forum.fhem.de/index.php/topic,42850.0.html
Zitat von: Bennemannc am 24 Oktober 2015, 08:33:10
ist die Version 0.15 jetzt stabil ? Es gab da doch Probleme. Macht es Sinn von 0.14 auf 0.15 zu wechseln ? Wo sind die Unterschiede ?
Bis auf den Burst-Mode, den man nicht einschalten sollte, funktioniert die Version 0.15 stabil.
Ein Update solltest du machen, wenn du den Sensor mit einem HM-CC-RT-DN Pairen möchtest.
Der Changelog von 0.15
- Improve / Fix debugging.
- Fix #16 so peering with HM-CC-RT-DN should stable now.
- Add hysteresis for battery voltage measurement.
- Experimental support for US-100 ultrasonic distance sensor (Do not use this experimental feature if you need the peering with HM-CC-RT-DN at this time)
Viele Grüße
Dirk
(kopfkratz)...
Kommen die Sensoren von Dirk eigentlich mit einer installierten Firmware oder muss ich die erst installieren? Bei mir blinkt beim Enlegen der Batterien die LED (edit) 7x kurz und schnell, bei einem Druck auf den Konfigtaster passiert aber gar nix. Dementsprechend pairt auch nix.
Bis ich die 133 Seiten nachgelesen habe, ist das Wochenende da ;)
also bei mir war eine firmware drauf - damals noch 0.12 oder so. Da noch kein OTA Bootloader drauf war, musste ich den einmal an der RASPI anlöten. Dann habe ich 0.14 aufgespielt ( wegen den millis bug) seitdem laufen die super.
Mit dem pairen hatte ich auch Problem - habe auch pairSerial versucht und irgendwann hat es geklappt.
Gruß Christoph
Merci. Ist die Seriennummer die auf dem Batteriehalter ("UWS0931763"?) Daneben klebt "OTAU 0.7.0". Würde ja mal ein OTAU versuchen, aber vielleicht mache ich da noch mehr kaputt...
Zitat von: Pfriemler am 26 Oktober 2015, 21:35:12
Kommen die Sensoren von Dirk eigentlich mit einer installierten Firmware oder muss ich die erst installieren? Bei mir blinkt beim Enlegen der Batterien die LED (edit) 7x kurz und schnell, bei einem Druck auf den Konfigtaster passiert aber gar nix.
Mit dem 7x blinken meldet sich der Bootloader. Das ist in diesem Fall seine Versionsnummer.
Drück den Taster mal etwas fester. Dann sollte die led blinken.
Gruß
Dirk
Korrelation gefunden. Gibt es eine maximale Leitungslänge für das Breakout-Board? Habe den SHT10 mit 38 cm Fernmeldekabel angepinnt. Löte ich den ab, pairt er sofort.
Hallo,
was hast Du mit dem Mantel gemacht ? Wenn die Abschirmung nicht stimmt, kann das zu Funkproblemen / Einkopplungen kommen. Immerhin arbeiten wir ja mit Elektomagnetischen Feldern.
Gruß Christoph
oh sorry ... is gar kein Fernmeldekabel. Einfach vier Adern. Keine Schirmung.
Das Breakoutboard ist doch per I2C angebunden. Ist das so zickig? Sollte ich ein anderes Kabel nehmen?
Es kann auch kürzer ausfallen, 15 cm würden reichen.
Ich habe zwar bisher auch nur 10-15 cm überbrückt, aber ein geschirmtes Kabel kann nicht schaden. Die Anschlussbelegung vom Kabel passt? Wenn der I2C-Bus gestört wird, dann initialisieren beim Start ggf. die anderen Sensoren nicht richtig. Dann bleibt die Firmware beim Start hängen. Kommt also nicht über den Bootloader hinaus.
Nach dem Bootloader blinkt der Sensor noch mal 3 mal. Das zeigt den erfolgreichen Start an.
Zitat von: Pfriemler am 26 Oktober 2015, 22:15:43
Das Breakoutboard ist doch per I2C angebunden.
Jain. Der SHT10 spricht kein echtes I2C. Der hat ein eigenes Protokoll. Das kann aber parallel zum I2C, welches der Luftdruck- und Helligkeitssensor spricht, über die selben Leitungen laufen.
Erst mal läuft der Sensor einwandfrei. Ich teste es morgen mal mit anderen Kabeln und Längen. Belegung habe ich 3x überprüft...
Hallo Dirk,
ZitatDa war tatsächlich ein unbemerkter Bug im Code. Das Sollte jetzt funktionieren. Bitte auch das Subrepo mit der Lib aktualisieren.
auch ich habe es endlich geschafft. Jetzt funktioniert auch mein Sensor. :-)
Vielen Dank
Viele Grüße
Helmut
Zitat von: Pfriemler am 26 Oktober 2015, 22:38:49
Erst mal läuft der Sensor einwandfrei. Ich teste es morgen mal mit anderen Kabeln und Längen. Belegung habe ich 3x überprüft...
3x hat nicht gereicht. Aber lassen wir das jetzt...
Inzwischen hängt das Breakout mit dem SHT10 kopfunter insekten- und tropfwassergeschützt in einer Pillendose an einem geschirmten 50-cm-Kabel unter dem UWS - und funzt einwandfrei. Auf diese Weise kann ich den Außensensor in die pralle Sonne bauen und der Temperatur- und Feuchtesensor hängt schattig und gut belüftet.
Hallo Pfriemler
Magst Du eventuell mal ein Foto posten!? Mein Breakout-Board hat es wohl gehimmelt, da ich nur eine kleine Kunststofftuete genommen hatte. Diese ist dann unbemerkt vom Sturm entfernt worden!
Danke und Gruss
Christoph
Gern.
Das Kabel sitzt stramm im Boden der Dose und auch in diesem transparenten Einsatz. Eigentlich sollte alles außen bleiben bzw. innen am transparanten Einsatz ablaufen. Der wiederum sitzt im Deckel der Dose stramm. Das große Loch ist mit Fenstergaze abgeklebt gegen die Viecher, trotzdem ist das Loch groß genug für einen schnellen Lufttausch. Was am Einsatz außen noch herabläuft, kann durch die kleinen Löcher ringsrum weg.
Ob's hält wird sich noch zeigen.
Zitat von: pc1246 am 30 Oktober 2015, 08:20:06
Mein Breakout-Board hat es wohl gehimmelt, da ich nur eine kleine Kunststofftuete genommen hatte. Diese ist dann unbemerkt vom Sturm entfernt worden!
Meinste der Chip ist wirklich hin? gut trocknen lassen?
Hallo
Nein der Chip war nicht hin, es laeuft jetzt wieder. Eine Lötstelle war von mir nicht so professionell ausgefuehrt. Das habe ich jetzt gerichtet und nun laeuft er wieder! :D
Gruss Christoph
Hallo zusammen,
ich bin dabei mir einen Universalsensor zusammen zu bauen und möchte diesen in meine HomeMatic Steuerung einbinden.
Folgende Produkte wurden ausgewählt:
• CC1101 Wireless Modul
• SHT10 Digital Temperatur-Feuchtigkeits-Sensor
• Arduino kompatibles ATmega Pro Mini / 3.3V, 8MHz / ATmega328
http://www.amazon.de/Arduino-kompatibles-ATmega-Mini-ATmega328/dp/B00H9CVQDW/ref=sr_1_1/275-4323989-2120558?ie=UTF8&qid=1447404992&sr=8-1&keywords=arduino+pro+mini
Folgendes habe ich bereits getan:
Firmware auf den Microcontroller per USBasp geflasht
,,C:\ISP-Flash-Tool...\flash.cmd usbasp WetterSensor+AskSinBootloader_HB-UW-Sen-THPL.hex F1:01 AB:CD:EF UWS1234567" -> erfolgreich
Zusammenbau des Arduino dem Sensor und das CC1101 Modul
Mein Problem ist, dass sich der Universalsensor nicht mit meinem System Homematic oder auch FHEM verbindet. Das Add-On für HomeMatic habe ich bereits hinzugefügt. Habe ich eventuell noch irgendwelche Widerstände vergessen ? Muss ich den Controller vor dem Koppeln resetten ?
Ich hoffe ihr könnt mir weiterhelfen. Anbei noch der Schaltplan
Viele Grüße
Effe
Hallo Effe,
Gibt der Sensor denn schon irgendwelche Blinkcodes aus?
Die LED gegen GND mit ca. 1,5K Vorwiderstand kommt an D4.
Und der Configtaster kommt gegen GND an D8.
Ohne den Taster kannst du den Sensor nicht anlernen.
Schließe auch noch je einen 4,7K Widerstand an S und D vom SHT10 gegen VCC an.
Du kannst auch einen anderen "ähnlichen" Widerstandswert probieren.
Ansonsten kann es sein, dass der I2C-Bus nicht richtig Initialisiert und der Sensor bleibt beim Start "hängen" bleibt.
Der Arduino den du verwendest ist auch ein 3,3V-Arduino. Denn die Eingänge vom CC1101 sind nicht 5V tolerant.
Viele Grüße
Dirk
Hallo Dirk,
vielen Dank für die schnelle Antwort. Den Taster muss ich dann noch anbringen. Habe vermutet dass ich diesen über eine Seriennummer manuell anlernen kann.
Der Arduino ist ein 3,3 V und ich habe zwei AA Batterien angeschlossen die mein Universalsensor versorgen.
Beide LED`s auf dem Arduino leuchten durchgängig rot.
Ich werde die Schaltung optimieren und mich nochmal im Anschluss hier im Forum melden.
Besten Dank nochmal :))
Hallo zusammen,
seit einigen Tagen bin ich stolzer Besitzer zweier Universalsensoren von Dirk.
Vielen Dank an Dirk und alle weiteren Kollegen, die bei der Entwicklung der Sensoren mitgewirkt haben. Das ist wirklich ein Klasse Produkt. :D :D
Bei meinem Außensensor habe ich die Schutzfolie eingebracht, um ein Übersteuern des Lichtsensors zu vermeiden. Ich möchte Euch nun mit einer Anfängerfrage nerven. Bitte entschuldigt vorab. :-[
Ich möchte mit dem -um die Dämpfung korrigierten- Helligkeitswert aus dem Reading weiter arbeiten, um diesen zu ploten und später einmal die Beschattung meiner Rolladen zu steuern.
Ich habe dazu einen Dummy erstellt, um den korrigierten Helligkeitswert aufzunehmen. Per nachfolgendem Notify übertrage ich die Werte in den Dummy.
Ga.Sensor.aussen:luminosity:.* {my $lum =(ReadingsVal("Ga.Sensor.aussen","luminosity",""));; my $lux = $lum/0.265;; fhem ("set Ga.Sensor.aussen.Lu $lux")}
Leider habe ich Probleme mit der Berechnung des Wert, da der Wert des Readings nicht nummerisch ist. Ich erhalte im Log immer Fehler mit dem Hinweis "Argument isn't numeric". :'(
Was mache ich falsch? Gibt es ggf. einen anderen Weg als über den Dummy, um das Reading direkt zur Weiterverarbeitung per Plot usw. anzupassen.
Vielen Dank für Eure Unterstützung.
Gruß
Christian
bei meinem innensensor sind die werte numerisch. poste mal ein list.
wenn wirklich nicht numerisch, ersetze "ReadingsVal()" durch "ReadingsNum()".
Hallo,
bei mir ist das auch nummerich - mache doch mal die letzten "" im Readingsval weg und setze da eine 0 - ohne etwas rein. Es könnte sein, das der Interpreter das sonst als string interpretiert.
Ich rechne da nichts zurück - bis jetzt schalte ich damit nichts, und wenn doch dann setze ich eben den gemessenen Wert ein. Der Sensor ist ja nicht wirklich kalibriert und ob die Folie genau sitzt ? Somit habe ich mit das einfach gespart.
Gruß Christoph
Hallo zusammen,
vielen Dank für Eure Hilfe.
Es war der Leerstring "" als default. Mit 0 hat es nun geklappt.
Gruß
Christian
Ich bin seit etlichen Monaten stolzer Besitzer eines Uni-Sensor von Dirk.
Das Teil funzt wunderbar.
Danke an Dirk.
Ich würde das gute Stück ( 02. 33,00 € Funk-Innensensor, Batterie mit Temperatur / Feuchte, MAX1724, Gehäuse weiß) nun gern mit einigen 1-Wire-Sensoren erweitern.
Laut Wiki soll dies grundsätzlich ziemlich problemlos gehen. Aber auch mit dem Modell?
Soviel ich rausbekommen habe, muss ich dazu eine andere Firmware flashen.
Ist das inzwischen vielleicht auch mit nem HMLAN möglich?
Was anderes habe ich nämlich nicht am Start, bisher gab es da einfach keinen Grund für.
Flashen über den Raspberry soll auch gehen, gibt es dazu zufällig schon ein HowTo bzgl der verwendeten GPIO Pins?
Wieviele Sensoren werden vernünftig nutzbar sein?
Muss/sollte ich die Sensoren extern mit Spannung versorgen?
Danke,
vb
Hallo,
also den bootloader habe ich schon einmal mit einem Raspberry aufgespielt - das gab es eine Anleitung die ich aber auf die Schnelle nicht finde :(
Grundsätzlich ist der HMLAN "konstruktionsbedingt" nicht in der Lage ein FW Update zu übertragen. Bei dem Übertragen wird die Geschwindigkeit umgestellt - das kann der Adapter nicht.
Gruß Christoph
Edit: in einem guten Haushalt geht nichts verlohren :) so habe ich das damals gemacht http://www.lxccu.com/hb-raspberry-bootloader-update
Zitat von: Bennemannc am 08 Dezember 2015, 20:23:29
Hallo,
also den bootloader habe ich schon einmal mit einem Raspberry aufgespielt - das gab es eine Anleitung die ich aber auf die Schnelle nicht finde :(
Grundsätzlich ist der HMLAN "konstruktionsbedingt" nicht in der Lage ein FW Update zu übertragen. Bei dem Übertragen wird die Geschwindigkeit umgestellt - das kann der Adapter nicht.
Gruß Christoph
Edit: in einem guten Haushalt geht nichts verlohren :) so habe ich das damals gemacht http://www.lxccu.com/hb-raspberry-bootloader-update
Cool Danke Christoph, dass werde ich dann zu Weihnachten angehen!
Ich danke auch.
Nur zu Sicherheit, nicht das ich den Sensor zerschieße...
Das funktioniert mit allen Versionen von Dirks Universalsensoren?
Hat schon jemand 1wire Sensoren im produktiven Einsatz?
Hallo,
nur um das klar zu stellen - das geht mit allen von Dirk's Sensoren - aber das ist der bootloader, also das Grundprogramm was das Startverhalten und das Laden des eigentlichen Programm's steuert. Das Programm (der Sketch selber) muss an einer anderen Speicheradresse anfangen.
Das war so gedacht, das man mit den Funktionen von fhem oder dem HM-Konfigtool zusammen mit dem HM-CFG-USB oder jetzt auch dem CUL ein Firmwareupdate per Funk übertragen kann. Ich habe das machen "müssen", die erste Generation von Dirk's Sensoren noch einen anderen Bootloader hatten, die das OTA Update nicht unterstützten.
Wenn Du den Sensor erweitern möchtest, musst Du Dich intensiv mit der Arduino IDE beschäftigen, für die neuen Sensoren Register anlegen, die Bibliotheken einbinden, die AskSin Bibliothek verstehen. das ganze Kompilieren und übertagen. Dann fhelt noch das anpassen der HM-Custom...pm in der dann die "Beschreibung" steht damit die Registerwerte in fhem auch richtig angezeigt werden.
Gruß Christoph
Danke für den Hinweis.
Erschien mir schon viel zu einfach, einfach bischen flashen und Sensor anlöten? :D
Ich muss mal auf die Liste schauen, ob es da nicht schon einen funktionstüchtigen Sensor von Dirk gab und hoffen, das er noch was macht.
Das ganze Arduniozeugs ist zwar gewiss spannend und super flexibel aber übersteigt dann doch meine Zeit und Lust mich da reinzuarbeiten.
vb
Hallo,
ich habe das schon mal mit rumgemacht - aber das Teil soll ja nacher Homematic reden, somit kommt man um die AskSin nicht herum. Von der gibt es ... also die Alte von Trilu, von Dirk für "seine" Sensoren eine gepatchte und eine "neue" Version (grade keine Ahnung von wenn). Dann erwarte Homematic einen speziellen Aufbau (Register, Platz für peers, Datenregister). Dann noch die "externen" Bibliotheken um mit den Sensoren reden zu können - und zur Krönung sehr wenig Speicherplatz auf dem Chip. Für Panstamp / Swap habe ich da mal etwas gemacht, das ist aber von der Struktur deutlich einfacher - und selbst da habe ich Stunden mit verbracht.
Von daher "Hut ab" für die Leistung derjenigen die uns da fertige Programme kostenlos zur Verfügung stellen.
Gruß Christoph
Die Leistung will ich gar nicht in Abrede stellen, da habe ich jeden Respekt vor.
Es ist ja eben nicht mit "zweimal hier, dreimal da klicken" getan.
Ich hatte den WIKI-Eintrag so verstanden, das es von Dirks Sensoren eine Version gibt, die a) Homematic spricht und b) einfach per 1wire zu erweitern ist.
Falls letzteres nicht mit anlöten der Sensoren getan ist, muss ich mir für meine Zwecke was anderes einfallen lassen.
vb
Hallo,
also mit dem anlöten der Sensoren, denke ich, ist das nicht getan. Die Kommunikation mit den Sensoren muss implemeniert werden, die AskSin muss angepasst werden, bzw. die Struktur der Gerätes muss abgebildet werden - da müssen entsprechende Register vorhanden sein. Mann will ja ggf. auch die Daten mit peers verbinden und entsprechend schalten können.
Gruß Christoph
die new AskSin versucht das ganze wie ein Baukastensystem zu gestalten - aber das, denke ich, dauert noch was bis es fertig ist.
-- was möchtest Du den messen bzw. steuern ? Eventuell ist Panstamp und SWAP interessant für Dich.
Zitat von: VB90 am 08 Dezember 2015, 19:41:56
nun gern mit einigen 1-Wire-Sensoren erweitern.
Laut Wiki soll dies grundsätzlich ziemlich problemlos gehen. Aber auch mit dem Modell?
Der entsprechende Entrag im Wiki bezoeht sich auf die RS485-Variante und der HM-Wired Firmware-Version.
Hier ist das Auslesen von 1Wire Temperatur in der FW integriert.
Die AskSin-Firmware kann das noch nicht. Obwohl ich das schon immer mal vor hatte.
ZitatWieviele Sensoren werden vernünftig nutzbar sein?
In der HM-Wired Version werden, wenn ich mich recht erinnere bis zu 10 1Wire Temperatursensoren unterstütz.
Zitat von: Bennemannc am 08 Dezember 2015, 21:44:27
aber das ist der bootloader, also das Grundprogramm was das Startverhalten und das Laden des eigentlichen Programm's steuert. Das Programm (der Sketch selber) muss an einer anderen Speicheradresse anfangen.
Das wird über die Fuses des AVR geregelt.
Normal, also ohne Bootloader beginnt das Programm (Sketch) Bei Adresse 0x0000.
Wenn die Fuses für den Bootloader gesetzt werden, Startet der AVR bei einem Reset das Programm von einer hinteren Adresse. Z.B. 0x7800.
An dieser Stelle steht dann in der Regel der Bootloader, der dann entscheidet ob der untere Speicherbereich neu beschrieben werden soll oder ob er das Hauptprogramm (Sketch) mit einem Spung zu Adresse 0x0000 Starten soll.
Sofern der Bootloader entsprechende Daten empfängt. Dabei ist es erstmal egal über welchen Weg der Bootloader die Daten empfängt. Der Arduino-Bootloader, welcher auf den ersten Sensoren drauf war, bzw. den ich immer noch auf Wunsch vorinstalliere empfängt die Daten über die serielle Schnittstelle (UART). Der Bootloader ist auch dann Empfehlenswert wenn man kein CUL, HM-LAN-USB o.ä. hat. Damit kann man den Sensor dann per USB-Serial-Adapter Updaten.
Der AskSin Bootloader empfängt die Programmdaten per Funk. In diesem Fall über das HM-Protokoll.
ZitatWenn Du den Sensor erweitern möchtest, musst Du Dich intensiv mit der Arduino IDE beschäftigen, für die neuen Sensoren Register anlegen, die Bibliotheken einbinden, die AskSin Bibliothek verstehen. das ganze Kompilieren und übertagen. Dann fhelt noch das anpassen der HM-Custom...pm in der dann die "Beschreibung" steht damit die Registerwerte in fhem auch richtig angezeigt werden.
Da würde ich mich freuen wenn hier jemand an der Firmware mit entwicken würde. :) Da würde ich auch unterstützen.
Zitat von: Bennemannc am 08 Dezember 2015, 22:16:39
Von der gibt es ... also die Alte von Trilu, von Dirk für "seine" Sensoren eine gepatchte
Ich hatte hier einiges optimiert und ein paar "unschöne" Bugs behoben.
Zitatund eine "neue" Version (grade keine Ahnung von wenn).
Die kommt auch von Trillu. Und auch hier konnte ich meine Finger nicht raushalten :)
Hab da AES inzwischen eingebaut und es ist geplant die Sensor-Firmware auf die neue Lib zu portieren. Das dauert vermutlich aber noch etwas.
Zitat von: VB90 am 08 Dezember 2015, 22:23:49
Ich hatte den WIKI-Eintrag so verstanden, das es von Dirks Sensoren eine Version gibt, die a) Homematic spricht und b) einfach per 1wire zu erweitern ist.
Du hast hier bestimmt das "Wired" bei Homematic übersehen :)
Gruß
Dirk
Hi Dirk,
ich habe im Wiki den Universalsensor gesehen, darauf hin hier nachgefragt wo man den bekommt
http://forum.fhem.de/index.php/topic,45414.0.html
und wurde dann auf den Thread hier verwiesen.
Ich hätte da gerne was (1 mal Außen / 1 mal Innen) bestellt, kannst Du Dich mal bitte mit den Konditionen per PN melden ?
Sind die dann komplett mit Gehäuse so wie hier ?
(http://www.fhemwiki.de/w/images/1/16/Universalsensor-CC1101-Innen.jpg)
(http://www.fhemwiki.de/w/images/3/3e/Universalsensor-CC1101-Aussen.jpg)
Hi,
Zitat von: Dirk am 09 Dezember 2015, 11:37:39
Der entsprechende Entrag im Wiki bezoeht sich auf die RS485-Variante und der HM-Wired Firmware-Version.
Ich glaube, dass er sich schon auf das hier bezieht: http://www.fhemwiki.de/wiki/Universalsensor (http://www.fhemwiki.de/wiki/Universalsensor)
Dort steht unter Anderem:
Zitat
Über diese Erweiterungsports können zusätzlich eigene Sensoren oder auch Aktoren angeschlossen werden. Über eine entsprechende Firmware ist es z.B. möglich auch mehrere 1-Wire-Sensoren abzufragen und deren Werte zu übertragen.
Gruß,
Thorsten
@Afterburner
Ich hab dir eine Nachricht geschickt.
Zitat von: Thorsten Pferdekaemper am 09 Dezember 2015, 18:21:24
Hi,Ich glaube, dass er sich schon auf das hier bezieht
Da kannst natürlich recht haben.
Das ist tatsächlich etwas missverständlich beschrieben. Werde das gleich mal berichtigen.
Gruß
Dirk
Hallo,
erst mal ein dickes Danke an Dirk für seinen Sensor.
Hab ih n erfolgreich an meine Zentrale angelernt.
Kann mir einer sagen wie ich nun Werte heraus bekomme?
Als Firmware findet man in den attr 0.14.
Bei State steht RESPONSE TIMEOUT:RegisterRead
Edit:
Hab den Sensor jetzt noch mal neue Angelernt.
Gruß Robert
Hi Robert,
hat du die HMConfig_SenTHPL.pm ins FHEM-Verzeichniss kopiert?
Siehe: http://www.fhemwiki.de/wiki/Universalsensor#Inbetriebnahme
Gruß
Dirk
Hi Dirk,
naja genau das hatte ich vergessen.
Hab die Datei mal schnell installiert.
Den Sensor hab ich noch mal zurück gesetzt und neu angelernt.
Jetzt steht im FHEM unter dem Sensor folgendes (siehe Bild)
Scheint als ob er nicht richtig angelernt wurde.
R-pairCentral set_0x200DB8
Gruß Robert
Hallo Robert,
noch einmal versuchen - eventuell auch mal mit pairSerial und der Seriennummer. Bei mir hat das auch immer erst bein zweiten oder dritten mal geklappt. Aber dann läuft das Teil sauber und stabil durch.
Gruß Christoph
PS. bei pairSerial musst Du kurz danach den Configknopf am Gerät drücken.
Ich hab jetzt einfach mehr Fach hintereinander den Knopf gedrückt.
Scheint bis jetzt so zu gehen. Cmd-Pending sieht man nicht
Mehr drin stehen. Ich werde das mal beobachten.
Ich hab jetzt einfach mehr Fach hintereinander den Knopf gedrückt.
Scheint bis jetzt so zu gehen. Cmd-Pending sieht man nicht
Mehr drin stehen. Ich werde das mal beobachten.
Geht leider nicht.
Es scheint als ob bis 8:15 daten eingegangen sind.
Danach nicht mehr.
Ich muss wenn ich wieder zuhause bin doch mal mit der Seriennummer anlernen.
Kann ich eigentlich Manuell werte Abrufen?
Hat jemand den Sensor mit einer VCCU und HMLANs im Einsatz?
Gruß Robert
Hallo Robert,
VCCU nein - HMLAN ja.
Gruß Christoph
Bei mir laufen ein Innen- und ein Außensensor problemlos über eine VCCU. Diese wählt dann zwischen einem NanoCul oder dem HMUsb Stick.
Bei mir laufen ein Innen- und ein Außensensor problemlos über eine VCCU. Diese wählt dann zwischen einem NanoCul oder dem HMUsb Stick.
Zitat von: Spezialtrick am 10 Dezember 2015, 13:04:08
Bei mir laufen ein Innen- und ein Außensensor problemlos über eine VCCU. Diese wählt dann zwischen einem NanoCul oder dem HMUsb Stick.
Wie hast du angelernt per Serial oder per Zeit?
Sollte ich vor dem neuen anlernen eigentlich ein unpair machen?
Oder einfach nur den Sensor zurücksetzten?
Gruß Robert
Hallo Robert,
keines von beiden - weder unpair noch reset. Wie schon erwähnt hat es bei keinem meiner drei Sensoren auf anhieb geklappt. Ich habe meist erst pairForSec versucht und wenn das nicht erfolgreich war pairSerial hinterher geschikt. In beiden Fällen mus der Taster am Sensor kurz betätigt werden.
Gruß Christoph
Okay, hab jetzt einfach mal mehrfach angelernt.
Ohne vorher irgendwas zu machen kein unpair, reset oder so.
In den letzten paar Minuten sind nun wieder Signale rein gekommen.
Mal abwarten was morgen früh ankommt.
Edit:
Eine Frage hab ich noch: Es waren zwei Filterfolien dabei.
Muss man beide benutzten?
eine Filterfolie reicht, ich habe den Sensor mit nur einer auf dem Dach, er hat noch nie übersteuert.
Gruß PeMue
Hat jemand ein paar Anregung für mich wo Ohr den Sensor angebracht habt? Vll. mit Bild?
Hallo,
unter dem Dachüberstand. Ich habe noch einen zusätzlichen Temp- / Hydr Sensor drin. Damit die "vernünftig" arbeiten, musste ich in das Outdoorgehäuse ein paar Löcher bohren. Deshalb habe ich es Wettergeschützt under dem Dachüberstand montiert. Klar - dadurch sind die Lichtwerte geringer als wenn das Teil die volle Sonneneinstrahlung bekommt - aber ich kann trotzdem einen Lichtwert bestimmen, ab den die Verdunkelung aktiviert wird.
Gruß Christoph
Ich muss morgen mal auf den Speicher. Haben da eine transparente Klappe die für den Schornstein Feger ist.wollte eventuell da hinten dran oder draußen an der Lücke vll.
Eventuell auch an dem velux Dachfenster.
Muss ich mal schauen gehen, wo ich am einfachsten dran komme und der Standort noch halbwegs gut ist.
Hallo no_Legend
Ich habe die drei Sensoren auch mit einer VCCU und einem HM-USB-2 am Laufen. Ich glaube ich hatte anfaenglich das gleiche Problem wie Du. Man muss zum pairen den Taster am Sensor nur kurz druecken, und das ist ja bei den meisten HM-Geraeten eher anders.
Gruss Christoph
Zitat von: pc1246 am 11 Dezember 2015, 12:15:43
Hallo no_Legend
Ich habe die drei Sensoren auch mit einer VCCU und einem HM-USB-2 am Laufen. Ich glaube ich hatte anfaenglich das gleiche Problem wie Du. Man muss zum pairen den Taster am Sensor nur kurz druecken, und das ist ja bei den meisten HM-Geraeten eher anders.
Gruss Christoph
Das mit dem Kurz war nicht mein Problem, hatte ich bereits so gemacht.
Ich hab ihn obwohl der Sensor bereits angelernt war einfach mehrfach angelernt.
Bis jetzt scheint er ohne aussetzer zu funktionieren.
Zitat von: no_Legend am 10 Dezember 2015, 22:27:09
Hat jemand ein paar Anregung für mich wo Ohr den Sensor angebracht habt? Vll. mit Bild?
Voilá:
(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=41928;image)
Das Alu-Blech ist mit zwei versenkten Schrauben am Sensorgehäuse befestigt.
Gruß PeMue
Hallo PeMue,
Danke für das Bild habe meine sensor eben auch montiert. Ja auch am Sonntag wird bei mir gearbeitet.
Habe mir auf Aluminium einen Winkel gebogen und diesen an einem velux ssl Solar Rollladen befestigt.
Die Antennen habe ich unter der Folie gelassen und so verlegt dass sie dem Sensor möglichst wenig in die Quere kommt.
Der Abstand zum HMLAN ist nicht wirklich groß (Luftlinie max 4m) weshalb nicht von Empfangsproblemen ausgehe.
Schauen wir mal ob meinen Konstruktion auf Dauer hält!
Edit:
Wenn Ihr die Folie benutzt, habt ihr dann dafür einen Dummy angelegt um die Richtigen Werte zu bekommen?
Oder kann FHEM diese auch direkt im state des Devices berechnen?
Gruß Robert
Zitat von: no_Legend am 13 Dezember 2015, 11:27:16
Die Antennen habe ich unter der Folie gelassen und so verlegt dass sie dem Sensor möglichst wenig in die Quere kommt.
Wenn Ihr die Folie benutzt, habt ihr dann dafür einen Dummy angelegt um die Richtigen Werte zu bekommen? Oder kann FHEM diese auch direkt im state des Devices berechnen?
Hallo Robert,
also war's heute nichts mit Kirche ???
Ich habe die Antenne über die Folie gelegt, da ich den Eindruck habe, sie könnte leitfähig sein.
fhem wertet die durch die Folie gedämpften Werte aus, wenn Du den Wert in Lux haben willst, brauchst Du ein userreading. Dirk hat meine ich im Wiki den Faktor rausgelegt.
Gruß Peter
Zitat von: PeMue am 13 Dezember 2015, 16:05:45
Hallo Robert,
also war's heute nichts mit Kirche ???
Ich habe die Antenne über die Folie gelegt, da ich den Eindruck habe, sie könnte leitfähig sein.
fhem wertet die durch die Folie gedämpften Werte aus, wenn Du den Wert in Lux haben willst, brauchst Du ein userreading. Dirk hat meine ich im Wiki den Faktor rausgelegt.
Gruß Peter
Denk Faktor habe ich gefunden.
Mit den Userreadings hatte ich bisher noch nichts am hut.
Ich schau mal wie weit ich komm.
Hab es hin bekommen, habe es gleich im Wiki ergänzt
Was ist Eigentlich der maximal wert des Sensors?
Ich meine das sind 40.000 Lux.
Gruß
Dirk
ich würde auch gerne 2 davon haben :-)
Zitat von: Wuppi68 am 14 Dezember 2015, 20:23:22
ich würde auch gerne 2 davon haben :-)
Schrieb Dirk ne PM
@Dirk
Hatte heute schon 25.000 (25k) stehen.
Hab eine Folie drin. Hab schon gedacht ist ne Messfehler.
Aber bei 40k ist ja noch alles in Butter.
Hallo Robert,
ich hatte heute als Maximalwert 28500 lux, also alles ok bei Dir.
Gruß Peter
Habe das Wiki korrigiert:
aus STH10 habe ich SHT10 gemacht, dann findet man auch die Teile im Internet :-)
Danke für den Riesen Einsatz für den Sensor
Habe mich versucht hier im Thread und im Wiki schlau zu machen, aber so richtig bin ich noch nicht durchgestiegen.
Ich habe momentan eine 1-wire Lösung an einem Pi mit 5 Sensoren.
Würde aber gerne auf die hier (bzw. im Wiki) vorgestellte Lösung umsteigen.
Also 1-wire per HBW-1W-T10 über RS485 an meine CCU2 anbinden.
Ebenso interessiere ich mich auch für einen Universal-Außensensor um Temperatur, Luftdruck, Feuchtigkeit und Helligkeit per Funk einzubinden.
Ich blicke aber nicht durch was ich genau wofür brauche und wo (bei wem ?) ich anfragen und bestellen kann ?
Zitat von: ralalla am 13 Januar 2016, 13:03:27
Würde aber gerne auf die hier (bzw. im Wiki) vorgestellte Lösung umsteigen.
Also 1-wire per HBW-1W-T10 über RS485 an meine CCU2 anbinden.
Ich blicke aber nicht durch was ich genau wofür brauche und wo (bei wem ?) ich anfragen und bestellen kann ?
Hi,
schau Dir dazu mal diesen Thread hier an: http://forum.fhem.de/index.php/topic,22952.0.html (http://forum.fhem.de/index.php/topic,22952.0.html). Ausserdem im Wiki http://www.fhemwiki.de/wiki/HBW-1W-T10 (http://www.fhemwiki.de/wiki/HBW-1W-T10). Manche der Informationen sind zwar veraltet, aber da wuerde ich an Deiner Stelle mal anfangen.
Es gibt dazu noch nicht wirklich etwas Fertiges. Wenn Du Dich aber wirklich dafuer interessierst, dann mach mal einen neuen Thread dazu auf. Mal sehen, was wir da zusammenbekommen.
Gruss,
Thorsten
Servus Zusammen,
Ich habe Interesse ein paar Universalsensoren käuflich zu erwerben - an wen muss ich mich hierfür wenden?
Oder meldet sich der Betreffende selbst bei mir per PN? ;-)
Viele Grüße,
Sebastian
Hallo zusammen,
mir geht es da wie meinem Vorredner ;-)
Ich habe ebenfalls Interesse ein paar Universalsensoren käuflich zu erwerben. Wie muss ich das anstellen?
Besten Dank & Grüße,
Markus
@canta und phlash
Ich hab euch eine Nachricht geschickt.
Viele Grüße
Dirk
Zitat von: Dirk am 21 Januar 2016, 22:45:44
@canta und phlash
Ich hab euch eine Nachricht geschickt.
Viele Grüße
Dirk
Hallo Dirk
ich hätte ebenfalls Interesse an einem Universalsensor (Bausatz wäre auch OK).
Vielen Dank im Voraus
MfG Stephan
Hallo Dirk,
ich bin schon länger auf der Suche nach Sensoren in dieser Art. Insofern habe ich natürlich auch großes Interesse an diesem Universalsensor.
Tolle Arbeit - Respekt!
Grüße
Klaus
Hallo Dirk,
Ich häng mich mal hier dran. Ich hätte ebenfalls Interesse an diesem universalsensor ( vor allem das mit fern Helligkeitswerten ist interessant).
Kann ich den bei Dir käuflich erwerben?
Gruß
Jens
Hallo,
Ich habe gestern versucht meinen Sensor vom seriellen zum OTA Bootloader umzuprogrammieren.
Anleitung nach: http://www.lxccu.com/hb-raspberry-bootloader-update
Sensor ist einer der ersten von Dirk, noch mit der Seriennummer *Default* und ID ABCDEF
Ich hatte das alles übernommen, aber irgendwie meldet er sich nicht mehr. Muss ich mehr machen?
Oder noch die eigentliche Firmware drüber?
Ich bin etwas ratlos. Müsste aber auch noch alle anderen Sensoren flashen, da diese den Bootloader mit dem Bug haben, das die Übertragung abbricht, beim Update.
Nico
ZitatOder noch die eigentliche Firmware drüber?
jetzt ota die fw drauf.
edit: ich glaube dirk hatte auch ein tool, um bootloader
und fw (inkl einstellung von hmid und seriennummer) in einem rutsch über kabel zu flashen. sollte hier im thread stehen. ;)
Hallo
@StephanK, anomios, Jens_B
Irgendwie hab ich die Benschrichtigungen übersehen.
Daher hab ich erst heute geantwortet.
Zitat von: santalaus am 29 Januar 2016, 11:16:29
Ich bin etwas ratlos. Müsste aber auch noch alle anderen Sensoren flashen, da diese den Bootloader mit dem Bug haben, das die Übertragung abbricht, beim Update.
Bist du da weiter gekommen.
Ansonsten kann ich dir die Teile auch updaten.
Falls du nach Karlsruhe kommst, dann könnte ich das auch vor Ort machen.
Zitat von: frank am 29 Januar 2016, 11:32:56
ich glaube dirk hatte auch ein tool, um bootloader und fw (inkl einstellung von hmid und seriennummer) in einem rutsch über kabel zu flashen. sollte hier im thread stehen. ;)
Das sollte im Github mit liegen.
Gruß
Dirk
Hallo,
nein, mangels Zeit bin ich nicht weiter. Ich hoffe heute Abend. Karlsruhe werde ich Temrinlcih nicht schaffen, danke für das Angebot.
Ich denke das Problem ist, das ich das Script von lxccu genommen habe. Im gitHub hatte mich Version 0.12 gestört ;) Die werde ich aber mal testen.
Edit: Ich werde das nochmal einige Tage nach hinten stellen. Melde mich ggf wieder.
Nico
Hallo zusammen,
seit Wochen setze ich zwei Sensoren (außen und innen) von Dirk ein und muss einfach noch einmal sagen: Einfach top ! :)
Ich habe noch eine Frage. Ich hatte das FHEM-Modul "HMConfig_SenTHPL.pm" manuell eingebunden, nachdem ich es von der hier im Thread aufgeführten URL heruntergeladen habe.
Ich frage mich nun, ob das immer so bleiben muss, oder ob das Modul in der Zwischenzeit (FHEM 5.7 ??) im "Standard" aufgenommen wurde.
Derzeit erhalte ich beim Start immer noch den Hinweis:
"additional HM config file loaded: ./FHEM/HMConfig_SenTHPL.pm"
Was meint Ihr.
Vielen Dank und Gruß
Christian
Hallo Christian,
ob das mal Einzug in Fhem nehmen wird entscheidet Rudi. Martin hat damals für dieses und den umprogrammierten Unterputzschalter eine Schnittstelle in das HM Modul gebaut. Theortisch ist es ja möglich, mit der Asksin beliebige Geräte zu bauen. Die Gerätebescheibung - und nichts anderes ist die Datei - können somit sehr individuell ausfallen. Deshalb denke ich, das sie in das standart Fhem nicht hineingehören.
Gruß Christoph
Hallo,
nachdem ich einen Tag verbraten habe auf meinem selbstgelöteten Sensor den OTA Bootloader einzuspielen, weil die Anleitung auf der Seite http://www.lxccu.com/hb-raspberry-bootloader-update leider nicht funktionierte, hab ich nochmal den Forumsthread durchgraben und nun auch gelesen, dass diese Möglichkeit einen Fehler in der hex2bin haben kann. (http://forum.fhem.de/index.php/topic,20620.msg273380.html#msg273380 ff.)
Bei mir ging das Flashen des Bootloaders auf einem Raspi B+ zuerst mit einem OK durch, nur blinkte die LED nicht, so dass ich erst einmal den Fehler auf der Platine gesucht habe und alles mögliche probiert habe.
Dann suchte ich nochmal im Thread und fand den Hinweis, das es nicht so funktioniert.
Mit dem Setzen der Fuse-Bits:
bin/avrdude -p m328p -P gpio -c gpio -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m -e -Uflash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:i
hat dann das Modul angefangen zu blinken. Yeppee!
Danach konnte ich mit der default Seriennummer HB0Default auch über OTA mit meinem nanoCUL flashen und fhem hat den Sensor eingefügt.
Ich habe dazu noch 2 Anmerkungen.
- Bitte ins Wiki die Anleitung einfügen für das Flashen des OTA-Bootloaders und des seriellen Bootloader (wie Pemue hier beschrieben http://forum.fhem.de/index.php/topic,20620.msg281813.html#msg281813)
- Was genau ist die HM-ID? Einfach frei wählbar nach dem Format AB:CD:EF?
Hat schon jemand ein flash-Script für Linux geschrieben? Analog zu https://github.com/kc-GitHub/Asksin_OTA_Bootloader/blob/master/Tools/Flash-Tool-Windows/flash.cmd (betateilchen?)
Ich finde die Variante mit dem Raspi zu flashen sehr elegant. Man kann den Bootloader flashen und im Nachgang die Firmware.
Vielen Dank und Gruss Thomas
Hallo,
Zitat- Was genau ist die HM-ID? Einfach frei wählbar nach dem Format AB:CD:EF?
Außer der Seriennummer haben die Devices bei HM eine eigene (einzigartige) ID. Diese ID wird im Funkprotokoll zur Addressierung genutzt. Wie schon gesagt, darf diese ID nur einmal vorkommen - also bei zwei Geräten kann das zweite nicht mehr AB:CD:EF haben. Die Werte sind Hexadezimale Werte - also alles von 0-9 und A-F.
ZitatHat schon jemand ein flash-Script für Linux geschrieben?
Meinst Du um die Firmware OTA zu flashen ? Das ist Bestandteil des "hmland" - also der Software die den HM-CFG-USB als Netzwerkes-Funkinterface für fhem bereitstellt.
Ich habe damals nur dne Bootloader serial geflash. Die Firmware habe ich OTA übertragen, weil ich wissen wollte ob der Bootloader wie gewünscht funktioniert.
Gruß Christoph
ZitatIch habe damals nur dne Bootloader serial geflash.
Wie hast du das gemacht? Mit USBasp v2.0 oder Raspberry Pi? Windows, Linux?
Gruss Thomas
Hallo,
Raspberry Pi, Kabel angelötet und mit avrdude den Bootloader draufgeflasht.
Gruß Christoph
Hallo Dirk,
ich hätte Interesse an den Universalsensor. Gibt es diese noch zu erwerbe?
Wenn ja, wie und wo?
MfG
Andreas
Hallo Christian,
Zitat von: cseuss am 03 Februar 2016, 19:17:53
Ich habe noch eine Frage. Ich hatte das FHEM-Modul "HMConfig_SenTHPL.pm" manuell eingebunden, nachdem ich es von der hier im Thread aufgeführten URL heruntergeladen habe.
Ich frage mich nun, ob das immer so bleiben muss, oder ob das Modul in der Zwischenzeit (FHEM 5.7 ??) im "Standard" aufgenommen wurde.
Da bin ich noch nicht sicher obich das in FHEM direkt comitten soll. Da das ja nur die Sensoren betrifft.
Ich werde am Samstag mal mit Rudi sprechen und schauen was er dazu meint.
Ich habe jetzt aber schon mal ein Control-File gebaut, so dass sich das Modul nun auch direkt von FHEM aus updaten lässt:
Dazu reicht dann ein
update HMConfig_SenTHPL.pm https://raw.githubusercontent.com/kc-GitHub/Wettersensor/master/Contrib/control-fhem.txt
und anschliessend ein
shutdown restart@ALL
Es gab die letzten Tage noch die eine oder andere Anfrage nach den Sensoren.
Ich hatte leider einiges zu tun. daher kam die Antwort wieder mal verzögert.
Ich hoffe ich habe keinen vergessen. Falls doch, bitte nicht böse sein. Einfach noch einmal kurz eine Nachricht an mich.
Viele grüße
Dirk
Hallo,
Ich habe Interesse einen Universalsensor zu erwerben - an wen muss ich mich hierfür wenden?
Martin
Hallo Zusammen,
ich habe gestern Abend meinen ersten Universalsensor selbst gelötet (Es fehlen lediglich noch die Sensoren). Daraufhin habe ich heute nach dieser Anleitung von Dirk
http://forum.fhem.de/index.php/topic,20620.msg208682.html#msg208682 (http://forum.fhem.de/index.php/topic,20620.msg208682.html#msg208682)
den OTA Bootloader 0.7.0 und die Firmware 0.11 mittel USBasp aufgespielt. Offenbar war ich erfolgreich, da der Sensor schon mal von FHEM erkannt und auch angezeigt wird, siehe Foto.
Nun versuche ich schon seit paar Stunden die aktuelle Firmware per OTA auf Sensor aufzuspielen. Leider ohne Erfolg. Nach einigen "Missing ACK!" bricht der Vorgang ab:
root@cubietruck:/opt/hmcfgusb# sudo ./flash-ota -f HB-UW-Sen-THPL_update_V0_14_001_150301.eq3 -s UWS8788112
HomeMatic OTA flasher version 0.097-git
Reading firmware from HB-UW-Sen-THPL_update_V0_14_001_150301.eq3...
Firmware with 224 blocks successfully read.
Rebooting HM-CFG-USB to avoid running out of credits
HM-CFG-USB not in bootloader mode, entering bootloader.
Waiting for device to reappear...
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB in bootloader mode, rebooting
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB opened
HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial UWS8788112
Device with serial UWS8788112 (hmid: 044db1) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 224 blocks: 0001/0224 /
Missing ACK!
Flashing 224 blocks: 0001/0224 /
Missing ACK!
Flashing 224 blocks: 0001/0224 /
Missing ACK!
Flashing 224 blocks: 0001/0224 /
Missing ACK!
Flashing 224 blocks: 0001/0224 /
Missing ACK!
Too many errors, giving up!
Es macht übrigens keinen Unterschied, ob ich den Sensor unmittelbar am HM-Usb-Stick platziere oder weiter entfernt. Kann sich jemand das Verhalten erklären? Mache ich irgendeinen Fehler?
Hallo Dirk,
ich hätte auch Interesse an den Universalsensor(Außen) und würde gerne einen oder zwei erwerben.
Mit freundlichen Grüßen
Volkmar
ZitatEs macht übrigens keinen Unterschied, ob ich den Sensor unmittelbar am HM-Usb-Stick platziere oder weiter entfernt. Kann sich jemand das Verhalten erklären? Mache ich irgendeinen Fehler?
einen mindestabstand von ca 1m solltest du trotzdem einhalten.
den hmland hast du vorher gestopt?
ich würde das flashen mal mit dem nanocul sniffen, um zu "sehen", was da los ist. den müsstest du allerdings vorher auf 100k mode schalten.
Den Mindestabstand habe ich eingehalten und auch HMland habe ich vorher abgeschalten und FHEM ebenfalls.
Einen fertigen Sensor von Dirk konnte ich ebenfalls ohne Probleme flashen.
Für das Sniffen darf nicht die Alternative FW auf dem Cul sein oder? Wie gehe ich da im Allgemeinen vor? Geschnifft habe ich bisher nicht. :D
Edit: Lasst sich ein Sensor mit dem OTA Bootloader auch noch per Kabel bespielen?
ZitatEinen fertigen Sensor von Dirk konnte ich ebenfalls ohne Probleme flashen.
also selbes procedere. bootloader + v11 per kabel und dann v14 ota?
ZitatFür das Sniffen darf nicht die Alternative FW auf dem Cul sein oder? Wie gehe ich da im Allgemeinen vor? Geschnifft habe ich bisher nicht. :D
eigentlich nur verbose 4 beim cul und am besten global verbose 1. a-culfw sollte es auch können, einfach probieren. umschalten 100k mode
set cul raw ARzurück in 10k mode
set cul raw Ar
Zitat von: frank am 29 Februar 2016, 19:32:45
also selbes procedere. bootloader + v11 per kabel und dann v14 ota?
Nene ich glaube, dass da schon die 0.13 bzw 0.14 drauf war.
Sollte "set cul raw AR" eine Rückmeldung geben?
ZitatSollte "set cul raw AR" eine Rückmeldung geben?
keine ahnung.
bei 10k sollten die "normalen" homematic messages zu sehen sein und bei 100k nicht mehr.
Zitat von: frank am 29 Februar 2016, 19:04:53
ich würde das flashen mal mit dem nanocul sniffen, um zu "sehen", was da los ist.
So ich habe gerade versucht den Update Prozess zu sniffen:
2016.03.01 11:09:02 4 : CUL_Parse: nanoCUL868hm A 0F 02 20CB 395182 044DB1 105B11F815476C -20
2016.03.01 11:09:02 4 : CUL_Parse: nanoCUL868hm A 0F 02 20CB 395182 044DB1 105B11F815476B -20.5
2016.03.01 11:09:02 4 : CUL_Parse: nanoCUL868hm A 0F 02 20CB 395182 044DB1 105B11F815476B -20.5
2016.03.01 11:09:02 4 : CUL_Parse: nanoCUL868hm A 0A 02 8002 044DB1 395182 0031 -49.5
2016.03.01 11:09:02 4 : CUL_Parse: nanoCUL868hm A 2E 03 00CA 395182 044DB1 00800C944D010C94182F0C94452F0C94A7100C94CC100C94F1100C94C6210C9475010C94756B -20.5
2016.03.01 11:09:02 4 : CUL_Parse: nanoCUL868hm A 2C 03 00CA 395182 044DB1 010C9475010C9475010C9475010C9475010C9475010C9475010C9475010C94872F0C946B -20.5
2016.03.01 11:09:03 4 : CUL_Parse: nanoCUL868hm A 2C 03 00CA 395182 044DB1 75010C94142D0C94462D0C9475010C9475010C9475010C9475010C9442040C947501736C -20
2016.03.01 11:09:03 4 : CUL_Parse: nanoCUL868hm A 20 03 20CA 395182 044DB1 746174757320726571756573742C20646174613A2000616C -20
2016.03.01 11:09:03 4 : CUL_Parse: nanoCUL868hm A 20 03 20CA 395182 044DB1 746174757320726571756573742C20646174613A2000616B -20.5
2016.03.01 11:09:03 4 : CUL_Parse: nanoCUL868hm A 20 03 20CA 395182 044DB1 746174757320726571756573742C20646174613A2000616B -20.5
2016.03.01 11:09:03 4 : CUL_Parse: nanoCUL868hm A 2C 03 00CA 395182 044DB1 00800C944D010C94182F0C94452F0C94A7100C94CC100C94F1100C94C6210C9475010C6B -20.5
2016.03.01 11:09:03 4 : CUL_Parse: nanoCUL868hm A 2C 03 00CA 395182 044DB1 9475010C9475010C9475010C9475010C9475010C9475010C9475010C9475010C94872F6C -20
2016.03.01 11:09:03 4 : CUL_Parse: nanoCUL868hm A 2C 03 00CA 395182 044DB1 0C9475010C94142D0C94462D0C9475010C9475010C9475010C9475010C9442040C94756B -20.5
2016.03.01 11:09:03 4 : CUL_Parse: nanoCUL868hm A 22 03 20CA 395182 044DB1 0173746174757320726571756573742C20646174613A2000616B -20.5
2016.03.01 11:09:03 4 : CUL_Parse: nanoCUL868hm A 0A 03 8002 044DB1 395182 002E -51
2016.03.01 11:09:04 4 : CUL_Parse: nanoCUL868hm A 2E 04 00CA 395182 044DB1 00806C7469747564653A20000A007472616E736D4465765472794D61783A20000A006275726B -20.5
2016.03.01 11:09:04 4 : CUL_Parse: nanoCUL868hm A 2C 04 00CA 395182 044DB1 737452783A20000A006C65644D6F64653A20000A006C6F774261744C696D69743A20006C -20
2016.03.01 11:09:04 4 : CUL_Parse: nanoCUL868hm A 2C 04 00CA 395182 044DB1 0A00436F6E666967206368616E6765642E20446174613A200072657365742C206461746C -20
2016.03.01 11:09:04 4 : CUL_Parse: nanoCUL868hm A 20 04 20CA 395182 044DB1 613A2000667265654D656D3A20002062797465000A00536C -20
2016.03.01 11:09:04 4 : CUL_Parse: nanoCUL868hm A 20 04 20CA 395182 044DB1 613A2000667265654D656D3A20002062797465000A00536B -20.5
2016.03.01 11:09:04 4 : CUL_Parse: nanoCUL868hm A 20 04 20CA 395182 044DB1 613A2000667265654D656D3A20002062797465000A00536B -20.5
2016.03.01 11:09:04 4 : CUL_Parse: nanoCUL868hm A 0A 04 8002 044DB1 395182 0030 -50
2016.03.01 11:09:04 4 : CUL_Parse: nanoCUL868hm A 2E 05 00CA 395182 044DB1 008074617274696E6720736B657463682E2E2E0A00006400000010030000000000000900006B -20.5
2016.03.01 11:09:04 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 000024020104060501050000002D0220284D3A00290A000A0020284C3A0029002000006B -20.5
2016.03.01 11:09:04 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 2E0206030D04E905CA063D070C0B060D210E650F5010C81193120315341601181819166C -20
2016.03.01 11:09:04 4 : CUL_Parse: nanoCUL868hm A 20 05 20CA 395182 044DB1 1B432156250026112D353EC320202077726974652064616B -20.5
2016.03.01 11:09:05 4 : CUL_Parse: nanoCUL868hm A 20 05 20CA 395182 044DB1 1B432156250026112D353EC320202077726974652064616B -20.5
2016.03.01 11:09:05 4 : CUL_Parse: nanoCUL868hm A 20 05 20CA 395182 044DB1 1B432156250026112D353EC320202077726974652064616B -20.5
2016.03.01 11:09:05 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 008074617274696E6720736B657463682E2E2E0A0000640000001003000000000000096C -20
2016.03.01 11:09:05 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 0000000024020104060501050000002D0220284D3A00290A000A0020284C3A002900206C -20
2016.03.01 11:09:05 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 00002E0206030D04E905CA063D070C0B060D210E650F5010C8119312031534160118186B -20.5
2016.03.01 11:09:05 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616C -20
2016.03.01 11:09:05 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616B -20.5
2016.03.01 11:09:06 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616B -20.5
2016.03.01 11:09:06 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 008074617274696E6720736B657463682E2E2E0A0000640000001003000000000000096C -20
2016.03.01 11:09:06 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 0000000024020104060501050000002D0220284D3A00290A000A0020284C3A002900206B -20.5
2016.03.01 11:09:06 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 00002E0206030D04E905CA063D070C0B060D210E650F5010C8119312031534160118186C -20
2016.03.01 11:09:06 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616B -20.5
2016.03.01 11:09:06 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616B -20.5
2016.03.01 11:09:06 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616C -20
2016.03.01 11:09:07 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 008074617274696E6720736B657463682E2E2E0A0000640000001003000000000000096C -20
2016.03.01 11:09:07 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 0000000024020104060501050000002D0220284D3A00290A000A0020284C3A002900206B -20.5
2016.03.01 11:09:07 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 00002E0206030D04E905CA063D070C0B060D210E650F5010C8119312031534160118186B -20.5
2016.03.01 11:09:07 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616C -20
2016.03.01 11:09:07 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616C -20
2016.03.01 11:09:07 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616C -20
2016.03.01 11:09:08 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 008074617274696E6720736B657463682E2E2E0A0000640000001003000000000000096C -20
2016.03.01 11:09:08 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 0000000024020104060501050000002D0220284D3A00290A000A0020284C3A002900206C -20
2016.03.01 11:09:08 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 00002E0206030D04E905CA063D070C0B060D210E650F5010C8119312031534160118186C -20
2016.03.01 11:09:08 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616C -20
2016.03.01 11:09:08 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616C -20
2016.03.01 11:09:08 4 : CUL_Parse: nanoCUL868hm A 22 05 20CA 395182 044DB1 19161B432156250026112D353EC320202077726974652064616C -20Der Abstand zwischen HM-CFG-USB zum Sensor betrug circa 4 Meter. Nachfolgend die Ausgaben des Terminals:
root@cubietruck:~# service hmland stop
root@cubietruck:/opt/hmcfgusb# sudo ./flash-ota -f HB-UW-Sen-THPL_update_V0_15_000_150303.eq3 -s UWS8788100
HomeMatic OTA flasher version 0.097-git
Reading firmware from HB-UW-Sen-THPL_update_V0_15_000_150303.eq3...
Firmware with 224 blocks successfully read.
Rebooting HM-CFG-USB to avoid running out of credits
HM-CFG-USB not in bootloader mode, entering bootloader.
Waiting for device to reappear...
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB in bootloader mode, rebooting
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB opened
HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial UWS8788100
Device with serial UWS8788100 (hmid: 044db1) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 224 blocks: 0001/0224 /
Missing ACK!
Flashing 224 blocks: 0003/0224 /
Missing ACK!
Flashing 224 blocks: 0003/0224 /
Missing ACK!
Flashing 224 blocks: 0003/0224 /
Missing ACK!
Flashing 224 blocks: 0003/0224 /
Missing ACK!
Flashing 224 blocks: 0003/0224 /
Missing ACK!
Too many errors, giving up!
root@cubietruck:/opt/hmcfgusb#
Und nochmal das selbe, aber diesmal mit einem Meter Entfernung:
2016.03.01 11:20:31 4 : CUL_Parse: nanoCUL868hm A 0F 02 20CB 395182 044DB1 105B11F815474D -35.5
2016.03.01 11:20:31 4 : CUL_Parse: nanoCUL868hm A 0A 02 8002 044DB1 395182 0049 -37.5
2016.03.01 11:20:31 4 : CUL_Parse: nanoCUL868hm A 2E 03 00CA 395182 044DB1 00800C944D010C94182F0C94452F0C94A7100C94CC100C94F1100C94C6210C9475010C94754D -35.5
2016.03.01 11:20:31 4 : CUL_Parse: nanoCUL868hm A 2C 03 00CA 395182 044DB1 010C9475010C9475010C9475010C9475010C9475010C9475010C9475010C94872F0C944D -35.5
2016.03.01 11:20:31 4 : CUL_Parse: nanoCUL868hm A 2C 03 00CA 395182 044DB1 75010C94142D0C94462D0C9475010C9475010C9475010C9475010C9442040C947501734D -35.5
2016.03.01 11:20:31 4 : CUL_Parse: nanoCUL868hm A 20 03 20CA 395182 044DB1 746174757320726571756573742C20646174613A2000614D -35.5
2016.03.01 11:20:31 4 : CUL_Parse: nanoCUL868hm A 20 03 20CA 395182 044DB1 746174757320726571756573742C20646174613A2000614D -35.5
2016.03.01 11:20:31 4 : CUL_Parse: nanoCUL868hm A 0A 03 8002 044DB1 395182 0049 -37.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 20 03 20CA 395182 044DB1 746174757320726571756573742C20646174613A2000614D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 2C 03 00CA 395182 044DB1 00800C944D010C94182F0C94452F0C94A7100C94CC100C94F1100C94C6210C9475010C4D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 2C 03 00CA 395182 044DB1 9475010C9475010C9475010C9475010C9475010C9475010C9475010C9475010C94872F4D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 2C 03 00CA 395182 044DB1 0C9475010C94142D0C94462D0C9475010C9475010C9475010C9475010C9442040C94754D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 22 03 20CA 395182 044DB1 0173746174757320726571756573742C20646174613A2000614D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 0A 03 8002 044DB1 395182 0047 -38.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 2E 04 00CA 395182 044DB1 00806C7469747564653A20000A007472616E736D4465765472794D61783A20000A006275724D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 2C 04 00CA 395182 044DB1 737452783A20000A006C65644D6F64653A20000A006C6F774261744C696D69743A20004D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 2C 04 00CA 395182 044DB1 0A00436F6E666967206368616E6765642E20446174613A200072657365742C206461744D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 20 04 20CA 395182 044DB1 613A2000667265654D656D3A20002062797465000A00534D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 0A 04 8002 044DB1 395182 004F -34.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 2E 05 00CA 395182 044DB1 008074617274696E6720736B657463682E2E2E0A00006400000010030000000000000900004C -36
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 000024020104060501050000002D0220284D3A00290A000A0020284C3A0029002000004D -35.5
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 2C 05 00CA 395182 044DB1 2E0206030D04E905CA063D070C0B060D210E650F5010C81193120315341601181819164D -35.5
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 20 05 20CA 395182 044DB1 1B432156250026112D353EC320202077726974652064614D -35.5
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 0A 05 8002 044DB1 395182 004C -36
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 2E 06 00CA 395182 044DB1 008074612C20627574206E6F7420696E20636F6E666967206D6F64650A00425552535420214E -35
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 2C 06 00CA 395182 044DB1 2121200A002D3E204E4120003C2D20000A554E4B4E4F574E204D4553534147452C20504E -35
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 2C 06 00CA 395182 044DB1 4C45415345205245504F5254210A0A006E6F74207265636569766564206265666F72654F -34.5
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 20 06 20CA 395182 044DB1 2E2E2E0A00616C7265616479207265636569766564202D4F -34.5
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 0A 06 8002 044DB1 395182 004B -36.5
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 2E 07 00CA 395182 044DB1 008020736B69700A002020207265706561746564206D6573736167653B20006C3E2000623E4F -34.5
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 2C 07 00CA 395182 044DB1 20002D3E2000706F7765724D6F64653A20000A000000000800020100000304070000004F -34.5
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 2C 07 00CA 395182 044DB1 00000000000102040810204080010204081020010204081020040404040404040402024F -34.5
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 20 07 20CA 395182 044DB1 02020202030303030303000000002300260029000000004F -34.5
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 20 07 20CA 395182 044DB1 02020202030303030303000000002300260029000000004F -34.5
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 0A 07 8002 044DB1 395182 004C -36
2016.03.01 11:20:33 4 : CUL_Parse: nanoCUL868hm A 2E 08 00CA 395182 044DB1 008000250028002B0000000000240027002A0000400342061611762D11241FBECFEFD8E0DE4F -34.5
2016.03.01 11:20:34 4 : CUL_Parse: nanoCUL868hm A 2C 08 00CA 395182 044DB1 BFCDBF11E0A0E0B1E0E8EEF7E602C005900D92AC3AB107D9F725E0ACEAB1E001C01D924F -34.5
2016.03.01 11:20:34 4 : CUL_Parse: nanoCUL868hm A 2C 08 00CA 395182 044DB1 AB30B207E1F712E0CAE9D2E004C02297FE010E947D33C239D107C9F70E94782F0C94F24F -34.5
2016.03.01 11:20:34 4 : CUL_Parse: nanoCUL868hm A 20 08 20CA 395182 044DB1 330C9400001F93CF93DF93EC01162F6FED70E08DE594E04F -34.5
2016.03.01 11:20:34 4 : CUL_Parse: nanoCUL868hm A 20 08 20CA 395182 044DB1 330C9400001F93CF93DF93EC01162F6FED70E08DE594E04F -34.5
2016.03.01 11:20:34 4 : CUL_Parse: nanoCUL868hm A 2E 09 00CA 395182 044DB1 00800E94F72D42E0612FCE010E9483118DE593E00E941A1A8981811107C08DE593E0DF91CF4F -34.5
2016.03.01 11:20:34 4 : CUL_Parse: nanoCUL868hm A 2C 09 00CA 395182 044DB1 911F910C94AC21DF91CF911F910895EF92FF920F931F93CF93DF938C01E62E809129024F -34.5
2016.03.01 11:20:34 4 : CUL_Parse: nanoCUL868hm A 2C 09 00CA 395182 044DB1 8A3008F48AE0682F833308F062E380E194E00E94EF0E80912502807C61E009F460E08D4F -34.5
2016.03.01 11:20:34 4 : CUL_Parse: nanoCUL868hm A 20 09 20CA 395182 044DB1 E593E00E94521680912402882311F062E001C063E08DE54F -34.5
2016.03.01 11:20:34 4 : CUL_Parse: nanoCUL868hm A 20 09 20CA 395182 044DB1 E593E00E94521680912402882311F062E001C063E08DE54F -34.5
2016.03.01 11:20:35 4 : CUL_Parse: nanoCUL868hm A 20 09 20CA 395182 044DB1 E593E00E94521680912402882311F062E001C063E08DE54F -34.5
2016.03.01 11:20:35 4 : CUL_Parse: nanoCUL868hm A 2C 09 00CA 395182 044DB1 00800E94F72D42E0612FCE010E9483118DE593E00E941A1A8981811107C08DE593E0DF4F -34.5
2016.03.01 11:20:35 4 : CUL_Parse: nanoCUL868hm A 2C 09 00CA 395182 044DB1 91CF911F910C94AC21DF91CF911F910895EF92FF920F931F93CF93DF938C01E62E80914F -34.5
2016.03.01 11:20:35 4 : CUL_Parse: nanoCUL868hm A 2C 09 00CA 395182 044DB1 29028A3008F48AE0682F833308F062E380E194E00E94EF0E80912502807C61E009F4604F -34.5
2016.03.01 11:20:35 4 : CUL_Parse: nanoCUL868hm A 22 09 20CA 395182 044DB1 E08DE593E00E94521680912402882311F062E001C063E08DE54F -34.5
2016.03.01 11:20:35 4 : CUL_Parse: nanoCUL868hm A 0A 09 8002 044DB1 395182 004E -35
2016.03.01 11:20:35 4 : CUL_Parse: nanoCUL868hm A 2E 0A 00CA 395182 044DB1 008093E00E94FD1580912A02811101C081E0F82E8AE08F1510F49AE0F92EF092470120912B4F -34.5
2016.03.01 11:20:35 4 : CUL_Parse: nanoCUL868hm A 2C 0A 00CA 395182 044DB1 0230E0322F222780912C02282B2C308EEF380714F42CE03EEFE901213187E2380714F04F -34.5
2016.03.01 11:20:35 4 : CUL_Parse: nanoCUL868hm A 2C 0A 00CA 395182 044DB1 C0E1D7E2BE018CEA91E00E94D12B68EC70E08DE594E00E94F72D43E06E2DC8010E948350 -34
2016.03.01 11:20:35 4 : CUL_Parse: nanoCUL868hm A 20 0A 20CA 395182 044DB1 111091290268EB70E08DE594E00E94F72D4AE050E0612F4F -34.5
2016.03.01 11:20:35 4 : CUL_Parse: nanoCUL868hm A 20 0A 20CA 395182 044DB1 111091290268EB70E08DE594E00E94F72D4AE050E0612F50 -34
2016.03.01 11:20:36 4 : CUL_Parse: nanoCUL868hm A 20 0A 20CA 395182 044DB1 111091290268EB70E08DE594E00E94F72D4AE050E0612F4F -34.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0A 00CA 395182 044DB1 008093E00E94FD1580912A02811101C081E0F82E8AE08F1510F49AE0F92EF09247012050 -34
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0A 00CA 395182 044DB1 912B0230E0322F222780912C02282B2C308EEF380714F42CE03EEFE901213187E2380750 -34
2016.03.01 11:20:38 1 : Perfmon: possible freeze starting at 11:20:37, delay is 1.272
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0A 00CA 395182 044DB1 14F0C0E1D7E2BE018CEA91E00E94D12B68EC70E08DE594E00E94F72D43E06E2DC8010E4F -34.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 22 0A 20CA 395182 044DB1 9483111091290268EB70E08DE594E00E94F72D4AE050E0612F4F -34.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 22 0A 20CA 395182 044DB1 9483111091290268EB70E08DE594E00E94F72D4AE050E0612F50 -34
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 22 0A 20CA 395182 044DB1 9483111091290268EB70E08DE594E00E94F72D4AE050E0612F4F -34.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0A 00CA 395182 044DB1 008093E00E94FD1580912A02811101C081E0F82E8AE08F1510F49AE0F92EF0924701204F -34.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0A 00CA 395182 044DB1 912B0230E0322F222780912C02282B2C308EEF380714F42CE03EEFE901213187E2380750 -34
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0A 00CA 395182 044DB1 14F0C0E1D7E2BE018CEA91E00E94D12B68EC70E08DE594E00E94F72D43E06E2DC8010E51 -33.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 22 0A 20CA 395182 044DB1 9483111091290268EB70E08DE594E00E94F72D4AE050E0612F50 -34
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2E 0B 00CA 395182 044DB1 00808DE594E00E94DB2E66EC70E08DE594E00E94F72D1091250212951695169513706CEA7050 -34
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0B 00CA 395182 044DB1 E08DE594E00E94F72D4AE050E0612F8DE594E00E94DB2E66EB70E08DE594E00E94F72D50 -34
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0B 00CA 395182 044DB1 1091240260EA70E08DE594E00E94F72D4AE050E0612F8DE594E00E94DB2E6AEA70E08D50 -34
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 20 0B 20CA 395182 044DB1 E594E00E94F72D6CE870E08DE594E00E94F72D4AE050E04F -34.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 20 0B 20CA 395182 044DB1 E594E00E94F72D6CE870E08DE594E00E94F72D4AE050E04F -34.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 20 0B 20CA 395182 044DB1 E594E00E94F72D6CE870E08DE594E00E94F72D4AE050E04F -34.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0B 00CA 395182 044DB1 00808DE594E00E94DB2E66EC70E08DE594E00E94F72D1091250212951695169513706C51 -33.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0B 00CA 395182 044DB1 EA70E08DE594E00E94F72D4AE050E0612F8DE594E00E94DB2E66EB70E08DE594E00E9451 -33.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0B 00CA 395182 044DB1 F72D1091240260EA70E08DE594E00E94F72D4AE050E0612F8DE594E00E94DB2E6AEA7052 -33
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 22 0B 20CA 395182 044DB1 E08DE594E00E94F72D6CE870E08DE594E00E94F72D4AE050E052 -33
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 0A 0B 8002 044DB1 395182 004D -35.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2E 0C 00CA 395182 044DB1 00806F2D8DE594E00E94DB2E6EE970E08DE594E00E94F72D6FE770E08DE594E00E94F72D4A52 -33
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0C 00CA 395182 044DB1 E050E0BE018DE594E00E94C62E6AE870E08DE594E0DF91CF911F910F91FF90EF900C9451 -33.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0C 00CA 395182 044DB1 F72D1F93CF93DF93EC01162F68E670E08DE594E00E94F72D42E0612FCE010E9483112F4F -34.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 20 0C 20CA 395182 044DB1 E788E391E0215080409040E1F700C00000DF91CF911F914F -34.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 0A 0C 8002 044DB1 395182 004D -35.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2E 0D 00CA 395182 044DB1 00800895FA0170E0641B750B680F791F8E2F841B821738F48491DB01AE0FBF1F8C933196F54E -35
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0D 00CA 395182 044DB1 CF0895CF92DF92EF92FF920F931F93CF93DF9388E10FB6F89480936000109260000FBE4F -34.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 2C 0D 00CA 395182 044DB1 26E040E051EE60E070E08DE594E00E94B82C6FEF70E08DE594E00E94F72D0E94A30FEC50 -34
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 20 0D 20CA 395182 044DB1 016DEE70E08DE594E00E94F72D4AE050E0BE018DE594E051 -33.5
2016.03.01 11:20:38 4 : CUL_Parse: nanoCUL868hm A 0A 0D 8002 044DB1 395182 004D -35.5
2016.03.01 11:20:39 4 : CUL_Parse: nanoCUL868hm A 2E 0E 00CA 395182 044DB1 00800E94E22E67EF70E08DE594E00E94F72D6DEF70E08DE594E00E94F72D2CE040EF5FE76151 -33.5
2016.03.01 11:20:39 4 : CUL_Parse: nanoCUL868hm A 2C 0E 00CA 395182 044DB1 E08FE491E00E94810223E04CEF5FE761E18FE491E00E948102C12C22E0E22E0DE02CE051 -33.5
2016.03.01 11:20:39 4 : CUL_Parse: nanoCUL868hm A 2C 0E 00CA 395182 044DB1 4BE06AE08FEE93E00E94311330EAE32E3BEBF32E01E121E047E062E080E194E00E94B051 -33.5
2016.03.01 11:20:39 4 : CUL_Parse: nanoCUL868hm A 20 0E 20CA 395182 044DB1 0E8DE593E00E947D214DE553E060E08DEF91E00E94972750 -34
2016.03.01 11:20:39 4 : CUL_Parse: nanoCUL868hm A 20 0E 20CA 395182 044DB1 0E8DE593E00E947D214DE553E060E08DEF91E00E9497274E -35
2016.03.01 11:20:39 4 : CUL_Parse: nanoCUL868hm A 20 0E 20CA 395182 044DB1 0E8DE593E00E947D214DE553E060E08DEF91E00E9497274F -34.5
2016.03.01 11:20:39 4 : CUL_Parse: nanoCUL868hm A 2C 0E 00CA 395182 044DB1 00800E94E22E67EF70E08DE594E00E94F72D6DEF70E08DE594E00E94F72D2CE040EF5F4F -34.5
2016.03.01 11:20:39 4 : CUL_Parse: nanoCUL868hm A 2C 0E 00CA 395182 044DB1 E761E08FE491E00E94810223E04CEF5FE761E18FE491E00E948102C12C22E0E22E0DE04F -34.5
2016.03.01 11:20:39 4 : CUL_Parse: nanoCUL868hm A 2C 0E 00CA 395182 044DB1 2CE04BE06AE08FEE93E00E94311330EAE32E3BEBF32E01E121E047E062E080E194E00E4F -34.5
2016.03.01 11:20:40 4 : CUL_Parse: nanoCUL868hm A 22 0E 20CA 395182 044DB1 94B00E8DE593E00E947D214DE553E060E08DEF91E00E9497274F -34.5
2016.03.01 11:20:40 4 : CUL_Parse: nanoCUL868hm A 22 0E 20CA 395182 044DB1 94B00E8DE593E00E947D214DE553E060E08DEF91E00E9497274E -35
2016.03.01 11:20:40 4 : CUL_Parse: nanoCUL868hm A 22 0E 20CA 395182 044DB1 94B00E8DE593E00E947D214DE553E060E08DEF91E00E9497274F -34.5
2016.03.01 11:20:40 4 : CUL_Parse: nanoCUL868hm A 2C 0E 00CA 395182 044DB1 00800E94E22E67EF70E08DE594E00E94F72D6DEF70E08DE594E00E94F72D2CE040EF5F50 -34
2016.03.01 11:20:40 4 : CUL_Parse: nanoCUL868hm A 2C 0E 00CA 395182 044DB1 E761E08FE491E00E94810223E04CEF5FE761E18FE491E00E948102C12C22E0E22E0DE050 -34
2016.03.01 11:20:40 4 : CUL_Parse: nanoCUL868hm A 2C 0E 00CA 395182 044DB1 2CE04BE06AE08FEE93E00E94311330EAE32E3BEBF32E01E121E047E062E080E194E00E50 -34
2016.03.01 11:20:40 4 : CUL_Parse: nanoCUL868hm A 22 0E 20CA 395182 044DB1 94B00E8DE593E00E947D214DE553E060E08DEF91E00E94972750 -34
2016.03.01 11:20:40 4 : CUL_Parse: nanoCUL868hm A 0A 0E 8002 044DB1 395182 004E -35
2016.03.01 11:20:40 4 : CUL_Parse: nanoCUL868hm A 2E 0F 00CA 395182 044DB1 008040E050E068E08DEF91E00E9469264DE553E061E08CEA91E00E94212B4BEDC42E41E0D450 -34
2016.03.01 11:20:41 4 : CUL_Parse: nanoCUL868hm A 2C 0F 00CA 395182 044DB1 2E50EEE52E51E0F52E07EF11E020E030E043E162E18CEA91E00E94512884B714BE60E050 -34
2016.03.01 11:20:41 4 : CUL_Parse: nanoCUL868hm A 2C 0F 00CA 395182 044DB1 80E090E00E94990144E064E088EF93E00E94441223E043E063E088EF93E0DF91CF911F50 -34
2016.03.01 11:20:41 4 : CUL_Parse: nanoCUL868hm A 20 0F 20CA 395182 044DB1 910F91FF90EF90DF90CF900C94D6118DE593E00C946C2550 -34
2016.03.01 11:20:41 4 : CUL_Parse: nanoCUL868hm A 20 0F 20CA 395182 044DB1 910F91FF90EF90DF90CF900C94D6118DE593E00C946C2550 -34
2016.03.01 11:20:41 4 : CUL_Parse: nanoCUL868hm A 20 0F 20CA 395182 044DB1 910F91FF90EF90DF90CF900C94D6118DE593E00C946C254F -34.5
2016.03.01 11:20:41 4 : CUL_Parse: nanoCUL868hm A 2C 0F 00CA 395182 044DB1 008040E050E068E08DEF91E00E9469264DE553E061E08CEA91E00E94212B4BEDC42E414F -34.5
2016.03.01 11:20:41 4 : CUL_Parse: nanoCUL868hm A 2C 0F 00CA 395182 044DB1 E0D42E50EEE52E51E0F52E07EF11E020E030E043E162E18CEA91E00E94512884B714BE4E -35
2016.03.01 11:20:41 4 : CUL_Parse: nanoCUL868hm A 2C 0F 00CA 395182 044DB1 60E080E090E00E94990144E064E088EF93E00E94441223E043E063E088EF93E0DF91CF4F -34.5
2016.03.01 11:20:41 4 : CUL_Parse: nanoCUL868hm A 22 0F 20CA 395182 044DB1 911F910F91FF90EF90DF90CF900C94D6118DE593E00C946C254F -34.5
2016.03.01 11:20:41 4 : CUL_Parse: nanoCUL868hm A 0A 0F 8002 044DB1 395182 004D -35.5
2016.03.01 11:20:42 4 : CUL_Parse: nanoCUL868hm A 2E 10 00CA 395182 044DB1 008010922E0210922F021092310210923002109233021092320210923502109234021092364F -34.5
2016.03.01 11:20:42 4 : CUL_Parse: nanoCUL868hm A 2C 10 00CA 395182 044DB1 0210923702109239021092380210923B0210923A0210923D0210923C028BED91E00C944F -34.5
2016.03.01 11:20:42 4 : CUL_Parse: nanoCUL868hm A 2C 10 00CA 395182 044DB1 4D061092AB0281E08093A9021092A80261E082E10E947A3061E083E10E947A30E9EBF04F -34.5
2016.03.01 11:20:42 4 : CUL_Parse: nanoCUL868hm A 20 10 20CA 395182 044DB1 E080818E7F808380818D7F808380E28093B80085E480934F -34.5
2016.03.01 11:20:42 4 : CUL_Parse: nanoCUL868hm A 20 10 20CA 395182 044DB1 E080818E7F808380818D7F808380E28093B80085E480934E -35
2016.03.01 11:20:42 4 : CUL_Parse: nanoCUL868hm A 20 10 20CA 395182 044DB1 E080818E7F808380818D7F808380E28093B80085E480934F -34.5
2016.03.01 11:20:42 4 : CUL_Parse: nanoCUL868hm A 2C 10 00CA 395182 044DB1 008010922E0210922F02109231021092300210923302109232021092350210923402104F -34.5
2016.03.01 11:20:42 4 : CUL_Parse: nanoCUL868hm A 2C 10 00CA 395182 044DB1 92360210923702109239021092380210923B0210923A0210923D0210923C028BED91E04F -34.5
2016.03.01 11:20:42 4 : CUL_Parse: nanoCUL868hm A 2C 10 00CA 395182 044DB1 0C944D061092AB0281E08093A9021092A80261E082E10E947A3061E083E10E947A30E94F -34.5
2016.03.01 11:20:43 4 : CUL_Parse: nanoCUL868hm A 22 10 20CA 395182 044DB1 EBF0E080818E7F808380818D7F808380E28093B80085E480934F -34.5
2016.03.01 11:20:43 4 : CUL_Parse: nanoCUL868hm A 22 10 20CA 395182 044DB1 EBF0E080818E7F808380818D7F808380E28093B80085E480934F -34.5
2016.03.01 11:20:43 4 : CUL_Parse: nanoCUL868hm A 22 10 20CA 395182 044DB1 EBF0E080818E7F808380818D7F808380E28093B80085E480934F -34.5
2016.03.01 11:20:43 4 : CUL_Parse: nanoCUL868hm A 2C 10 00CA 395182 044DB1 008010922E0210922F021092310210923002109233021092320210923502109234021050 -34
2016.03.01 11:20:43 4 : CUL_Parse: nanoCUL868hm A 2C 10 00CA 395182 044DB1 92360210923702109239021092380210923B0210923A0210923D0210923C028BED91E04F -34.5
2016.03.01 11:20:43 4 : CUL_Parse: nanoCUL868hm A 2C 10 00CA 395182 044DB1 0C944D061092AB0281E08093A9021092A80261E082E10E947A3061E083E10E947A30E94E -35
2016.03.01 11:20:43 4 : CUL_Parse: nanoCUL868hm A 22 10 20CA 395182 044DB1 EBF0E080818E7F808380818D7F808380E28093B80085E480934E -35
2016.03.01 11:20:43 4 : CUL_Parse: nanoCUL868hm A 0A 10 8002 044DB1 395182 004E -35
2016.03.01 11:20:43 4 : CUL_Parse: nanoCUL868hm A 2E 11 00CA 395182 044DB1 0080BC000895413208F03FC09091AB029111FCCF91E09093AB022093A9022FEF20933E02104F -34.5
2016.03.01 11:20:44 4 : CUL_Parse: nanoCUL868hm A 2C 11 00CA 395182 044DB1 928302240F209382029093AA029091AA02880F892B8093AA028091A802813041F4109250 -34
2016.03.01 11:20:44 4 : CUL_Parse: nanoCUL868hm A 2C 11 00CA 395182 044DB1 A8028091AA028093BB0085EC01C085EE8093BC008091AB028130E1F3809183028417104F -34.5
2016.03.01 11:20:44 4 : CUL_Parse: nanoCUL868hm A 20 11 20CA 395182 044DB1 F44091830224E832E0FB01D9018A2F821B841718F48D914F -34.5
2016.03.01 11:20:44 4 : CUL_Parse: nanoCUL868hm A 0A 11 8002 044DB1 395182 004D -35.5
2016.03.01 11:20:44 4 : CUL_Parse: nanoCUL868hm A 2E 12 00CA 395182 044DB1 00808193F9CF842F089580E008950F93413208F046C09091AB029111FCCF92E09093AB02004F -34.5
2016.03.01 11:20:44 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 93A9029FEF90933E021092830240938202FB0164E872E0DB019A2F961B941718F4919150 -34
2016.03.01 11:20:44 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 9D93F9CF1092AA029091AA02880F892B8093AA028091A802813041F41092A8028091AA4F -34.5
2016.03.01 11:20:44 4 : CUL_Parse: nanoCUL868hm A 20 12 20CA 395182 044DB1 028093BB0085EC01C085EE8093BC00222321F08091AB024E -35
2016.03.01 11:20:44 4 : CUL_Parse: nanoCUL868hm A 20 12 20CA 395182 044DB1 028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:44 4 : CUL_Parse: nanoCUL868hm A 20 12 20CA 395182 044DB1 028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:45 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 00808193F9CF842F089580E008950F93413208F046C09091AB029111FCCF92E09093AB4E -35
2016.03.01 11:20:45 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 020093A9029FEF90933E021092830240938202FB0164E872E0DB019A2F961B941718F44F -34.5
2016.03.01 11:20:45 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 91919D93F9CF1092AA029091AA02880F892B8093AA028091A802813041F41092A802804F -34.5
2016.03.01 11:20:45 4 : CUL_Parse: nanoCUL868hm A 22 12 20CA 395182 044DB1 91AA028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:45 4 : CUL_Parse: nanoCUL868hm A 22 12 20CA 395182 044DB1 91AA028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:45 4 : CUL_Parse: nanoCUL868hm A 22 12 20CA 395182 044DB1 91AA028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:45 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 00808193F9CF842F089580E008950F93413208F046C09091AB029111FCCF92E09093AB4F -34.5
2016.03.01 11:20:45 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 020093A9029FEF90933E021092830240938202FB0164E872E0DB019A2F961B941718F450 -34
2016.03.01 11:20:46 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 91919D93F9CF1092AA029091AA02880F892B8093AA028091A802813041F41092A802804F -34.5
2016.03.01 11:20:46 4 : CUL_Parse: nanoCUL868hm A 22 12 20CA 395182 044DB1 91AA028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:46 4 : CUL_Parse: nanoCUL868hm A 22 12 20CA 395182 044DB1 91AA028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:46 4 : CUL_Parse: nanoCUL868hm A 22 12 20CA 395182 044DB1 91AA028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:46 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 00808193F9CF842F089580E008950F93413208F046C09091AB029111FCCF92E09093AB4F -34.5
2016.03.01 11:20:46 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 020093A9029FEF90933E021092830240938202FB0164E872E0DB019A2F961B941718F44F -34.5
2016.03.01 11:20:46 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 91919D93F9CF1092AA029091AA02880F892B8093AA028091A802813041F41092A802804F -34.5
2016.03.01 11:20:46 4 : CUL_Parse: nanoCUL868hm A 22 12 20CA 395182 044DB1 91AA028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:47 4 : CUL_Parse: nanoCUL868hm A 22 12 20CA 395182 044DB1 91AA028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:47 4 : CUL_Parse: nanoCUL868hm A 22 12 20CA 395182 044DB1 91AA028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:47 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 00808193F9CF842F089580E008950F93413208F046C09091AB029111FCCF92E09093AB51 -33.5
2016.03.01 11:20:47 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 020093A9029FEF90933E021092830240938202FB0164E872E0DB019A2F961B941718F450 -34
2016.03.01 11:20:47 4 : CUL_Parse: nanoCUL868hm A 2C 12 00CA 395182 044DB1 91919D93F9CF1092AA029091AA02880F892B8093AA028091A802813041F41092A8028050 -34
2016.03.01 11:20:47 4 : CUL_Parse: nanoCUL868hm A 22 12 20CA 395182 044DB1 91AA028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:47 4 : CUL_Parse: nanoCUL868hm A 22 12 20CA 395182 044DB1 91AA028093BB0085EC01C085EE8093BC00222321F08091AB024F -34.5
2016.03.01 11:20:47 4 : CUL_Parse: nanoCUL868hm A 0A 12 8002 044DB1 395182 004B -36.5
2016.03.01 11:20:48 4 : CUL_Parse: nanoCUL868hm A 2E 13 00CA 395182 044DB1 00808230E1F380913E028F3F61F080913E02803251F080913E02803341F483E007C081E00550 -34
2016.03.01 11:20:48 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 C080E003C082E001C084E00F910895613298F42091AB02243089F460936002FC0182E64F -34.5
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 92E0DC012A2F281B261718F421912D93F9CF80E0089581E0089582E0089585ED8093BC4F -34.5
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 20 13 20CA 395182 044DB1 008091BC0084FDFCCF1092AB02089585EC8093BC0010924F -34.5
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 20 13 20CA 395182 044DB1 008091BC0084FDFCCF1092AB02089585EC8093BC0010924D -35.5
2016.03.01 11:20:50 1 : Perfmon: possible freeze starting at 11:20:49, delay is 1.732
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 20 13 20CA 395182 044DB1 008091BC0084FDFCCF1092AB02089585EC8093BC0010924F -34.5
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 00808230E1F380913E028F3F61F080913E02803251F080913E02803341F483E007C0814F -34.5
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 E005C080E003C082E001C084E00F910895613298F42091AB02243089F460936002FC014F -34.5
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 82E692E0DC012A2F281B261718F421912D93F9CF80E0089581E0089582E0089585ED804F -34.5
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924F -34.5
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924E -35
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924F -34.5
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 00808230E1F380913E028F3F61F080913E02803251F080913E02803341F483E007C0814E -35
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 E005C080E003C082E001C084E00F910895613298F42091AB02243089F460936002FC014E -35
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 82E692E0DC012A2F281B261718F421912D93F9CF80E0089581E0089582E0089585ED804E -35
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924E -35
2016.03.01 11:20:50 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924E -35
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924F -34.5
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 00808230E1F380913E028F3F61F080913E02803251F080913E02803341F483E007C0814E -35
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 E005C080E003C082E001C084E00F910895613298F42091AB02243089F460936002FC014D -35.5
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 82E692E0DC012A2F281B261718F421912D93F9CF80E0089581E0089582E0089585ED804E -35
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924E -35
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924F -34.5
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924F -34.5
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 00808230E1F380913E028F3F61F080913E02803251F080913E02803341F483E007C0814F -34.5
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 E005C080E003C082E001C084E00F910895613298F42091AB02243089F460936002FC014F -34.5
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 2C 13 00CA 395182 044DB1 82E692E0DC012A2F281B261718F421912D93F9CF80E0089581E0089582E0089585ED8050 -34
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924F -34.5
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924E -35
2016.03.01 11:20:51 4 : CUL_Parse: nanoCUL868hm A 22 13 20CA 395182 044DB1 93BC008091BC0084FDFCCF1092AB02089585EC8093BC0010924F -34.5Terminal Auszug:
root@cubietruck:/opt/hmcfgusb# sudo ./flash-ota -f HB-UW-Sen-THPL_update_V0_15_000_150303.eq3 -s UWS8788100
HomeMatic OTA flasher version 0.097-git
Reading firmware from HB-UW-Sen-THPL_update_V0_15_000_150303.eq3...
Firmware with 224 blocks successfully read.
Rebooting HM-CFG-USB to avoid running out of credits
HM-CFG-USB not in bootloader mode, entering bootloader.
Interrupt transfer not completed: Unknown error code 5 / 0x05!
Can't send null frame: No such device (it may have been disconnected)
Waiting for device to reappear...
Can't release interface: No such device (it may have been disconnected)
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB in bootloader mode, rebooting
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB opened
HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial UWS8788100
Device with serial UWS8788100 (hmid: 044db1) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 224 blocks: 0001/0224 /
Missing ACK!
Flashing 224 blocks: 0007/0224 /
Missing ACK!
Flashing 224 blocks: 0008/0224 /
Missing ACK!
Flashing 224 blocks: 0008/0224 /
Missing ACK!
Flashing 224 blocks: 0009/0224 /
Missing ACK!
Flashing 224 blocks: 0012/0224 /
Missing ACK!
Flashing 224 blocks: 0012/0224 /
Missing ACK!
Flashing 224 blocks: 0013/0224 /
Missing ACK!
Flashing 224 blocks: 0014/0224 /
Missing ACK!
Flashing 224 blocks: 0014/0224 /
Missing ACK!
Flashing 224 blocks: 0016/0224 /
Missing ACK!
Flashing 224 blocks: 0016/0224 /
Missing ACK!
Flashing 224 blocks: 0016/0224 /
Missing ACK!
Flashing 224 blocks: 0016/0224 /
Missing ACK!
Flashing 224 blocks: 0017/0224 /
Missing ACK!
Flashing 224 blocks: 0017/0224 /
Missing ACK!
Flashing 224 blocks: 0017/0224 /
Missing ACK!
Flashing 224 blocks: 0017/0224 /
Missing ACK!
Flashing 224 blocks: 0017/0224 /
Missing ACK!
Too many errors, giving up!
root@cubietruck:/opt/hmcfgusb#
Der Sensor war in beiden Fällen mit dem OTA Bootloader 0.7.0 und der Firmware 0.11 bespielt. Ich hoffe, dass du oder irgendjemand anderes etwas mit den Ausgaben anfangen kann. ???
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 2E 04 00CA 395182 044DB1 00806C7469747564653A20000A007472616E736D4465765472794D61783A20000A006275724D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 2C 04 00CA 395182 044DB1 737452783A20000A006C65644D6F64653A20000A006C6F774261744C696D69743A20004D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 2C 04 00CA 395182 044DB1 0A00436F6E666967206368616E6765642E20446174613A200072657365742C206461744D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 20 04 20CA 395182 044DB1 613A2000667265654D656D3A20002062797465000A00534D -35.5
2016.03.01 11:20:32 4 : CUL_Parse: nanoCUL868hm A 0A 04 8002 044DB1 395182 004F -34.5
so müssten eigentlich alle 224 blöcke aussehen. am ende das ack vom sensor. das ack kommt aber nicht immer, und zum schluss gar nicht mehr. mit millisekunden aufzeichnung (attr global mseclog 1) wäre es noch besser, da man dann timing probleme erkennen könnte.
grundsätzlich scheint es ja zu funktionieren, aber nicht stabil genug. da es mit geringerem abstand besser zu laufen scheint, vermute ich ein funkproblem und/oder timingprobleme. hast du eventuell ein "pseudo 868mhz funkmodul" ? ausreichende spannungsversorgung? korrekte antenne? andere störungen?
Danke für deine Antwort! :)
Zitat von: frank am 01 März 2016, 12:35:28
grundsätzlich scheint es ja zu funktionieren, aber nicht stabil genug. da es mit geringerem abstand besser zu laufen scheint, vermute ich ein funkproblem und/oder timingprobleme. hast du eventuell ein "pseudo 868mhz funkmodul" ? ausreichende spannungsversorgung? korrekte antenne? andere Störungen?
Ich habe den Fehler gefunden und konnte nun erfolgreich die FW 0.15 per OTA flashen:
root@cubietruck:/opt/hmcfgusb# sudo ./flash-ota -f HB-UW-Sen-THPL_update_V0_15_000_150303.eq3 -s UWS8788100
HomeMatic OTA flasher version 0.097-git
Reading firmware from HB-UW-Sen-THPL_update_V0_15_000_150303.eq3...
Firmware with 224 blocks successfully read.
Rebooting HM-CFG-USB to avoid running out of credits
HM-CFG-USB in bootloader mode, rebooting
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB opened
HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial UWS8788100
Device with serial UWS8788100 (hmid: 044db1) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 224 blocks: 0224/0224 -
Entering 10k-mode
Waiting for device to reboot
Ich Depp habe zwei falsche Kondensatoren an der Spule verlötet. Nachdem ich diese gegen die richtigen ausgetauscht habe, verlief das flashen ohne Probleme und ohne einem einzigen "Missing ACK". Das Problem war also die Stromversorgung.
Vielen Dank für deine Hilfe Frank!
Zitatohne Probleme und ohne einem einzigen "Missing ACK".
das hört sich doch bestens an.
Hallo Dirk,
hast Du schon Erkenntnisse, inwiefern sich das "Zusatzpaket" in der neuen CCU2-Firmware 2.17.14 *neu installieren* lässt?
Lässt sich das Zusatzpaket bei einem Update von 2.15.5 weiterverwenden ohne Neu-Installation des Paketes?
Edit: Das klappt (beides).
Ist das noch anpassbar, dass es nach Installation auch in der Übersicht über die installierten Zusatzpakete auftaucht?
Mal ne kurze Frage: Heute nacht hat mein Außensensor aufgrund von Unterspannung den Dienst eingestellt, jedoch ohne Low-Voltage-Warnung. Die letzte gemessene Spannung in FHEM war 1,9 V. Ist das normal so, dass er schon bei 1,9 V nicht mehr arbeitet? Das würde heißen, dass ich einfach das Register für Unterspannung etwas erhöhen würde. Was würdet ihr empfehlen, 2,1 V?
Hallo,
wenn man bedenkt, das die Nennspannung der Batterien eigentlich 3 V ist, sind 1,9 V schon sehr wenig. Wenn dann noch die Temperatur abfällt, kann es durchaus sein, das die Batterie(n) dann von jetzt auf gleich zusammenbrechen. Ich würd die Schwelle etwas höher wählen - bei 1 V pro Zelle (also 2,0 V) sind die eigentlich leer. Viel mehr kann man da nicht merh herausbekommen.
Gruß Christoph
ich bin auch gerade am überlegen, welcher bat level sinnvoll ist.
mit den batlevel daten aus meinem log, dachte ich eigentlich an 1.8v. deine angaben zum batlevel, passen dann natürlich nicht mehr.
(https://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=48092;image)
seit anfang januar gab es werte von 2.1/2.0/1.9 und dann der schnelle abfall bis 1.6v. da es ungefähr 2 wochen vor dem ausfall einen ersten ausreisser mit 1.8v gab, wollte ich diesen nun einstellen. der verlauf von batlevel hat sich gegenüber v13 auch verändert. damals gingen die werte, glaube ich, bis ca 0.8 v runter, weswegen ich 1.0v als grenzwert gesetzt hatte.
ich habe mir geade noch einen zweiten sensor angeschaut, der draussen hängt. hier habe ich leider keinen ausfall mehr im log. hier sind die batlevel ausreisser nach unten bei negativen temperaturen im schnitt grösser (bis zu -0.4v / 1.9v bei sonst 2.3v). hm... bei einem grenzwert von 1.9v hätte dieser dann bereits anfang januar lowbat angezeigt, aber wird wohl noch ein paar wochen/monate durchhalten.
eine allgemein sinnvolle einstellung scheint schwierig, da sie je nach umgebungstemperatur / batterietyp und eventuell den realen widerstandswerten der überwachungsschaltung unterschiedlich sein müsste.
ich lasse bei mir jetzt erstmal 1.8v und beobachte weiter. wegen dem stepup-ic nutze ich die sensoren immer für die alten batterien, die in anderen devices bereits aufgeben. ;)
Hm, wollte gerade das Register ändern. Anderes Problem, das mir gerade wieder aufgefallen ist: Ich habe zwei von Dirk's Sensoren und regelmäßig ist es bei mir so, dass die Register-Werte fehlen in FHEM (bzw. flöten gehen). configCheck sagt dann immer:
missing register list
ku_fridge: RegL_00.
Ich muss dann immer die Sensoren reinholen und getConfig machen. Dann sind die Register-Werte erstmal da, aber irgendwann später (Wochen? Monate) fehlen sie wieder. Hat das jemand auch? Mach ich was falsch?
Hab das Problem bei keinem anderen HM-Device. Firmware ist bei mir die 0.15.
Danke!
Hallo,
das liegt an HMInfo. Nach einem Neustart werden nicht automatisch die Register gelesen, bei Batteriegeräten macht das ohnehin keinen Sinn und geht nur auf die Batterie. In HMInfo kann man save Config machen. Dann werden alle Registerwerte in einer Datei gespeichert. Wenn configCheck dann diese Meldung raushaut, kann man mit load Config die gespeicherten Werte wieder laden. Damit verschwindet dann diese Meldung. Mann muss nur darauf achten, das nach einer Änderung der Register ein save Config gemacht wird, damit die Werte auch aktuell sind.
Gruß Christoph
Danke für die Antwort! Aber die Meldung in HMConfig ist für mich eher das Symptom als die Ursache. Ich habe auch einige andere batteriebetriebene HM-Gerät (Bewegungsmelder, Wandthermostate etc.). Bei denen habe ich nicht das Problem. Dort habe ich auch nach längere Zeit noch gefüllte Register-Readings. Also es scheint mir, als würde der THPL-Sensor irgendwas anders machen als "normale" HM-Geräte?
Sorry, nochmal eine generelle Frage:
Die Register-Werte tauchen ja in FHEM als reguläre Readings auf, zB "RegL_00.". Werden diese nicht, wie alle anderen Readings auch, bei saveConfig in die Datei fhem.save gespeichert und beim Starten von FHEM wieder eingelesen? Sind diese Register-Readings aus FHEM-Sicht in irgendeiner Art speziell?
setstate Wetter.Sued 2016-03-06 11:35:23 RegL_00. 01:00 05:24 0A:1A 0B:CE 0C:1F 12:12 14:03 24:00 25:4E 00:00
meine liste steht drinnen, bei dir nicht? du musst natürlich einmal speichern.
wenn sie nicht drin stehen würden, wären sie ja nach reboot/restart alle fort. in der regel bleiben sie ja erhalten.
manchmal "verliert" wohl fhem schon mal ein paar daten, daher empfiehlt martin ja nach restart die gesicherten configs mit loadconfig einzuspielen.
Bei mir steht es (im Moment) drin in der fhem.save. Und es überlebt auch Restarts. Also ich kann es nicht so einfach Reproduzieren. Aber es ist immer so, dass nach einiger Zeit wieder die Register-Readings von meinen beiden THPLs flöten gehen. Sieht für mich nicht nach einem generellen FHEM-Problem aus, da es wirklich immer nur die beiden THPLs betrifft.
Aber ist schonmal interessant, dass ihr das Problem offenbar nicht habt. Hm...
Hallo Ralli,
Zitat von: Ralli am 03 März 2016, 16:28:20
hast Du schon Erkenntnisse, inwiefern sich das "Zusatzpaket" in der neuen CCU2-Firmware 2.17.14 *neu installieren* lässt?
Lässt sich das Zusatzpaket bei einem Update von 2.15.5 weiterverwenden ohne Neu-Installation des Paketes?
Edit: Das klappt (beides).
Danke für das Feedback. Super das das geklappt kat
ZitatIst das noch anpassbar, dass es nach Installation auch in der Übersicht über die installierten Zusatzpakete auftaucht?
Da das ein FW-Patch und nicht nur ein Addon ist, ist das nicht vorgesehen.
Und da hier wirklich Firmware-Files gepatcht werden ist ein sicheres "Deinstallieren" nur über ein erneutes Einspielen des letzten Updates möglich.
Vorher das Backup nicht vergessen :)
Zitat von: vbs am 07 März 2016, 08:59:54
Mal ne kurze Frage: Heute nacht hat mein Außensensor aufgrund von Unterspannung den Dienst eingestellt, jedoch ohne Low-Voltage-Warnung. Die letzte gemessene Spannung in FHEM war 1,9 V. Ist das normal so, dass er schon bei 1,9 V nicht mehr arbeitet? Das würde heißen, dass ich einfach das Register für Unterspannung etwas erhöhen würde. Was würdet ihr empfehlen, 2,1 V?
Das habe ich so auch schon erlebt. Das Problem war in der Regel, dass eine Zelle sich deutlich schneller entladen hat. Wenn die andere Zelle dann noch "gut" ist, dann bricht die Spannung beider Zellen in Summe trotzdem zu stark ein. Da kann dann auch der Schaltregler nix mehr ausrichten.
Diese Woche hatte ich das erst. Die letzte erfolgreiche Spanungsmessung war bei 2,0 V.
Allerdings war dieses Verhalten selber verursacht. Da ich die Sensoren dazu benutze, Batterien die in anderen Geräten praktisch nicht mehr funktionieren noch mal bis auf's letzte "auszuquetschen"
Die Batterien laufen in den Sensoren dann noch ein paar Wochen / Monate. Eine Zelle hatte übrigens noch eine Spannung von 0,7 V die andere 1,3 V.
Der Innenwiderstand der leeren Zelle ist dann zu hoch um den Schaltregler bei aktivem Sensor noch ausreichend zu versorgen. Hier hätte ich die Zellen vor dem Einsetzen wohl besser selektieren sollen.
Viele Grüße
Dirk
Ok danke, ich hab mal die Schwelle etwas hochgesetzt. Mal schauen, wie es beim nächsten Mal abläuft.
Nochmal eine andere Frage:
Ich kann ja per Register den Burst aktivieren. Nach meinem Verständnis können damit dem Device ständig Nachrichten geschickt werden und es reagiert sofort (wie bei einer zB Funksteckdose). Zieht natürlich mehr Batterie.
Jedoch auch ohne Burst-Modus wachen doch HM-Geräte normalerweise gelegentlich auf, um Nachrichten vom Server zu holen, oder? Oder spätestens wenn sie selbst Nachrichten ZUM Server schicken, nutzen sie doch die Gelegenheit, um auch welche vom Server zu empfangen (so scheint es zB mein HM-Bewegungsmelder zu machen).
Meine THPLs hier scheinen jedoch nie Nachrichten zu empfangen (getConfig zB), bevor ich nicht den Taster am Gerät drücke. Ist das so gedacht? Also ein getConfig steht gefühlt ewig in der Queue bis ich mich erbarme und den Außensensor reinhole und den Taster betätige.
ZitatMeine THPLs hier scheinen jedoch nie Nachrichten zu empfangen (getConfig zB), bevor ich nicht den Taster am Gerät drücke. Ist das so gedacht?
im moment funktioniert nur manuell den taster drücken.
und vorsicht! das register burst nicht einschalten, sonst ist die batterie ganz schnell leer. zumindestens noch bei fw 0.14.
Zitat von: vbs am 12 März 2016, 11:21:28
Ich kann ja per Register den Burst aktivieren. Nach meinem Verständnis können damit dem Device ständig Nachrichten geschickt werden und es reagiert sofort (wie bei einer zB Funksteckdose).
So sollte es sein. Burst ist aber in der Firmware noch nicht bzw. unvollständig integriert. In der 0.15er bleib hier lediglich der Sensor ständig wach und ist dort nur zu Testzwecken weil der Batterieverbrauch dann exorbitant steigt.
Geplant hatte ich Burst um z.B. die Sensorwerte adhock anfordern zu können.
Was du meinst nennt sich "lazy config" und lässt ein batteriebetriebenes Gerät, Konfigurationsänderungen vom Master bei der nächsten geplanten Kommunikation
"abholen". Ein Burst braucht es dafür nicht.
Das hatte ich versucht zu integrieren. Das ganze Funktioniert aber noch nicht oder nur ab und zu.
Hier muss ich noch mal schauen warum das nicht klappt.
Viele Grüße
Dirks
Ok, danke für die Aufklärung!
Sowas von superextremsaublöd: Ich habe seit Monaten den UWS im offenen Außengehäuse im Testbetrieb, nun soll er endlich an die frische Luft. Nur: wie vom Erdboden verschluckt ist der Klarsichtdeckel vom Gehäuse. Ich habe eine Viertelstunde lang Werkstatt und Arbeitszimmer abgesucht (und dabei viele interessante Dinge gefunden, aber eben nicht ...)
Dirk, woher beziehst Du die Gehäuse aktuell? Ich werde wohl eins nachkaufen müssen.
Hallo,
kann man eigentlich irgendwo die Zeit zwischen den einzelnen Übertragungen der Werte einstellen?
Bei mir werden die Daten alle 3 min übertragen, alle 6 min würde mir im hinblick auf Batterielaufzeit auch reichen.
Gruß Holgi
Hallo Dirk,
ich hätte Interesse an zwei Universalsensoren.
MfG BlasterX
Habe heute an außensensor die Batterie gewechselt. Leider wird die Helligkeit nicht aktualisiert. Batteriewerte werden angezeigt und aktualisiert. Was kann das sein?
Reading von luminosity verharrt auf 3.12.2015?
Hallo Pjg
Ist der Sensor noch gepairt?
Gruss Christoph
Ja also alle anderen readings werden aktualisiert. Nur die Helligkeit nicht.
Bessere Auflösung
Hab mal auf den Knopf am Sensor gedrückt. Bringt auch nix
Auch neu pairen über den CUL brachte keinen Erfolg.
Ist der Sensor kaputt?
Hallo Pjg
Der Sensor ist nicht gepairt! Ich meine das schon mal gelesen zu haben, dass nach Batteriewechsel das pairing verloren geht!
Siehe paired to, da steht 000000
Gruss Christoph
Hm. Und jetzt?
Wie ging das noch. Ich hab schon x mal den Knopf am Sensor gedrückt.
Und hmpairforsec 600 am CUL hab ich auch schon gemacht.
Ich weiss es jetzt auch gerade nicht, bin noch auf Arbeit!
Gruss Christoph
Ich Probier mal Knopf gedrückt halten beim Batterie einlegen.
Hallo zusammen
Zitat von: Pfriemler am 13 März 2016, 22:47:39
Dirk, woher beziehst Du die Gehäuse aktuell? Ich werde wohl eins nachkaufen müssen.
Das Gehäuse hab ich von TME. Bei ELV gibt es das Gehäuse auch: http://www.elv.de/industrie-aufputz-gehaeuse-ip65-modell-g201c.html
Zitat von: The-Holgi am 14 März 2016, 12:40:35
kann man eigentlich irgendwo die Zeit zwischen den einzelnen Übertragungen der Werte einstellen?
Bei mir werden die Daten alle 3 min übertragen, alle 6 min würde mir im hinblick auf Batterielaufzeit auch reichen.
Aktuell nur im Code. Das Feature steht aber in meiner ToDo-Liste.
Zitat von: blasterx am 17 März 2016, 18:06:11
ich hätte Interesse an zwei Universalsensoren.
Hab dir eine PM geschickt.
Zitat von: Pjg am 18 März 2016, 14:56:43
Wie ging das noch. Ich hab schon x mal den Knopf am Sensor gedrückt.
Und hmpairforsec 600 am CUL hab ich auch schon gemacht.
So ist der korrekte Weg. Aber auch ohne Peering sendet der Sensor Werte. Dann an Broadcast.
So wie es bei dir aussieht bekommst du aber gar keine Werte übermittelt.
Kannst du RAW-Werte vom Sensor in FHEM sehen?
Zitat von: Pjg am 18 März 2016, 15:07:15
Ich Probier mal Knopf gedrückt halten beim Batterie einlegen.
Damit startet der Bootloader. Das ist also nur beim Update notwendig.
Blinkt die LED nach dem Drücken der Config-Taste
Gruß
Dirk
Edit: falscher Link
Ja, wenn ich drucke blinkt es
Schau mal ins Eventlog. Dann sollte ein Eintrag beim Drücken kommen.
Ebenso beim regulärem Senden der Daten Entweder alle 2-3 Min.
oder direkt nach dem Batterieeinlegen.
Poste mal die Ausgabe vom Eventlog mit den Daten des Sensors
Dauert. Hab die Handwerker im Haus. Wo ist das Eventlog?
Ok. heisst "Event Monitor". In FHEM unten in der Navigation
Bei mir unter http://<meineIp>:8083/fhem?cmd=style%20eventMonitor
Beim drücken kommt das
Und das beim senden. Kommt irgendwie schon was, nur nicht die Helligkeit. Temp. Ist nicht bestückt
Das
Ok, Temperatur und Feuchte werden übertragen. Ich war nur Irritiert, dass bei deinen vorherigen Screenshots da auch 0 stand.
Du kannst zwar nochmal probieren die 0.14 oder 0.15er Firmware zu flashen. Sieht für mich aber nach einem Defekt aus. Das muss ich wohl reparieren / austauschen.
Falls das nach dem Update nicht funktioniert, schreib mich am besten per PM an.
Viele Grüße
Dirk
Nein. Das ist der innensensor
Es geht um den aussen. Der hat nur einen helligkeitssensor.
Ah, ok. Dann bin ich wohl in der Zeile verrutscht.
Eine Idee habe ich noch. Du hast nicht zufällig die Version der 0.15er Firmware geflasht die experimentell für den Ultraschallsensor gedacht ist?
Bei der ist der Helligkeitssensor deaktiviert.
Nein. Ist 15 aber hat ja den ganzen Sommer funktioniert
Hallo,
ich bin gerade dabei, einen eigenen Raumtemperatursensor analog dem Universalsensor zu bauen - nur anderer Sensor.
Das Ganze soll zum Know-How-Aufbau für weitere HM-Projekte dienen.
Ursprünglich habe ich mit der NewAskSin-Lib angefangen und das Peering mit einem HM-CC-RT-DN getestet - allerdings
hatte ich nur sporadische Datenübertragungen. Danach bin ich auf die alte AskSin-Lib zurück gegangen - gleicher (Miss-)Erfolg.
Zuletzt habe ich den Original-Code vom Universalsensor verwendet, da hier ja (ich hoffe mal, das stimmt) das Peering
funktioniert. Die Abfragen der Sensoren habe ich mit der Rückgabe von Dummy-Werten "gebrückt".
Aber auch hier mag sich nach dem Peeren mit dem RT-DN keine dauerhafte Datenkommunikation einstellen...
Ich habe auch als eigene HM-ID die aus diesem Thread genommen: https://forum.fhem.de/index.php/topic,17485.0.html
Die Wartesequenzen ("Slots") kommen auch entsprechend, aber wenn mal eine Kommunikation zum RT-DN funktioniert hat,
die nächsten Datenübertragungen funktionieren dann wieder nicht.
Weiterhin habe ich auch festgestellt, daß wohl durch einen Compilerfehler (oder sonstigen Bug / Überschreiber in der Lib)
die Meßdaten nicht normal gesendet, sondern geburstet werden.
In diesem Falle funktioniert die Kommunikation mit dem RT-DN dauerhaft.
Das ist aber nicht das, was ich will. Wenn ich den Burst hart abschalte, dann geht's nur noch sporadisch.
Hier mal ein Protokoll:
Starting sketch...
freeMem: 995 byte
Device type from PROGMEM: F1 01
Serial from PROGMEM: 48 42 30 44 65 66 61 75 6C 74
Addresse from PROGMEM: 1F 4C 66
powerMode: 3
Config changed. Data: (L:0)
lowBatLimit: 16
ledMode: 1
burstRx: 0
transmDevTryMax: 3
altitude: 0
Slot=158, dst=159786, HMID=66 4C 1F 00, cnt=0 (M:1038)
<- 14 00 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1052)
<- 14 00 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1751)
<- 14 00 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2451)
-> NA (M:3149)
Slot=144, dst=304276, HMID=66 4C 1F 00, cnt=1 (M:160028)
<- 14 01 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:160045)
<- 14 01 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:160743)
<- 14 01 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:161444)
-> NA (M:162142)
Slot=130, dst=434517, HMID=66 4C 1F 00, cnt=2 (M:304519)
<- 14 02 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:304535)
<- 14 02 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:305234)
<- 14 02 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:305934)
-> NA (M:306632)
Slot=179, dst=614241, HMID=66 4C 1F 00, cnt=3 (M:434743)
<- 14 03 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:434759)
-> 0A 03 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:434907)
Slot=165, dst=779448, HMID=66 4C 1F 00, cnt=4 (M:614450)
<- 14 04 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:614464)
<- 14 04 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:615162)
<- 14 04 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:615863)
-> NA (M:616561)
Slot=150, dst=930442, HMID=66 4C 1F 00, cnt=5 (M:779694)
<- 14 05 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:779711)
<- 14 05 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:780409)
<- 14 05 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:781110)
-> NA (M:781808)
Slot=136, dst=1066926, HMID=66 4C 1F 00, cnt=6 (M:930678)
<- 14 06 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:930694)
<- 14 06 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:931393)
<- 14 06 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:932093)
-> NA (M:932791)
Slot=121, dst=1188904, HMID=66 4C 1F 00, cnt=7 (M:1067156)
<- 14 07 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1067172)
<- 14 07 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1067871)
<- 14 07 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1068571)
-> NA (M:1069270)
Slot=171, dst=1360624, HMID=66 4C 1F 00, cnt=8 (M:1189126)
<- 14 08 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1189142)
b> 0F 02 86 10 2E A3 AE 00 00 00 0A 88 E3 0D 00 00 (L:16) (M:1189804)
UNKNOWN MESSAGE, PLEASE REPORT!
<- 14 08 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1189841)
<- 14 08 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1190541)
-> NA (M:1191240)
Slot=157, dst=1517631, HMID=66 4C 1F 00, cnt=9 (M:1360633)
<- 14 09 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1360649)
-> 0A 09 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:1360797)
Slot=142, dst=1660319, HMID=66 4C 1F 00, cnt=10 (M:1517821)
<- 14 0A A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1517836)
-> 0A 0A 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:1517985)
Hat jemand die V0.15 vom Universalsensor direkt mit einem HM-CC-RT-DN im Einsatz (funktionsfähig; garantiert ohne Bursting)?
Viele Grüße,
Martin
Hallo Martin,
Zitat von: Linef am 28 März 2016, 18:41:17
allerdings hatte ich nur sporadische Datenübertragungen.
Das hatte ich ursprünglich auch. (Bis einschliesslich V0.14)
Wichtig ist hier das berechnete Timing. Das darf nicht durch andere Prozesse, Waits usw. verzögert werden. Und wenn, dann muss die Zeit für die nächste "Sendung" korrigiert werden.
ZitatWeiterhin habe ich auch festgestellt, daß wohl durch einen Compilerfehler (oder sonstigen Bug / Überschreiber in der Lib)
die Meßdaten nicht normal gesendet, sondern geburstet werden.
Was meinst du damit? Normal sendet der Sensor die Daten wenn er nicht gepeert ist genau einmal an die Broadcast Adresse. Ansonsten wird an die Peer-Adresse gesendet und auch ein ACK gewartet. Wenn das ACK ausbleibt, wird das Senden noch N-Mal wiederholt. N wird im transmDevTryMax-Register definiert.
ZitatIn diesem Falle funktioniert die Kommunikation mit dem RT-DN dauerhaft.
Vermutlich weil eine der drei Sendungen dann zufällig in den "normalen" Sendeslot passt.
ZitatHat jemand die V0.15 vom Universalsensor direkt mit einem HM-CC-RT-DN im Einsatz (funktionsfähig; garantiert ohne Bursting)?
So hatte ich das jedenfalls erfolgreich getestet.
Du hast nicht zufällig die Unterstützung für den US-Sensor einkommentiert?
Diese Codeteile dürften das Timing für das Peering mit dem HM-CC-RT-DN aktuell "versauen". Siehe auch der Kommentar in der Readme:
ZitatExperimental support for US-100 ultrasonic distance sensor (Do not use this experimental feature if you need the peering with HM-CC-RT-DN an this time)
Viele Grüße
Dirk
Noch mal was zum Thema Lazy-Config. Also das Übertragen der Registereinstellungen bei der nächsten Übertragung.
Also ohne das explizite Drücken der Config-Taste.
Ich habe das die letzten Tage noch einmal evaluiert. Grundsätzlich funktioniert das. Auch wenn es manchmal etwas dauert. Allerdings habe ich das Ganze aktuell nur zusammen mit der CCU erfolgreich getestet.
Mit FHEM klappt das aus irgendeinem Grund nicht. FHEM "gibt hier einfach zu früh auf" und quittiert den Versuch dann mit einem Fehler.
Hat schon mal jemand das Ganze z.B. mit einem anderen batteriebetriebenen Device getestet, welches nicht im Burst-Mode ist, getestet? Auch bei einem Bewegungsmelder wollte FHEM keine Register ohne Drücken der Config-Taste aktualisieren.
Gruß
Dirk
ZitatNoch mal was zum Thema Lazy-Config. Also das Übertragen der Registereinstellungen bei der nächsten Übertragung.
Also ohne das explizite Drücken der Config-Taste.
Ich habe das die letzten Tage noch einmal evaluiert. Grundsätzlich funktioniert das. Auch wenn es manchmal etwas dauert. Allerdings habe ich das Ganze aktuell nur zusammen mit der CCU erfolgreich getestet.
hi dirk,
was du hier als lazy-config beschreibst, ist das nicht eigentlich wakeup-config?
also wie bei einem thermostat, das regelmässig wetterdaten sendet.
lazy-config wäre nach meinem verständnis dann eher nach einem event, wie beim fensterkontakt oder eben motion beim bm.
würde diese "automatische" config denn auch in fw 0.14 funktionieren, oder erst mit 0.15?
edit:
wäre es möglich die namen deiner update-files ein klein wenig zu ändern, sodass der name kompatibel zu eq3 wird. dann wäre es einfacher deine files eventuell in meinen update-check einzubauen http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update#Tool_zur_Firmware_Versionspr.C3.BCfung (http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update#Tool_zur_Firmware_Versionspr.C3.BCfung)
bisher: HB-UW-Sen-THPL_update_V0_14_001_150301-I.tgz
demnächst: HB-UW-Sen-THPL-I_update_V0_14_001_150301.tgz
also den kompletten model-namen, wie in fhem benutzt, an den anfang des namens setzen und am ende nur das release date.
gruss frank
Also generell funktioniert das bei mir in FHEM mit HM-CFG-USB:
Wenn ich zB Register in einem HM-Bewegungsmelder ändere, dann werden die übertragen, wenn ich das nächste mal daran vorbeilaufe. Auch daran zu sehen, dass er dann recht wild blinkt.
Wie das genau heißt, kann ich allerdings nicht sagen.
Zitat von: Dirk am 31 März 2016, 16:31:19
Hallo Martin,
Das hatte ich ursprünglich auch. (Bis einschliesslich V0.14)
Wichtig ist hier das berechnete Timing. Das darf nicht durch andere Prozesse, Waits usw. verzögert werden. Und wenn, dann muss die Zeit für die nächste "Sendung" korrigiert werden.
Das Timing sollte ok sein. Aktuell lese ich keine Hardware-Sensoren aus, sondern erzeuge nur Dummy-Werte - das HM-Sensor-Modul liefert also immer gleichbleibende Temperatur, Feuchte und Druck. Keine Helligkeit und Batteriespannung. Damit geht der "Auslesevorgang" natürlich sehr schnell.
In SHT10_BMP085_TSL2561::poll_transmit lasse ich mir nach dem Aufruf von sendPeerWEATHER ein paar Debugs raus (Die Zeilen mit dem Slot=...). dst gibt dabei die nächste "Ziel"-Zeit an - also wenn das nächste Paket gesendet werden soll laut calcSendSlot. cnt ist der Message-Counter, der der Berechnung in calcSendSlot zugrunde liegt. Ich habe auch noch eine kleine Änderung in power_poll eingebaut, damit er beim peer_senden nicht noch zusätzlich 250ms "verschwendet". Damit ist das Timing eigentlich fast exakt (s.u.).
Zitat
Was meinst du damit? Normal sendet der Sensor die Daten wenn er nicht gepeert ist genau einmal an die Broadcast Adresse. Ansonsten wird an die Peer-Adresse gesendet und auch ein ACK gewartet. Wenn das ACK ausbleibt, wird das Senden noch N-Mal wiederholt. N wird im transmDevTryMax-Register definiert.
Mit Übersetzen Deines Originalcodes wird im 3. Byte der Message statt "A2" (wie es eigentlich durch die Einstellungen auch sein sollte) ein "B2" gesendet und damit ein Burst. Das läßt sich sehr schön durch Einschalten der Debug Message "send burst" im CC110x Modul erkennen:
Starting sketch...
freeMem: 995 byte
Device type from PROGMEM: F1 01
Serial from PROGMEM: 48 42 30 44 65 66 61 75 6C 74
Addresse from PROGMEM: 1F 4C 66
powerMode: 1
Config changed. Data: (L:0)
lowBatLimit: 16
ledMode: 1
burstRx: 0
transmDevTryMax: 3
altitude: 0
Slot=515 (128), dst=129786, HMID=66 4C 1F 00, cnt=255 (M:1038)
send burst
<- 14 00 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1437)
-> 0A 00 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:1558)
Slot=635 (158), dst=288537, HMID=66 4C 1F 00, cnt=0 (M:129789)
send burst
<- 14 01 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:130189)
send burst
<- 14 01 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:130887)
-> 0A 01 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:131010)
Slot=577 (144), dst=432788, HMID=66 4C 1F 00, cnt=1 (M:288540)
send burst
<- 14 02 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:288940)
-> 0A 02 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:289060)
Slot=520 (130), dst=562789, HMID=66 4C 1F 00, cnt=2 (M:432791)
send burst
<- 14 03 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:433190)
-> 0A 03 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:433311)
Slot=718 (179), dst=742290, HMID=66 4C 1F 00, cnt=3 (M:562792)
send burst
<- 14 04 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:563191)
-> 0A 04 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:563312)
Wenn ich nun z.B. die Debug-Meldungen in send_peer_poll aktiviere (zur Ausgabe von lB[0]), dann wird tatsächlich ein A2 gesendet und damit ist auch der Burst weg. Ich kann auch statt dem Einschalten der Debugs z.B. ein lb[0]=0 hart setzen, dann kommt auch kein Burst. Oder ich definiere lB als static - dann kommt auch keiner...
Das Verhalten habe ich mit der Arduino IDE 1.6.8, hatte ich auch mit 1.6.6 und habe es mit AtmelStudio 7.0.
Ich bin auch schon den erzeugten Assembler-Code durchgegangen - konnte aber keinen Fehler finden.
Vielleicht kannst Du das bei Dir mal verifizieren ob hier nicht doch zufällig geburstet wird...
Mein Code wäre auch hier verfügbar: https://github.com/LineF/Wettersensor.git und https://github.com/LineF/AskSin.git, jeweils develop Branch.
Zitat
Vermutlich weil eine der drei Sendungen dann zufällig in den "normalen" Sendeslot passt.
So hatte ich das jedenfalls erfolgreich getestet.
Wenn zum Peer geburstet wird, dann funktioniert's immer. Egal wann ich mit der Sequenz starte (z.B. kurz hintereinander den Sensor starten - RT-DN meldet sich immer)
Zitat
Du hast nicht zufällig die Unterstützung für den US-Sensor einkommentiert?
Diese Codeteile dürften das Timing für das Peering mit dem HM-CC-RT-DN aktuell "versauen". Siehe auch der Kommentar in der Readme:
Nein.
Hier die Sendungen ohne Burst:
Slot=653 (163), dst=1618042, HMID=66 4C 1F 00, cnt=13 (M:1454794)
rB:F6
<- 14 0E A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1454811)
<- 14 0E A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1455509)
<- 14 0E A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1456209)
-> NA (M:1456908)
Slot=595 (148), dst=1766792, HMID=66 4C 1F 00, cnt=14 (M:1618044)
rB:F6
<- 14 0F A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1618061)
-> 0A 0F 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:1618208)
Slot=538 (134), dst=1901293, HMID=66 4C 1F 00, cnt=15 (M:1766795)
rB:F6
<- 14 10 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1766811)
<- 14 10 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1767510)
<- 14 10 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1768210)
-> NA (M:1768908)
Slot=480 (120), dst=2021293, HMID=66 4C 1F 00, cnt=16 (M:1901295)
rB:F6
<- 14 11 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1901312)
<- 14 11 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1902010)
<- 14 11 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1902710)
-> NA (M:1903409)
Slot=678 (169), dst=2190794, HMID=66 4C 1F 00, cnt=17 (M:2021296)
rB:F6
<- 14 12 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2021312)
<- 14 12 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2022010)
<- 14 12 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2022711)
-> NA (M:2023409)
Slot=621 (155), dst=2346044, HMID=66 4C 1F 00, cnt=18 (M:2190796)
rB:F6
<- 14 13 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2190813)
<- 14 13 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2191511)
<- 14 13 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2192211)
-> NA (M:2192910)
Slot=563 (140), dst=2486795, HMID=66 4C 1F 00, cnt=19 (M:2346047)
rB:F6
<- 14 14 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2346063)
<- 14 14 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2346762)
<- 14 14 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2347462)
-> NA (M:2348161)
Slot=505 (126), dst=2613046, HMID=66 4C 1F 00, cnt=20 (M:2486798)
rB:F6
<- 14 15 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2486814)
-> 0A 15 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:2486962)
Slot=704 (176), dst=2789047, HMID=66 4C 1F 00, cnt=21 (M:2613049)
rB:F6
<- 14 16 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2613065)
<- 14 16 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2613764)
<- 14 16 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2614464)
-> NA (M:2615162)
Slot=646 (161), dst=2950548, HMID=66 4C 1F 00, cnt=22 (M:2789050)
rB:F6
<- 14 17 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2789066)
<- 14 17 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2789765)
<- 14 17 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2790465)
-> NA (M:2791163)
Slot=588 (147), dst=3097549, HMID=66 4C 1F 00, cnt=23 (M:2950551)
rB:F6
<- 14 18 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2950567)
<- 14 18 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2951266)
<- 14 18 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2951966)
-> NA (M:2952665)
Slot=530 (132), dst=3230050, HMID=66 4C 1F 00, cnt=24 (M:3097552)
rB:F6
<- 14 19 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3097569)
<- 14 19 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3098267)
<- 14 19 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3098968)
-> NA (M:3099666)
Slot=729 (182), dst=3412300, HMID=66 4C 1F 00, cnt=25 (M:3230052)
rB:F6
<- 14 1A A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3230068)
<- 14 1A A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3230767)
<- 14 1A A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3231467)
-> NA (M:3232165)
Die Sende-Zeit liegt also nur wenige ms hinter der Sende-Soll-Zeit.
Viele Grüße,
Martin
Hallo,
Zitat von: frank am 31 März 2016, 17:37:26
was du hier als lazy-config beschreibst, ist das nicht eigentlich wakeup-config?
also wie bei einem thermostat, das regelmässig wetterdaten sendet.
lazy-config wäre nach meinem verständnis dann eher nach einem event, wie beim fensterkontakt oder eben motion beim bm.
Gibt es diese Separation beim Wording? Ich kannte bisher nur "Lazy-Config" als Begriff. Aber ok.
Wenn das Device zyklisch sendet, dann heisst es "Lazy-Config", wenn er bei einem Event sendet heisst es "Wakeup-config"?
Ich meine aber, dass es hier technisch keine Unterschiede gibt. Die in der "Zentrale" stehen Config-Nachrichten für das Device an, wenn das Device sendet, dann sendet es ein "Wake me up"-Flag und dann sollte die "Zentrale" beginnen die Config-Daten zu übermitteln.
Zitatwürde diese "automatische" config denn auch in fw 0.14 funktionieren, oder erst mit 0.15?
Ich habe es mit meinen Wettersensoren (v0.14) und der CCU1 getestet. Damit hatte es auch funktioniert.
Zitatwäre es möglich die namen deiner update-files ein klein wenig zu ändern, sodass der name kompatibel zu eq3 wird.
bisher: HB-UW-Sen-THPL_update_V0_14_001_150301-I.tgz
demnächst: HB-UW-Sen-THPL-I_update_V0_14_001_150301.tgz
Ja, denke das kann ich machen. Falls ich das vergesse bitte noch mal erinnern :)
[/quote]
Zitat von: vbs am 31 März 2016, 19:40:33
Also generell funktioniert das bei mir in FHEM mit HM-CFG-USB:
Wenn ich zB Register in einem HM-Bewegungsmelder ändere, dann werden die übertragen, wenn ich das nächste mal daran vorbeilaufe. Auch daran zu sehen, dass er dann recht wild blinkt.
Ok, Dann werde ich das nochmal näher untersuchen. Vermutlich fehlt da noch was in der "HMConfig_SenTHPL.pm"
Zitat von: Linef am 31 März 2016, 20:56:12
Ich habe auch noch eine kleine Änderung in power_poll eingebaut, damit er beim peer_senden nicht noch zusätzlich 250ms "verschwendet". Damit ist das Timing eigentlich fast exakt (s.u.).
ZitatMit Übersetzen Deines Originalcodes wird im 3. Byte der Message statt "A2" (wie es eigentlich durch die Einstellungen auch sein sollte) ein "B2" gesendet und damit ein Burst.
Ich schaue mir das dann mal an.
Viele Grüße
Dirk
Hallo Dirk,
ich hätte Interesse an einen Außensensor.
MfG
Volker
Hallo Dirk,
Ich hätte auch Interesse an einen Außensensor.
Viele Grüße, Michael
Hallo,
ich hab den Innensensor selbst nachgebaut und stosse nun leider auf ein Problem. Den OTA-Bootloader hab ich erfolgreich geflasht. Wenn ich nun aber die Firmware per OTA flashe, startet der Sensor nicht und reagiert nicht auf den Config-Button:
sudo flash-ota -c /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03VVGB-if00-port0 -f HB-UW-Sen-THPL_update_V0_14_001_150301.eq3 -s SERIAL
HomeMatic OTA flasher version 0.102-git
Reading firmware from HB-UW-Sen-THPL_update_V0_14_001_150301.eq3...
Firmware with 224 blocks successfully read.
Opening culfw-device at path /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03VVGB-if00-port0 with speed 38400
Requesting firmware version
culfw-device firmware version: a-culfw
Entering 10k-mode
Waiting for device with serial SERIAL
Device with serial SERIAL(HMID: HM_ID) entered firmware-update-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 224 blocks: 0224/0224 -
Entering 10k-mode
Waiting for device to reboot
Die LED flackert auch beim Flashen.
Danach startet allerdings nicht die Sensor Software. Auch wenn ich per RX/TX draufschaue, sehe ich "Asksin OTA Bootloader ... Starte App" und dann nichts mehr.
Hat jemand vielleicht einen Tip, was ich noch versuchen kann? Ich vermute mal, dass wenn ich den Arduino-Bootloader verwende und seriell flashe, bekomme ich die gleichen Probleme.
Gruss Thomas
Hallo,
@VolkerNT und @wegi30
Ich hab euch eine PM geschickt.
@Thomas
Das Flashen der Firmware sah erst mal gut aus.
Welche Firmware hast du genommen? Selber kompiliert?
Was sagt die LED nach dem Anlegen der Versorgungsspannung?
Viele Grüße
Dirk
Hallo Dirk, die LED flackert kurz, 8 mal? Und dann in längeren Abständen.
Die Firmware ist die aus
https://github.com/kc-GitHub/Wettersensor/blob/master/Contrib/HB-UW-Sen-THPL_update_V0_14_001_150301.eq3
Ich weiss nicht was da faul ist. Das sind die Ausgaben beim Flashen:
AskSin OTA Bootloader V0.7.0
Start App
Starti®ö
AskSin OTA Bootloader V0.7.0
TX bootloader sequence
Wait for CB msg
Got CB msg
Switch to 100k mode
Wait for CB msg
Got CB msg
Receive firmware
.......Timeout
CRC OK
Start App
Starting
Auch wenn ich einen Arduino-Bootloader brenne, ATmegaBOOT_168_atmega328_pro_8MHz.hex, kann ich danach nicht mit Tx/Rx irgendein Programm mit avrdude brennen.
Kann ich die Firmware auch über Miso/Mosi/Sck flashen? Wie könnte das gehen?
Ich bin leider etwas ratlos. Ich hab noch gar keine Sensoren drauf, nur den Spannungsregler und den Atmega.
Update:
Hmm. Ich hab auf einer neuen Platine den Sensor noch einmal gebaut und es funktioniert. Dann hab ich wohl einen Hardware Defekt und werde mal einzelne Bauteile austauschen.
Gruss Thomas
Hallo Dirk,
ich habe Interesse an einem Aussensensor.
Vielen Dank, Grüße
Achim
Hallo,
auf der LXCCU Seite ist dieser Thread als Bezugsquelle für die Sensoren angegeben.
Ich habe einige Seiten gelesen aber noch keinen Quelle gefunden :-)
Kann mir jemand weiterhelfen?
Vielen Dank
Zitat von: hm-s am 20 April 2016, 18:54:10auf der LXCCU Seite ist dieser Thread als Bezugsquelle für die Sensoren angegeben.
Ich habe einige Seiten gelesen aber noch keinen Quelle gefunden :-)
Hi,
am besten Du schreibst eine PM an dem Forumsuser "Dirk".
Gruß,
Thorsten
Hallo,
ich habe bei einem HM configcheck festgestellt das der Sensor dort mehrere Einträge hat.
configCheck done:
missing register list
HM_Sensor: RegL_00.
PairedTo missing/unknown
HM_Sensor
weis jemand ob man das beheben kann.
Gruß Rolf
Hallo,
Zitatweis jemand ob man das beheben kann.
Normalerweise sollte ein "GetConfig" auf das Gerät ausreichen (anschließend die Configtaste am Gerät drücken). Anschließend solltest Du die Konfiguration in HMInfo abspeichern - sonst ist diese eventuell nach einen Neustart von Fhem weg. Wenn Du die gespeichert hast, kannst Du die Werte mit "Config restore" wieder einlesen.
"Paired to missin/unknown" bedeutet nicht unbedingt, das das Gerät nicht gepairt ist - es kann auch sein, das nur das Reading nicht - noch nicht - nicht mehr (clear Readings) von HMInfo in Fhem zu finden ist.
Gruß Christoph
Hallo,
ich habe heute nochmal getconfig auf alle Geräte gemacht, ist auf dem Sensor halt etwas komplizierter da ich in erst abbauen und aufschrauben muss. Jetzt ist alles ok.
Noch mal Danke, Gruß Rolf.
hallo dirk,
dies ist eine erinnerung. :)
ZitatZitatwäre es möglich die namen deiner update-files ein klein wenig zu ändern, sodass der name kompatibel zu eq3 wird.
bisher: HB-UW-Sen-THPL_update_V0_14_001_150301-I.tgz
demnächst: HB-UW-Sen-THPL-I_update_V0_14_001_150301.tgz
Ja, denke das kann ich machen. Falls ich das vergesse bitte noch mal erinnern :)
gruss frank
Hallo,
ich hatte diese Woche wieder einen relativ schnell entladenen Akku bei meinem Außensensor. Als ich diesen dann vom Dach geholt habe, war der Sensor innen feucht. Vermutlich vom vielen auf- bzw. zuschrauben beim Akkuwechsel.
Daher meine Frage:
Weiß jemand von Euch, wo man das Dichtungsband für das Außensensorgehäuse einzeln bekommt? Ich hatte noch ein Gehäuse da und habe die Dichtung gewechselt, aber auf Dauer ist mir das zu teuer ;)
Danke + Gruß
Peter
Hallo,
ich versuche gerade "HB-UW-Sen-THPL_CCU-addon.tgz"
als Zusatzsoftware in der CCU2 zu installieren.
Irgendwann ist die CCU2 damit fertig und ich kann mich neu anmelden.
Ich sehe die neu instalierte Software dort nicht,
ist aber wohl so, da es ein Patch ist.
Unter firmware/rftypes sehe ich allerdings nichts von "HB-UW-Sen-THPL.....xml
Was mache ich falsch?
Danke und Gruß, Gerd
Zitat von: g.finder am 07 Mai 2016, 12:26:08
Ich sehe die neu instalierte Software dort nicht,
Das ist korrekt so, das Addon wird dort nicht zu sehen sein.
ZitatUnter firmware/rftypes sehe ich allerdings nichts von "HB-UW-Sen-THPL.....xml
Die Datei die du suchst heisst "hb_uw_sen_thpl.xml"
Welche Version des Addons hast du verwendet? Dieses hoer sollte funktionieren:
https://github.com/kc-GitHub/Wettersensor/raw/master/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon.tgz
Viele Grüße
Dirk
Danke Dirk, mit deinem Link funktioniert es.
Ich hatte die "HB-UW-Sen-THPL_CCU-addon.tgz"
aus "Wettersensor-790be3c1c0387fbb70266416d7f5b71fdc225bb9" genommen.
Die ist 370.330KB groß und funktioniert nicht,
deine aus dem Link ist 370.397KB groß und funktioniert.
Danke, Gerd
Hallo Dirk,
ich hätte ebenfalls Interesse an einem Außensensor.
Gruß Luke
Hallo Gerd,
Zitat von: g.finder am 08 Mai 2016, 14:14:10
Ich hatte die "HB-UW-Sen-THPL_CCU-addon.tgz"
aus "Wettersensor-790be3c1c0387fbb70266416d7f5b71fdc225bb9" genommen.
Ja, in einer früheren Version gab es einen Bug im update-script für die CCU.
@Luke2000. Hab die eine PM geschickt.
Viele Grüße
Dirk
Hallo Dirk,
in den 144 Seiten hatte ich keinen Bughinweis gesehen, daher meine vergeblichen Versuche mit der falschen Version.
Zitat von: Dirk am 09 Mai 2016, 10:17:24
Ja, in einer früheren Version gab es einen Bug im update-script für die CCU.
Wie du oben in meinem Anhang siehst, sind die Bezeichnungen nicht wie die anderen Geräte in /firmware/rftypes.
Alle bereits vorhandenen fangen mit "rf_" an, die zwei neuen nicht. Fehler ?
Die Rechte und Besitzer sind ebenfalls anders als die bereits vorhandenen. Fehler ?
Gruß
Gerd
Hallo Dirk,
ich hätte noch einen Wunsch für die Firmware. Ließe sich dort ein Korrekturwert für die Temperatur (ggf. auch Feuchtigkeit) unterbringen? Hintergrund: Der SHT1 auf dem Breakout mißt konstant 0,6 Grad zuviel im Vergleich zum BMP180 bzw. anderen Thermometern an exakt gleicher Stelle.
lg.
TF
Fände ich auch gut. Ich hab mir auch schon die Zähne daran ausgebissen, aus dem Sensor und anderen Sensoren die gleiche Temperatur heraus zu bekommen. Nach meiner Erfahrung war jedoch der Offset leider nicht konstant, sondern schwankte zwischen 0.0 °C und ~ 1.0 °C. Habe leider nie herausgefunden, womit genau das zusammen hängt. 1.0 °C Abweichung finde ich schon relevant.
Wenn die Kennlinien der Sensoren verschieden sind, dann wird es sicher schwierig mit einem (linearen) Korrekturfaktor. Eventuell mittelt sich die Abweichung aber irgendwo. Bei mir ist dieses Problem so nicht vorhanden.
Ich habe übrigens die Erfahrung gemacht, dass sich zu Vergleichsmesssungen die Sensoren an exakt dem gleichen Ort befinden müssen. Selbst 1 oder 2 m Abstand können das Ergebnis verfälschen. Übrigens hat bei mir auch das Gehäuse des Außensensors einen (negativen) Einfluss, so das ich das Breakout-Modul verwende und dieses nach Außen verlegt habe.
Hallo Dirk
ich habe die ersten 25 Seiten und die letzten 10 Seiten versucht zu verstehen und mein Interesse ist geweckt.
Wie komme ich an die Universalsensoren?
Vielen Dank im Voraus
MfG paul_et
Hallo paul_er
du kannst die Platinen auch z.B. selbst bestellen und die Bauteile auch. Dirk hat alles im http://www.fhemwiki.de/wiki/Universalsensor (http://www.fhemwiki.de/wiki/Universalsensor) gut dokumentiert. Ich hab selbst 2 Innen- und einen Aussensensor gebaut. Ich kann dir da gerne weiter helfen.
Die Innensensor Platine kannst du günstig bei http://dangerousprototypes.com/store/pcbs (http://dangerousprototypes.com/store/pcbs) ordern.
@Dirk Ich hoffe, dass ist in deinem Sinne.
Gruss Thomas
Hallo Tom71,
vielen Dank für das Angebot.
Das Wiki hatte ich bereits durchgelesen, aber darin keine genaueren Info's für die Platinen/Bauteile (z.B. Universalsensorplatine etc.) zum Aussensensor gefunden. Habe ich da etwas übersehen?
Bin am Überlegen, ob es ein Eltako Multisensor werden wird oder ob ich in die Lösung von Dirk einsteige. Diese ist für mich aber vielleicht eine Nummer zu kompliziert.
Die Lösung soll im Sommer die Rollläden zur Beschattung steuern. Innentemperatur und grundsätzl. Rollladensteuerung hab ich bereits. Jetzt fehlt mir noch die Auswertung der Aussentemperatur und die Helligkeit (Sonnenschein).
Grüße paul_et
@paul_et
Ich hab dir eine PM geschrieben.
Zitat von: Tom71 am 13 Mai 2016, 20:12:26
@Dirk Ich hoffe, dass ist in deinem Sinne.
Klar, Nachbauen kann jeder. Und falls man nicht selber löten möchte oder kann, dann kann ich auch helfen.
Zitat von: paul_et am 16 Mai 2016, 20:00:04
aber darin keine genaueren Info's für die Platinen/Bauteile (z.B. Universalsensorplatine etc.) zum Aussensensor gefunden.
Unten in den Links sind Verweise zu dem Schaltplan und zum Layout. Auch zu Github. Dort liegt der Quellcode und auch die Eagle-Files.
Viele Grüße
Dirk
Hallo,
ich wollte dieses Projekt benutzen, um Informationen eines Bodenfeuchtesensors zu lesen.
Benutzt habe ich dazu einen Pro Mini 5V.
Dazu habe ich aus dem vorhandenen Sketch alle Sensoren softwaretechnisch entfernt und dann solch einen Sensor eingerichtet:
http://boxformakers.com/product/moisture-soil-moisture-module-yl-69-2/
Der Sensor kann seine Daten sowohl analog als auch digital übermitteln.
Die Übermittlung der Daten funktioniert auch soweit, allerdings kann ich nur die digitalen Daten zuverlässig auslesen.
Bei den analogen Daten kommen nur unlogische Werte raus.
Ich habe zunächst gedacht, es liegt am Sensor, aber ein kleiner Sketch, der ausschließlich den Sensor abfragt, funktioniert wunderbar.
Ich habe andere Pins probiert, aber es funktioniert einfach nicht.
Ich habe den Pin in der Library und im Sketch ausgelesen, die Daten sind identisch, aber falsch....
Wobei der HIGH-Wert oder wie man den maximalen analogen Wert nennen mag, nicht immer 1023 ist ... :o
Ich habe den digitalen Ausgang des Sensor an einem analogen Port angeschlossen und digital ausgelesen, das geht :-\
Langsam habe ich das Gefühl, dass ein analogRead irgendwie nicht funktioniert.
Hat jemand eine Erklärung, woran das liegen könnte?
Pairing etc. funktioniert übrigens...
Micky
Hallo Micky,
Die Analoge Messung funktioniert grudsätzlich. Schau dir mal die Messung der Batteriespannung im Sketch und in der Lib an.
Die Batteriespannung wird über A1 gemessen. A2 und A3 sollten Grundsätzlich noch frei und benutzbar sein.
Aber. Für die Batteriemessung wird die interne Spannungsreferenz des AVR benutzt. Möglicherweise stört das deine Messung.
Dann müsste das jeweils umkonfiguriert werden.
Viele Grüße
Dirk
Hallo Dirk,
danke für die schnelle Antwort.
Ich bin jetzt einen Schritt weiter.
Zunächst habe ich statt dem Pro Mini einen Nano benutzt, mit dem gleichen Problem.
Bei der ganzen Sache war mir noch aufgefallen, dass die Debug-Meldungen "Schmierzeichen", also nicht druckbare Zeichen enthalten.
Nachdem ich
hm.setPowerMode(POWER_MODE_ON);
gesetzt hatte, waren diese weg.
Aber der analoge Wert war immer noch falsch -und- veränderte sich nicht.
Erst nachdem ich die Batteriemessung abgeschaltet habe, funktioniert auch die Messung des Analogpins.
Wenn ich den Powermode auf POWER_MODE_SLEEP_WDT setze, ist die Analogmessung wieder hin :-[
Also geht nur POWER_MODE_ON ....
Wie ist denn da so der Stromverbrauch?
Micky
Hallo Leute,
habe heute meinen Universalsensor erhalten (Danke Dirk) und erfolgreich in betrieb genommen. Nun stellt sich mir eine Frage welche sicherlich irgendwo in den über 100 Seiten schon mal beantwortet wurde. Wo soll ich ihn am besten montieren (habe die Version für Aussen)?
Die Folie suggeriert mir dass ich ihn direkt in die Sonne hängen kann (bei mir wäre Ost- oder Westseite möglich) - das verfälscht aber sicherlich die Temperaturmessung, oder? Speziell in dem kleinen Gehäuse wird es sicherlich schnell warm.
Oder hänge ich ihn eher in den Schatten, dann aber vielleicht ohne Folie? Was sind eure Erfahrungswerte?
Grüße,
Markus
Zitat von: MarkusN am 28 Mai 2016, 12:23:49
Oder hänge ich ihn eher in den Schatten, dann aber vielleicht ohne Folie? Was sind eure Erfahrungswerte?
Hallo Markus,
das kommt darauf an, was Du damit machen willst. Wenn Du die Umgebungstemperatur messen willst, dann auf der Nordseite (ich meine in 1,5-2 m Höhe). Ich habe den direkt auf dem Dach neben meinen Solar/Photovoltaik Panels und messe die entsprechend wärmere Temperatur, ich habe aber den Fokus auf der Lichtmessung. Temperatur ist halt die ungefähre Modultemperatur.
Gruß Peter
Möglicherweise ist mein Post hier besser aufgehoben als in der Arduino Asksin Library... ::)
Ich habe leider ein Problem beim Flashen des Asksin Bootloaders. Ich verwende nachfolgenden Befehl für das Flashen:
avrdude -p m328p -P usb -c usbasp -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m -e -Uflash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:i
Und erhalte diese Ausgabe:
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xD0"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xD0:
avrdude: load data hfuse data from input file 0xD0:
avrdude: input file 0xD0 contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0x06"
avrdude: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x06:
avrdude: load data efuse data from input file 0x06:
avrdude: input file 0x06 contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0x2F"
avrdude: writing lock (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x2F:
avrdude: load data lock data from input file 0x2F:
avrdude: input file 0x2F contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex"
avrdude: writing flash (32768 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:
avrdude: load data flash data from input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:
avrdude: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex contains 32768 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x7243
0x60 != 0xe0
avrdude: verification error; content mismatch
avrdude: safemode: Fuses OK (H:06, E:D0, L:E2)
avrdude done. Thank you.
Andere Bootloader bringen das selbe Ergebnis. Ist der Pro Mini hin? :-[
Zitat von: Spezialtrick am 04 Juni 2016, 11:17:17
Ich habe leider ein Problem beim Flashen des Asksin Bootloaders.
Da scheint irgendwas mit der Datenrate nicht zu passen. Hier habe ich mal was dazu gefunden (ohne, dass ich es getestet habe) http://forum.arduino.cc/index.php?topic=312896.0
Kann man da die Baudrate runterdrehen?
Gruß Peter
Hat hier eigentlich schon jemand den Universalsensor um einen Bewegungsmelder erweitert? Ich habe den Aussensensor an einer Position vor der Haustür montiert an der ein Bewegungsmelder durchaus Sinn machen würde, vielleicht könnte man den ja sogar direkt im selben Gehäuse unterbringen.
Grüße,
Markus
Hallo Dirk,
ich hätte Interesse an einem Außensensor. :)
Viele Grüße
Christian
Zitat von: MarkusN am 09 Juni 2016, 18:14:45
Hat hier eigentlich schon jemand den Universalsensor um einen Bewegungsmelder erweitert? Ich habe den Aussensensor an einer Position vor der Haustür montiert an der ein Bewegungsmelder durchaus Sinn machen würde, vielleicht könnte man den ja sogar direkt im selben Gehäuse unterbringen.
Grüße,
Markus
Die Idee finde ich ziemlich gut, dann könnte man neben der Temp. Und Helligkeit auch eine Bewegung detektieren. Vielleicht kann der Bewegungssensor ja alternativ zum US Sensor verbaut werden.
@dirk, was hältst du von der Idee, ich hätte da sofort Bedarf 😉
Bin ebenfalls daran interessiert.
Gerd
Moin
Ich habe mal eine Frage, mein Aussensensor hat neuerdings keinen Bock mehr! Akkus sind frisch, und jetzt da er wieder tod ist kann ich eine Spannung von 2,5Volt messen. Er erwacht aber erst wieder zum Leben, wenn ich die Batterie kurz rausnehme. Hattet Ihr dieses Phaenomen auch schon? Von der Zentrale abgelernt war er jetzt auch schon einmal, kann aber auch durch Tastendrueckerei entstanden sein!
Jetzt gerade wieder Akku raus und rein!
Gruss Christoph
So, nach einer längeren Pause melde ich mich mal wieder hier.
Zitat von: micky0867 am 21 Mai 2016, 19:44:51
Bei der ganzen Sache war mir noch aufgefallen, dass die Debug-Meldungen "Schmierzeichen", also nicht druckbare Zeichen enthalten.
Nachdem ich
hm.setPowerMode(POWER_MODE_ON);
gesetzt hatte, waren diese weg.
Ich kann mir vorstellen, dass die Debugmeldungen bei dir "zu spät" abgesetzt werden. Ggf. Schaltet der Avr schon in den Sleep bevor die komplette Message übertragen wurde.
Baue nach dem letzten Debug mal eine
hm->stayAwake(1000);
Dann bleibt der AVR noch eine Sekunde länger wach.
ZitatWenn ich den Powermode auf POWER_MODE_SLEEP_WDT setze, ist die Analogmessung wieder hin :-[
Hier auch mal mit stayAwake versuchen den AVR wach zu halten.
ZitatWie ist denn da so der Stromverbrauch?
Das ist dann definitiv nix für längeren Batteriebetrieb.
Autobatterie Vielleicht :D
Zitat von: MarkusN am 09 Juni 2016, 18:14:45
Hat hier eigentlich schon jemand den Universalsensor um einen Bewegungsmelder erweitert? Ich habe den Aussensensor an einer Position vor der Haustür montiert an der ein Bewegungsmelder durchaus Sinn machen würde, vielleicht könnte man den ja sogar direkt im selben Gehäuse unterbringen.
Hatte ich schon mal im Versuchsaufbau. Der Bau einer fertigen Lösung liegt hier schon seit vielen Wochen in der Schublade. Nach den Ferien werde ich hier sicher mal wieder weiter machen.
Kann es sein dass das Textfeld in dem man hier Nachrichten schreibt nur eine begrenzte Anzahl von Zeichen verkraftet?Ok, es gal an einem Smiely-Sonderzeichen. Nach dem Löschen aus dem Zitat ging es dann.
Es kam die Fehlermeldung "Textfeld nicht ausgefüllt". Nach dem Kürzen der Nachricht ging der Beitrag dann durch.
Hier ist daher jetzt der zweite Teil:
@Chris8888
Mab die mal ne Nachricht geschickt.
Zitat von: kvo1 am 12 Juni 2016, 11:09:08
@dirk, was hältst du von der Idee, ich hätte da sofort Bedarf
Definitiv. Hab hier auch ein Einsatz dafür.
Vorher muss der Wasserzähler aber erst noch fertig gemacht werden.
Zitat von: pc1246 am 21 Juni 2016, 11:27:08
Ich habe mal eine Frage, mein Aussensensor hat neuerdings keinen Bock mehr! Akkus sind frisch, und jetzt da er wieder tod ist kann ich eine Spannung von 2,5Volt messen.
Wie verhält sich denn die Batteriespannung in der Zeit?
Viele grüße
Dirk
Hi Dirk,
ZitatZitat von: kvo1 am 12 Juni 2016, 11:09:08
@dirk, was hältst du von der Idee, ich hätte da sofort Bedarf
Definitiv. Hab hier auch ein Einsatz dafür.
SUPER... bin gespannt !
ZitatVorher muss der Wasserzähler aber erst noch fertig gemacht werden.
oh ja , da warten wir ja auch schon drauf ;)
DANKE
Klaus
Zitat von: Dirk am 23 Juni 2016, 17:28:42
Wie verhält sich denn die Batteriespannung in der Zeit?
Viele grüße
Dirk
Soweit ich das beurteilen kann, bleibt die konstant! Kann es sein, dass das Breakoutmodul sowas verursacht? Da habe ich ja leider keine vernuenftige Loesung gefunden, so dass das kleine Plastiktuetchen immer wieder vom Winde verweht wird. Das sieht jetzt schon recht oxidiert aus.
Gruss Christoph
Zitat von: Dirk am 23 Juni 2016, 17:25:48
Ich kann mir vorstellen, dass die Debugmeldungen bei dir "zu spät" abgesetzt werden. Ggf. Schaltet der Avr schon in den Sleep bevor die komplette Message übertragen wurde.
Baue nach dem letzten Debug mal eine hm->stayAwake(1000);
Dann bleibt der AVR noch eine Sekunde länger wach.
Die Schmierzeichen hatte ich auch. Alternativ zu einem stayAwake geht auch ein _delay_ms(10) (evtl. auch mehr), dann bleibt dem UART auch noch etwas Zeit, die Zeichen zu senden.
Zitat von: Linef am 24 Juni 2016, 10:12:50
Die Schmierzeichen hatte ich auch. Alternativ zu einem stayAwake geht auch ein _delay_ms(10) (evtl. auch mehr), dann bleibt dem UART auch noch etwas Zeit, die Zeichen zu senden.
Nimmt denn niemand Serial.flush() dafür? Das wartet doch genau so lange bis der Sendepuffer leer ist. Das nehme ich zumindest immer, wenn es derartige Probleme mit der UART-Ausgabe gibt.
Hallo zusammen,
ich kann im Wiki keine Bezugsquelle für fertige Plarinen finden... Handelt das Dirk via PM ab, oder gibt es irgendwo einen Shop etc.
Dankeschön :)
Zitat von: Floca am 29 Juni 2016, 15:45:00
Hallo zusammen,
ich kann im Wiki keine Bezugsquelle für fertige Plarinen finden... Handelt das Dirk via PM ab, oder gibt es irgendwo einen Shop etc.
Dankeschön :)
per PM
Weiß einer was pro fertiger Platine gelöhnt werden muss?
@kvo1 danke dir
Dirk liest hier mit und Du bekommst sicherlich eine Mail
mit den lieferbaren Sachen und Preise dazu.
Gerd
Zitat von: pc1246 am 24 Juni 2016, 07:35:43
Kann es sein, dass das Breakoutmodul sowas verursacht?
Ich will das nicht ausschließen, aber vorstellen kann ich es mir grade nicht. Ggf. muss ich mir das Teil mal bei mir anschauen
Zitat von: Uwe am 26 Juni 2016, 07:26:27
Nimmt denn niemand Serial.flush() dafür?
Wenn der AVR zwischenzeitlich in den Sleep geschickt wird, dürfte das auch nicht weiter helfen. Daher muss man sicherstellen, dass der AVR so lange wach bleibt, bis alles gesendet wurde.
Zitat von: g.finder am 29 Juni 2016, 18:11:54
Dirk liest hier mit und Du bekommst sicherlich eine Mail
Hin und wieder kommt das vor :)
Zitat von: Floca am 29 Juni 2016, 15:45:00
ich kann im Wiki keine Bezugsquelle für fertige Plarinen finden... Handelt das Dirk via PM ab, oder gibt es irgendwo einen Shop etc.
Hab dir eine PM geschickt.
Viele Grüße
Dirk
Sag ich doch ;)
Gerd
Zitat von: Dirk am 29 Juni 2016, 23:31:03
Wenn der AVR zwischenzeitlich in den Sleep geschickt wird, dürfte das auch nicht weiter helfen. Daher muss man sicherstellen, dass der AVR so lange wach bleibt, bis alles gesendet wurde.
Schlafen geht der AVR doch in HM::power_poll(), oder? Serial.flush() blockiert (in einer while-Schleife) aber so lange, bis alles gesendet wurde. Erst danach geht's wieder zurück zu HM:poll().
Entschuldige bitte, wenn ich mit so einem nebensächlichen Detail nerve, aber ich bin noch ein Lernender und möchte eben alles im Detail verstehen.
Aber vielleicht noch eine kurze Vorstellung, da ich hier neu bin: ich hatte mir vor ein paar Monaten einen Panstamp-AVR "nachgebaut" mit AVR und CC1101-Modul. Als Sensoren habe ich BME280 (für T/H/P) und BH1750 (für L) verwendet. Eine kurze Zeit habe ich den über Panstamp/SWAP mit FHEM betrieben. Dann bin ich aber auf Euren Thread gestoßen. Mit wenigen Umbauten an der Firmware läuft das Ding jetzt prima als HM-Device. Die Homematic-Anbindung in FHEM finde ich schon um einiges ausgereifter als die für Panstamps.
Vielen Dank an alle hier, ich durfte schon viel lernen.
Gruß
Uwe
Zitat von: Uwe am 01 Juli 2016, 09:32:11
Schlafen geht der AVR doch in HM::power_poll(), oder? Serial.flush() blockiert (in einer while-Schleife) aber so lange, bis alles gesendet wurde. Erst danach geht's wieder zurück zu HM:poll().
Dachte ich auch. Ich habe deshalb testweise einige delays nach seriellen Debug-Ausgaben entfernt und in PW::poll (NewAskSin) kurz vor dem Sleep einen Serial.flush() eingebaut - hat nicht funktioniert.
Ein Flush direkt nach der letzten seriellen Ausgabe dagegen schon.
D.h. das Funktionieren des Flushs scheint davon abzuhängen, ob er direkt nach einer seriellen Ausgabe erfolgt, oder zeitlich etwas später - oder sonst noch was schießt dazwischen...
@Dirk
Spricht was dagegen, dass Du die Datei HMConfig_SenTHPL.pm in den offiziellen fhem Distributionsweg eincheckst? Bei jeder Neuinstallation von fhem falle ich darauf rein, dass diese Datei fehlt und merke erst recht spät, dass mir Sensorwerte fehlen.
Zitat von: Dirk am 29 Juni 2016, 23:31:03
Ich will das nicht ausschließen, aber vorstellen kann ich es mir grade nicht. Ggf. muss ich mir das Teil mal bei mir anschauen
Viele Grüße
Dirk
So, das Problem ist erkannt! Eine von den Eneloops ist defekt! Dabei waren die neu! Jetzt habe ich erst mal Ikea drin, mal sehen ob ich die Eneloop noch wieder lebendig bekomme!
Gruss Christoph
Hallo Dirk,
ich hätte Interesse an deinen Sensoren (Innen und Aussen). Ist ein Versand in die Schweiz auch möglich?
Viele Grüsse
Philipp
Hallo,
kann man mit diesem Außensensor auch erkennen, ob die Sonne tatsächlich scheint? Ich benötige einen Sensor zur Rolladensteuerung.
Und besteht die Möglichkeit einen Sensor komplett montiert zu bekommen?
Grüße
Matthias
Moin Matthias
Also anbringen musst Du ihn schon selbst! ;) Ansonsten ist der Sensor von Dirk komplett fertig!
Da die Werte schon recht hochaufloesend sind, kannst du selbst entscheiden, bei welchem Wert Deine rollaeden runterfahren sollen. Ich benutze zusaetzlich noch den Sonnenstand, so dass ich wieder hochfahre, wenn die Sonne nicht mehr auf diese Fenster scheint. Zudem wird das auch nur dann gemacht, wenn die Temperaturen hoch genug sind, so dass ich im Winter die Sonnenenergie zum "heizen" nutze!
Gruss Christoph
Hallo,
vor einigen Monaten entdeckte ich den Thread mit den Selbstbau Sensoren von Dirk und baute mir auf dieser Basis 6 Sensoren auf.
Dabei merkte ich bald, dass es beim Timing Probleme gibt.
Wenn man die ursprünglich Software von Dirk benutzt, werden bei jeder Sendung
alle im Umkreis befindlichen HM-Geräte, die auf ein Burstsignal reagieren, geweckt. Das kostet Energie.
Beim Umstellen der Software auf das Timing, wie es auch von den originalen HM-Sensoren benutzt wird, stösst man auf das Problem der Ungenauigkeit des
Watchdog Timers, der abhängig von Spannung und Temperatur seine Werte ändert.
Auch die von Linef eingefügte Kalibrierung löst dass Problem nicht wirklich.
Nach wochenlangen Versuchen daher meine Frage: Ist das für euch überhaupt ein Problem und wenn ja, wie habt ihr das gelöst?
Anbringen bekomme ich gerade noch hin ;D
Meine Frage zielte darauf ab, ob ich da noch was löten müsste oder so. Das krieg ich nämlich überhaupt nicht hin.
Aktuell mach ich das fast genauso wie Du. Ich hole mir über Twillight den Sonnenstand und über meinWetter (wegen fehlender Sensoren) die Temperatur. Wen die Temp. über 20 °C ist und die Sonne vor den Wohnzimmerfenstern steht, fahren die Rollos in den Beschattungsmodus. Jedoch unabhängig ob die Sonne scheint oder ob es gerade bewölkt ist. Das bringt mich halt immer in Erklärungsnot bei meiner Holden.
Die Frage war vielleicht etwas falsch formuliert. Sind die Sensoren so hochauflösend, dass ich den Unterschied zwischen bewölktem und nicht bewölktem Himmel mitbekomme?
Wenn ja, hätte ich wirklich interesse den Sensoren.
Grüße
Matthias
Hi,
das mit dem Timing sehe ich so:
Für ein Peering mit einem RT-DN reicht es derzeit (für mich) aus (Temperaturbereich 20-28 °C). Ich habe ein Register mit reinprogrammiert, mit dem ich die Frequenz des internen RC-Oszillators justieren kann (in ca. 0,3%-Schritten). D.h. bei einem Sendeabstand der Telegramme von z.B. 180 Sek. kann der Abstand auf 0,5 Sek. genau eingestellt werden. Da der RT-DN ein Empfangszeitfenster von 10 Sek. hat, kommt man also genügend genau in dieses Fenster rein.
Problem ist eher, daß der RT-DN die Telegramme ab und zu komplett ignoriert, obwohl sie im Zeitfenster liegen.
Somit kommt es bei mir nur alle paar Tage vor, daß der RT-DN auf seinen internen Temperatursensor zurückschaltet. Das ist natürlich trotzdem ärgerlich.
Hier würden mich mal Erfahrungsberichte von Usern interessieren, die den RT-DN mit einem original EQ3-Raumthermostat versorgen - gibts hier auch immer wieder Rückschaltungen auf den internen Temperatursensor des RT-DN ??
Ich hatte auch schon drüber nachgedacht, den 32KHz Quarzoszillator zu benutzen - funktioniert aber leider auch nicht, da im niedrigsten Energiesparmodus des Atmega 328P ausschließlich noch der (RC-gesteuerte) Watchdog Oszillator läuft :-(
Hier könnte man allenfalls noch drüber nachdenken, mithilfe des Quarzoszillators den Watchdog immer mal wieder nachzukalibrieren.
Wenn der Sensor lediglich mit einer Zentrale gepairt ist, dann sehe ich überhaupt keine Probleme, was das Timing angeht.
Der Zentrale ist es egal, wann die Telegramme ankommen.
Wie es mit dem Peering mit anderen Aktoren aussieht, kann ich mangels Material nicht beurteilen.
Anbei übrigens der Temperaturverlauf über 1,5 Wochen - oben jeweils die gemessenen Werte des Eigenbau-Sensors, unten die des RT-DN. An insgesamt 5 Stellen (in den 3 markierten Bereichen) sieht man, daß er auf den eigenen, internen Sensor umgeschaltet hat. Davon waren aber 2 selbst verursacht (Neustarts des Sensors durch Neuprogrammierungen).
Viele Grüße,
Martin
Zitat von: Frini am 11 August 2016, 19:55:27
Anbringen bekomme ich gerade noch hin ;D
Meine Frage zielte darauf ab, ob ich da noch was löten müsste oder so. Das krieg ich nämlich überhaupt nicht hin.
Dirk's Sensoren sind komplett bestückt. Ggf. musst Du ihn noch in ein Gehäuse einbauen, aber ich meine, das hat er bei einem meiner Sensoren auch mitgeliefert.
Zitat von: Frini am 11 August 2016, 19:55:27
Das bringt mich halt immer in Erklärungsnot bei meiner Holden.
Hm, dann solltest Du an ein einer Lösung arbeiten 8) 8) 8)
Vielleicht gibt Sie Dir dann das Budget dafür frei :)
Zitat von: Frini am 11 August 2016, 19:55:27
Sind die Sensoren so hochauflösend, dass ich den Unterschied zwischen bewölktem und nicht bewölktem Himmel mitbekomme?
Ja, das geht. Ich hänge mal einen Plot von heute dran, da sieht man (hoffentlich) den Unterschied zwischen bewölkt und nicht bewölkt. Allerdings könnte ich mir vorstellen, dass man sowohl eine Hysterese braucht als auch ggf. den Schwellwert im Winter (Sonnenstand) ändern können müsste ...
Gruß PeMue
Hallo,
habe zum Überprüfen der Synchronität zwischen Temperatursensor und Heizkörperthermostat den tempOffset auf -3.5K
eingestellt. Besonders in der heizungsfreien Zeit kann ich dadurch jede Abweichung erkennen.
Bei dem zweiten Bild sind die Kurven deckungsgleich - also keine Abweichung.
Erreicht habe ich das unter anderem durch Einbau der Bibliothek narcoleptic von http://playground.arduino.cc/Main/LibraryList (http://playground.arduino.cc/Main/LibraryList).
Hallo Martin (Linef),
hab zwar eigentlich wegen was anderem vorbei geschaut ;-)
Aber weil ich über deine Frage "gestolpert" bin:
ZitatSomit kommt es bei mir nur alle paar Tage vor, daß der RT-DN auf seinen internen Temperatursensor zurückschaltet. Das ist natürlich trotzdem ärgerlich.
Hier würden mich mal Erfahrungsberichte von Usern interessieren, die den RT-DN mit einem original EQ3-Raumthermostat versorgen - gibts hier auch immer wieder Rückschaltungen auf den internen Temperatursensor des RT-DN ??
Ich habe einige HM-CC-RT-DN direkt mit einigen HM-TC-IT-WM-W-EU gepeert.
Ab und an habe ich mich über "eigenartiges" Verhalten der Heizkörper gewundert (macht auf, obwohl eigentlich warm genug / bzw. zu obwohl noch nicht warm)...
...und dann beschlossen, die desired-temp und measured-temp von beiden zu loggen (obwohl ja der HM-TC-IT-WM-W-EU "führend" ist und der HM-CC-RT-DN ja eigentlich seine eigenen Werte "ignorieren" soll, diese also identisch sein sollten) und mir nen Graphen gemacht.
Und ja ganz sporadisch laufen die mal ganz kurz "durcheinander", also der HM-CC-RT-DN springt auf sein eigenes Wochenprogramm etc.
Sieht so aus als würde er mal ein Telegramm des HM-TC-IT-WM-W-EU nicht bekommen (ist zumindest mal meine Vermutung).
Habe jetzt sorge ich immer dafür, dass die Wochenprogramme identisch sind dann fällt wenigstens das "komische Verhalten" der Heizkörper weg...
Aber ich denke nicht, dass das das eigentliche Problem (verlorenes Telegramm) löst, sondern nur die Auswirkung nicht mehr für mich sichtbar ist ;-)
Gruß, Joachim
Hallo,
Zitat von: plombe am 12 August 2016, 10:06:11
habe zum Überprüfen der Synchronität zwischen Temperatursensor und Heizkörperthermostat den tempOffset auf -3.5K
eingestellt.
Den Offset habe ich bei mir zwecks Erkennung des Problems ebenfalls recht hoch eingestellt...
Zitat von: plombe
Bei dem zweiten Bild sind die Kurven deckungsgleich - also keine Abweichung.
War bei dem ersten Bild die Lib noch nicht eingebaut?
Wie lange läuft bei Dir der Synchronitätstest mit der Lib schon? Nur die paar Tage jetzt?
Ich muß mir mal ansehen, wie die Lib das Timingproblem löst - hat ja auch keine andere Hardware zur Verfügung...
@MadMax-FHEM:
D.h., auch bei den Originalsensoren von EQ3 scheint das Problem also aufzutreten - beruhigt mich etwas, daß es also doch möglicherweise am RT-DN selbst liegt.
Martin
Hallo,
@Linef:
die narcoleptic Library benutzt den Timer1 zum Messen der Watchdogzeit(16ms) und misst die Abweichung in Microsekunden bei jedem Aufruf.
Die Wirkung der Korrektur ist bei kurzen Zeiten nicht so gravierend (Auflösung).
Daher sind die gemessenen Zeiten bei Schlafzeiten von 250ms trotz Korrektur durch die Library
ca. 249ms//255ms//256ms//255ms//252ms//250ms.(meine 6 Sensoren)
Leider muß man also jeden ATmega823P messen. Gerne hätte ich dafür ein Verfahren gefunden, das ohne individuelle Messung auskommt.
Aber da scheitere ich.
Zum Messen benutze ich einen Logikanalysator.
Bei einer eingestellten Schlafzeit von 100 000ms - zum Testen - ist die gemessene Zeit bei allen gleich bei 99 620ms.
Das bedeutet, daß eine Tiefschlafphase von z.B. 144 750ms hmid=EBD6C8 cnt=0 genau eingehalten werden kann.
Deshalb habe ich es so gelöst, daß die ersten 10 Minuten nach Reset der Sensor 250ms Pausen macht, der Sensor also gepairt und mit
den Heizungsthermostaten gepeert werden kann und danach in die lange Tiefschlafphase wechselt. Da reagiert er dann nicht mehr auf Tastendruck.
Der Stromverbrauch liegt dann bei ca. 4,5 Mikroampere.
Das Ergebnis ist, nach all dem langen Probieren und Suchen, begeisternd. Seit ca. 1 Monat laufen die ersten Sensoren, ohne ein einziges Mal
die Verbindung zu den gepeerten HM-CC-RT-DN zu verlieren. Das funktioniert auch, wenn ich den Sensor in den Kühlschrank lege.
Meine Versuche ergaben, daß der HM-CC-RT-DN seine interne Messung erst nach 5 erfolglosen Empfangsversuchen übernimmt.
Die Arduino Pro Mini mit internem RC-Oszillator waren mir so ungenau, daß ich 8MHz Keramik Quarze eingebaut habe.
Christian.
Hallo Zusammen,
nach der "Sommerpause" melde ich mich wieder zurück :)
Aus beruflichen und privaten Gründen habe ich mich die letzen Woche ein bisschen zurück gezogen.
Darum, und auch auch wegen fehlender Teile war die Sensorproduktion auch liegen geblieben.
Da die letzten Teile diese Woche nun endlich eingetrudelt sind, hab ich die Produktion wieder aufgenommen.
Alle die noch auf der Warteliste standen haben daher gestern eine Nachricht bekommen.
Falls ich jemanden vergessen oder übersehen haben sollte, bitte nicht böse sein. Einfach noch mal eine kurze Nachricht an mich senden.
Zitat von: plombe am 11 August 2016, 15:14:40
... werden bei jeder Sendung alle im Umkreis befindlichen HM-Geräte, die auf ein Burstsignal reagieren, geweckt.
Das sollte eigentlich nicht sein. Danke für den Hinweis. Das ist in meinem Umfeld noch gar nicht aufgefallen. Und dabei habe ich einige Sensoren im Einsatz.
Allerdings nur wenige Geräte die Auf Burst reagieren. Dabei hab ich aktuell keine erhöhten Energieverbrauch dort festgestellt. Ich werde mir das aber mal ansehen.
Viele Grüße
Dirk
So, meine Geräte sind soeben eingetroffen und angelernt.
Vielen Dank an Dirk!!!!
Dann fangen wir mal an :-)
Die Geräte sollen primär dazu dienen, die Rollos selbstständig hoch und runter zu fahren.
WO baue ich die Teile am Besten hin?
Direkt neben das Fenster?
In die "Sonne" oder den "Schatten"?
Habt ihr ein paar Bilder am "Einsatzort"?
Ein bisschen Code, wie ihr die Teile "auslest", bzw. "benutzt"?
VIelen dank schon mal.
Hallo,
habe mich mal hier angemeldet, da der Universalsensor die aesthetischen Probleme eines auf dem Schreibtisch herum blinkenden Arduino mit BMP280 an einen dicken USB-Kabel zur Stromversorgung, der den Luftdruck ueber ein dickes Cat6-Kabel per HTTP an die CCU2 postet, elegant loesen koennte. Zeit zum kompletten Selbstbau ist allerdings Mangelware. Darum die Frage:
Dirk,
ist noch eine Innensensor-Platine zu haben, bestueckt / unbestueckt?
Vielen Dank,
Stephan
Hallo,
ich habe den Sensor von Dirk bei mir auf dem Balkon(Südseite) angebracht. Leider war ich mit den Temp. Werten nicht so zufrieden aber leider habe ich keinen anderen Platz.
Nach langer Suche habe ich im Internet endlich ein Gehäuse gefunden.
http://www.elv.de/tfa-schutzhuelle-fuer-aussensensor.html (http://www.elv.de/tfa-schutzhuelle-fuer-aussensensor.html)
Die Temp. Werte sind deutlich besser da der Sensor vor Direkter Sonneneinstrahlung geschützt ist und durch die Rippen des Strahlungsschutzes sich auch nicht so aufheizt.
Gruß Rolf
Danke!
rvideobaers Gehäuse habe ich auch seit kurzem im Einsatz, allerdings sitzt bei mir der Sensor im Außengehäuse obenauf (u.a. wegen der Lichtmessung) und nur das Breakout-Board mit dem Temperatur-Feuchte-Sensor ist mittig im um vier Segmente gekürzten ELV-Gehäuse platziert. Das Schlüsselwort "direkte Sonneneinstrahlung" ist aber nach wie vor das Problem, die Luftzirkulation im Gehäuse scheint doch deutlich schlechter zu sein als bspw. im KS300, der nur zwei Meter entfernt genauso in der Sonne hängt, aber völlig unbeeindruckt von Sonnenschein konstante Werte liefert, während die gemessene Temperatur des Universalsensors bei Sonneneinstrahlung in Minuten um ein bis zwei Grad steigt. Daher werde ich den Boden des Gehäuses mit einem großen gittergeschützten Loch versehen. Bei rvideobaer fehlt der Boden ja komplett, das halte ich also für wirklich sinnvoll. Nur ganz ungeschützt vor Vögeln und Wespen sollte das Ding dann doch nicht sein. Das Preis-Leistungsverhältnis des Gehäuses empfinde ich dennoch als sehr gut. @rvideobaer: Die Wandhalterung hast Du offenbar nicht im Einsatz, oder was sind die beiden hellen Kringel da sonst?
Hallo,
Ich habe das Gehäuse mit den mitgelieferten Kabelbindern an meinem Markisengestell befestigt. Die Kabelbindern habe ich aber noch nicht gekürzt. Den Sensor habe ich ohne dass von Dirk gelieferte Gehäuse montiert suche da aber noch eine Lösung. Der Helligkeit Sensor funktioniert auch im Gehäuse gut. Das Gehäuse mag nicht perfekt sein aber für den Preis ist es erst einmal super.
Gruß Rolf
So. Also ich hab mal einen Sensor direkt in die Sonne gestellt.
Da er mir 48 grad anzeigt ist das mit der direkten Sonneneinstrahlung wohl nicht gut.
Sprich ich muss einen anderen Sensor nehmen für die Temperatur.
Hallo,
ich mein Modul nun seit knapp 3 Wochen im Betrieb.
Macht genau was es soll.
Die Beschattungssteuerung läuft tadellos....der WAF ist hervorragend! ;-)
Schade, das der Sommer jetzt vorbei ist und das Modul somit erst nächstes Jahr wieder zum tragen kommt.
Danke Dirk!
Viele Grüße
Christian
KAnnst du deine Definition hier rein stellen für den doif? Also wann was wie gemacht wird.
Hallo Dirk,
ich hätte Interesse an einem Innensensor. Ggfs auch einen für jedes Zimmer, falls mir der erste gefällt. Könntest Du mir ne PM schicken?
Danke
Marc
Hallo Dirk,
ich hätte Interesse an einem Außensensor und evtl. auch Innensensor. Könntest du dich bitte bei mir melden?
Danke.
Gruß Chris
Moin,
kurze Frage, ich habe an meinem AußenBoard noch ein SHT11 angeschlossen. Welche Temperatur wird jetzt benutzt, die vom SHT11 oder die von dem BMP180?
/Daniel
Feuchte und Temperatur kommen vom SHT. Der BMP180 ist nur noch für den Luftdruck zuständig.
Super, danke für die Info. Könnte eigentlich auch ins Wiki da es für den ein oder anderen eine wichtige Info ist.
/Daniel
Hallo zusammen,
ich habe den Universalsensor mit einem Nano, einem CC1101 und einem DHT22 zusammen gebaut und ich denke ich habe das zum großen Teil verstanden. So ein paar kleine Probleme habe ich da noch. Der Sensor meldet sich brav und zwar so : 2016-11-03_15:01:02 HM_534154 battery: ok
2016-11-03_15:01:02 HM_534154 humidity: 85
2016-11-03_15:01:02 HM_534154 T: 20.9 H: 85
2016-11-03_15:01:02 HM_534154 temperature: 20.9
Es hat etwas gedauert, bis ich darauf gekommen bin den Float aus der DHT22 Lib einfach mit 10 zu multipizieren um anschliessen den richtigen im FHEM angezeigt zu bekommen.
Was leider nicht so richtig will, ist das meine Luftfeutchtigkeit wieder runter geht. Irgendwie habe ic hdas Gefühl die "hängt" sich auf oder so. Temperatur geht ändert sich ein wenig, jedoch nicht viel. Okay ist ja auch innen. Aber Hum ist doch hoch und das glaube ich einfach nicht. Desweiteren werden die gesendenten Werte nur "verarbeitet" wenn die Sich auch verändert haben, was im Graphen natürlich eine etwas komische Darstellung geben kann, wenn sich nach Stunden etwas ändert. da hätte ich gerne zwischenschritte drinne.
Hat da jemand Erfahrung mit ? Also mit der Hum und dem "verarbeiten" der gesendeten Werte ?
VG
Sascha
Zitat von: Snobs am 03 November 2016, 15:29:31
Hallo zusammen,
ich habe den Universalsensor mit einem Nano, einem CC1101 und einem DHT22 zusammen gebaut und ich denke ich habe das zum großen Teil verstanden. So ein paar kleine Probleme habe ich da noch. Der Sensor meldet sich brav und zwar so : 2016-11-03_15:01:02 HM_534154 battery: ok
2016-11-03_15:01:02 HM_534154 humidity: 85
2016-11-03_15:01:02 HM_534154 T: 20.9 H: 85
2016-11-03_15:01:02 HM_534154 temperature: 20.9
Es hat etwas gedauert, bis ich darauf gekommen bin den Float aus der DHT22 Lib einfach mit 10 zu multipizieren um anschliessen den richtigen im FHEM angezeigt zu bekommen.
Was leider nicht so richtig will, ist das meine Luftfeutchtigkeit wieder runter geht. Irgendwie habe ic hdas Gefühl die "hängt" sich auf oder so. Temperatur geht ändert sich ein wenig, jedoch nicht viel. Okay ist ja auch innen. Aber Hum ist doch hoch und das glaube ich einfach nicht. Desweiteren werden die gesendenten Werte nur "verarbeitet" wenn die Sich auch verändert haben, was im Graphen natürlich eine etwas komische Darstellung geben kann, wenn sich nach Stunden etwas ändert. da hätte ich gerne zwischenschritte drinne.
Hat da jemand Erfahrung mit ? Also mit der Hum und dem "verarbeiten" der gesendeten Werte ?
VG
Sascha
Keine Änderung der Hum-Werte:
- DHT22 könnte einen Defekt haben --> direkt an GPOI des Raspberry oder einem Arduino direkt testen
- DHT22 braucht ein paar Sekunden zum "Aufwärmen". Wenn das nicht berücksichtigt ist könnte er falsche / alte Werte zurückliefern --> Prüfe die Logik ob du dem Sensor genügend Zeit gibst
Zu hohe Hum-Werte:
- Rechnet die Logik auch mit Faktor 10 zu kleinem Wert? --> Relative Humidity wird aus der Temperatur errechnet. Wenn hier ein Fehler ist, also der Wert zu klein ist wird der relative Wert zu groß
Du kannst zum Testen auch mal eine andere Lib für DHT verwenden. Gibt ja genügend.
Du schreibst dass die Werte nur geschrieben wenn diese geändert wird. Was erwartest du? Versuche mal mit Event-on-change / event-on-update ... damit werden Werte abhängig vom Event geschrieben. Würde aber erstmal den DHT22 an sich bzw. die Lib testen.
Die Source vom Wettersensor funktioniert, ich habe diese mit einem BME280 am laufen.
Hallo,
ich hoffe, der thread ist noch aktuell (seit knapp einem Monat keine Einträge mehr ?)..
Ich habe derzeit einige FS20 Komponenten im Einsatz, mit Selbstbau-Temp-Sensoren, die über WLAN reporten - Nachteil: Batterielebensdauer wegen ESP8266 ziemlich bescheiden. Jetzt habe ich hier gelesen, dass auch mal die Frage aufkam, ob es für den Universalsensor möglich wäre, statt Homematic FS20 zu sprechen - wurde leider nicht weiterverfolgt..
Meine Frage, hat sich schon jemand dran gemacht und eine Firmware gebaut, die FS20 spricht, also könnte ich mit meinem CUL in der derzeitigen Konfiguration (slowRF) die Sensoren einbinden? Mir fehlt leider aufgrund von Nachwuchs ( :) ) die Zeit, hier selber was zu schreiben, ich hoffe daher, die Frage erscheint nicht allzu unverschämt..
Was spricht gegen Homematic?
Ab ca. 10€ kannst du dir einen zusätzlichen nanoCUL selbst löten.
Hallo zusammen,
weiß jemand, wie die Spannung, ab der der Sensor Batterie nicht mehr ok anzeigt, in der Firmware festgelegt 0.15 ist? Ich dachte, ich bekomme das mit, aber mein Sensor auf dem Dach zeigt seit ca. einem Monat keine Werte mehr an. Und das Batteriesymbol zeigt immer noch grün >:(
Danke + Gruß
PeMue
das kannst du doch einstellen:
lowBatLimitTHPL | 1 to 5V | | Low batterie limit, step 0.1 V.
damit die low meldung auch vor dem "sterben" des devices kommt, muss ich über 2.0 v einstellen. ich nutze immer gebrauchte billig batterien.
Muss ich da mit attr expert experimentieren, damit ich das bekomme? Und wenn ja, was wäre da sinnvoll?
Danke + Gruß
Peter
durchaus möglich.
ich habe bei mir überall 251_anything stehen, damit mir nichts verborgen bleibt.
ok, habe gefunden wie es geht, hier steht es:
https://forum.fhem.de/index.php/topic,47089.msg388280.html#msg388280
Muss mich doch mal tiefer in die HomeMatic Materie einarbeiten ;)
Gruß PeMue
Hi Peter,
bei mir sind 2,40 V noch als okay !
R-lowBatLimitTHPL 1.6 V
kannst Du nicht ein event auf battery != ok setzen ?
kvo1
Hätte auch Interesse an einem Modul.....
Danke
Hallo,
ich möchte gern die Temperatur bei meinem Sensor anpassen, jetzt habe ich mit:
temperature_kor {(ReadingsVal("HM_Sensor","temperature",0) - 2.0)}
die Temperatur um 2 Grad nach unten korrigiert. aber wenn die zehntel Grad null sind wird die Temperatur ohne Nachkommastelle ausgegeben.
Also 3.0 °C --> 1 °C und nicht 1.0 °C.
Was mir dann wiederum die Anzeige auf meinem Wandtablet zerschießt.
Hat jemand einen Tip?
Gruß Rolf
{sprintf("%.1f",(ReadingsVal("HM_Sensor","temperature",0))-2)}
Hallo Icinger,
danke für den Tip ich werde es versuchen, Kannst Du mir noch etwas auf die Sprünge helfen was da genau gemacht wird?
Ich würde es gerne verstehen und nicht nur benutzen.
Gruß Rolf
Hallo,
es funktioniert leider nicht, der wert wird nicht aktualisiert. Ein Fehler aber auch nicht.
Gruß Rolf
Zitat von: rvideobaer am 10 Januar 2017, 10:38:27
Kannst Du mir noch etwas auf die Sprünge helfen was da genau gemacht wird?
Du gibst dem Reading nicht nur das eigentliche korrigierte Reading
((ReadingsVal("HM_Sensor","temperature",0))-2) mit, sondern formatierst das Ganze auch noch mit
sprintf("%.1f" ...Das sollte eigentlich funktionieren. Anbei mal ein funktionierendes Beispiel von mir:
attr Heizung userReadings OelToday { sprintf("%3.1f", (ReadingsVal("$name", "BrennerStundenToday", 0)) * 2.3);; }, OelLastDay { sprintf("%3.1f", (ReadingsVal("$name", "BrennerStundenLastDay", 0)) * 2.3);; }, EnergyToday { sprintf("%3.1f", (ReadingsVal("$name", "BrennerStundenToday", 0)) * 22.8);; }, EnergyLastDay { sprintf("%3.1f", (ReadingsVal("$name", "BrennerStundenLastDay", 0)) * 22.8);; }Gruß PeMue
hallo,
war mein Fehler, habe den Readingnamen vergessen, konnte so nicht funktionieren.
Nochmal Danke schön.
Gruß Rolf
Hallo
Ließe sich mit dem Universalsensor eine Spannungsmessung z.B. an einem 12 V Akku realisieren.
Hat so etwas schon mal jemand gemacht und wie müßte die Beschaltung modifizert werden:
* Step-Down-Wandler zur Spannungversorgung stat MAX?
* Teiler modifizieren?
Gruß
G.
Hallo,
ich versuche das gerade mit einem ESP 8266 zu realisieren. Da sollte das mir ESP EASY funktionieren.
Gruß Christoph
Zitat von: Bennemannc am 14 Januar 2017, 23:27:10
ich versuche das gerade mit einem ESP 8266 zu realisieren. Da sollte das mir ESP EASY funktionieren.
Hallo
Ich nehme an, das war eine Antwort auf meine Frage? Die Lösungwäre aber WLAN und nicht Bidcos, oder?
Gruß
G.
Ja, aber ich betreibe am Fhem Server einen eigenen AP - auch für den WIFI CUL. Wenn der da ist, kann der auch für andere Sachen genutzt werden. Außerdem scheit das viel einfacher zu realisieren zu sein.
Gruß Christoph
Zitat von: Gernott am 14 Januar 2017, 23:05:07
Hallo
Ließe sich mit dem Universalsensor eine Spannungsmessung z.B. an einem 12 V Akku realisieren.
Hat so etwas schon mal jemand gemacht und wie müßte die Beschaltung modifizert werden:
* Step-Down-Wandler zur Spannungversorgung stat MAX?
* Teiler modifizieren?
Gruß
G.
Willst du einen bestehenden Sensor jetzt mit 12 V speisen, oder einen neuen bauen?
Wenn neu dann ist es wahrscheinlich am einfachsten wenn du einen Arduino Nano nutzt den kannst du an VIN mit 12V versorgen. Spannung messen mit Spannungsteiler.
Hallo zusammen,
ich habe den Aussensensor seit ca. 1/2 Jahr in Betrieb. Leider gibt es immer wieder einzelne (!) Batterie-Spannungs-Einbrüche, obwohl die Batterie in Ordnung ist. Die Messwert sind in diesem Fall out-of-Range (siehe Log um 2017-01-14_14:47:54). Ich habe die Firmware 0.14 drauf.
Habt ihr ähnliches beobachtet? Was kann man dagegen tun?
Viele Grüße
Frank
2017-01-14_14:35:56 GH.ga.TH battery: ok
2017-01-14_14:35:56 GH.ga.TH luminosity: 831
2017-01-14_14:35:56 GH.ga.TH pressure-nn: 1029.8
2017-01-14_14:35:56 GH.ga.TH pressure: 1012.2
2017-01-14_14:35:56 GH.ga.TH T: 3.4 L: 831 P: 1012.2 P-NN: 1029.8
2017-01-14_14:35:56 GH.ga.TH temperature: 3.4
2017-01-14_14:44:42 GH.ga.TH batVoltage: 2.70
2017-01-14_14:44:42 GH.ga.TH battery: ok
2017-01-14_14:44:42 GH.ga.TH luminosity: 363
2017-01-14_14:44:42 GH.ga.TH pressure-nn: 1029.8
2017-01-14_14:44:42 GH.ga.TH pressure: 1012.2
2017-01-14_14:44:42 GH.ga.TH T: 3.3 L: 363 P: 1012.2 P-NN: 1029.8
2017-01-14_14:44:42 GH.ga.TH temperature: 3.3
2017-01-14_14:47:53 GH.ga.TH batVoltage: 2.70
2017-01-14_14:47:53 GH.ga.TH battery: ok
2017-01-14_14:47:53 GH.ga.TH luminosity: 713
2017-01-14_14:47:53 GH.ga.TH pressure-nn: 1029.7
2017-01-14_14:47:53 GH.ga.TH pressure: 1012.1
2017-01-14_14:47:53 GH.ga.TH T: 3.4 L: 713 P: 1012.1 P-NN: 1029.7
2017-01-14_14:47:53 GH.ga.TH temperature: 3.4
2017-01-14_14:47:54 GH.ga.TH batVoltage: 0.01
2017-01-14_14:47:54 GH.ga.TH battery: low
2017-01-14_14:47:54 GH.ga.TH humidity: 134
2017-01-14_14:47:54 GH.ga.TH pressure-nn: 2325.5
2017-01-14_14:47:54 GH.ga.TH pressure: 2307.9
2017-01-14_14:47:54 GH.ga.TH T: 207.5 H: 134 P: 2307.9 P-NN: 2325.5
2017-01-14_14:47:54 GH.ga.TH temperature: 207.5
2017-01-14_14:50:50 GH.ga.TH batVoltage: 2.70
2017-01-14_14:50:50 GH.ga.TH battery: ok
2017-01-14_14:50:50 GH.ga.TH luminosity: 689
2017-01-14_14:50:50 GH.ga.TH pressure-nn: 1029.8
2017-01-14_14:50:50 GH.ga.TH pressure: 1012.2
2017-01-14_14:50:50 GH.ga.TH T: 3.5 L: 689 P: 1012.2 P-NN: 1029.8
2017-01-14_14:50:50 GH.ga.TH temperature: 3.5
2017-01-14_14:53:26 GH.ga.TH batVoltage: 2.70
2017-01-14_14:53:26 GH.ga.TH battery: ok
... ich habe im Nachgang die Version 0.15 entdeckt.
Leider lässt sich diese nicht flashen. Es kommt die Fehlermeldung "Firmware file not valid!" für die eq3-Datei. Was mache ich falsch?
Zitat von: kadettilac89 am 15 Januar 2017, 10:51:35
Willst du einen bestehenden Sensor jetzt mit 12 V speisen, oder einen neuen bauen?
Wenn neu dann ist es wahrscheinlich am einfachsten wenn du einen Arduino Nano nutzt den kannst du an VIN mit 12V versorgen. Spannung messen mit Spannungsteiler.
Einen neuen bauen.
Aktuell ist ja die batteriegespeiste Version mit einem MAX... Step-up-Wandler versehen. Die Spannungsmessung erfolgt auf der Batterieseite. Für eine Spannungsüberwachung eines Akkus > 3.3 V könnte man nun einen Step-Down-Wandler verwenden und die Spannung über einen angepaßten Teiler messen. Das wäre alles, was man für eine reine Spannungsüberwachung mit Übertragung der Spannungswerte bräuchte.
Gäbe es eine andere und evtl. einfachere Möglichkeit, über einen Homematic-Sensor an regelmäßige Spannungswerte zu kommen? Eine reine Schwellwertüberwachung kann man mit dem batteriebetriebenen Schaltaktor realisieren. Der liefert aber keine Spannungswerte zurück.
Gruß
G.
Zitat von: Gernott am 15 Januar 2017, 12:11:10
Einen neuen bauen.
...
Gäbe es eine andere und evtl. einfachere Möglichkeit, über einen Homematic-Sensor an regelmäßige Spannungswerte zu kommen? Eine reine Schwellwertüberwachung kann man mit dem batteriebetriebenen Schaltaktor realisieren. Der liefert aber keine Spannungswerte zurück.
Gruß
G.
Willst du
1) ... nur die Spannung einer Batterie überwachen? Z. B. Motorradbatterie über Winter
2) ... den Temperatursensor mit 12V betreiben?
Zu 1: Hier kannst du jeden Aktor einsetzen der die Asksin-Lib verwendet. Spannung musst du über Widerstände (Spannungsteiler) auf >1 Volt bringen und dann an einem analogen Eingang messen. Über einen Faktor den du dir dann ausrechnest wird die Spannung hochgerechnet. Um dann einen Schwellwert anzugeben ab dem die Batterie von "OK -> nOK" geht kannst du setzen (LowBatLimit = 12 V oder ähnlich). Wenn du darauf automatisch reagieren willst kannst du einen Watchdog in Fhem anlegen.
2: Spannung überwachen oben. Ich würde wie gesagt einen Arduino nano nehmen und den mit 12 Volt versorgen, der hat einen Spannungsregler on board.
Beides ist auch ohne Platine möglich. Arduino zu CC1101 sind 5 oder 6 Kabel. Wenn du zusätzlich ein Temperatursensor ran soll dann nochmal 3 oder 4, je nach Sensor.
Schreib mal was genau du umsetzen willst, und was du schon hast (welche Bauteile oder Module). Ich durchblicke die Anforderung noch nicht ganz.
Hallo,
sollte man für diese Diskussion nicht besser einen eigenen Thread aufmachen. Ich finde das passt hier nicht so wirklich hin.
Gruß Christoph
Zitat von: Bennemannc am 17 Januar 2017, 08:09:53
Hallo,
sollte man für diese Diskussion nicht besser einen eigenen Thread aufmachen. Ich finde das passt hier nicht so wirklich hin.
Gruß Christoph
... darum meine Frage nach den Anforderungen. Wenn er den Temp-Sensor mit 12V statt 3V betreiben will --> nicht OT. Wenn er einen reinen "Spannungswatchdog" für die Autobatterie hat --> OT und besser im Asksin-Thread aufgehoben. Ich vermute auch, dass es nur um die 12V geht und nichts mit dem Temp-Sensor zu tun hat und dann hast du natürlich recht.
Ich verstehe die Einlassungen zu meiner Thematik. Zunächst wollte ich wissen, ob man den Universalsensor für diesen Zweck umbauen kann. Da ich ein neues Teil brauche, habe ich verstanden, daß offenbar die Asksin-Lösung empfehlenswerter ist. Ich bin einverstanden, mein Anliegen in einem anderen Thread fortzführen. - Ja, es geht mir um einen reinen Spannungssensor mit regelmäßiger Übertragung der Spannungswerte. Eine Schwellwertinfo habe ich hier bereits mit einem HM-Batterieschaltaktor umgesetzt, fände aber die Spannungswerte informativer.
Leider gibt es kein "follow up-to"....
Viele Grüße
G.
Zitat von: Gernott am 17 Januar 2017, 21:10:47
Ja, es geht mir um einen reinen Spannungssensor mit regelmäßiger Übertragung der Spannungswerte. Eine Schwellwertinfo habe ich hier bereits mit einem HM-Batterieschaltaktor umgesetzt, fände aber die Spannungswerte informativer.
Wie schon geschrieben am einfachsten mit einem Arduino nano. Du hast konstant 12V, wie viel mA darf die Schaltung "ziehen". Ist es eine Auto/Motorradbatterie? Oder reden wir von großen Bleiakkus für eine Photovoltaikanlage? Poste bitte im HM-Bereich, ich werde mich dann einklinken, oder schreibe mir eine PM.
Hallo,
habe ich mit Wemos D1 mini gemacht, Spannungsteiler, Spannungsregler 5V und fertig. Ultra kompakt, läuft und wird noch von der Spannungsquelle versorgt, die er überwacht - also nix mit leeren Batterien - absolut Wartungsfrei. Wenn der Accu nur noch 5 V hat, läuft das Teil immer noch - aber der Accu ist dann defekt ;-)
Gruß Christoph
Hallo Allerseits,
ich stehe hier gerade vor einem kleinen Rätsel und weiß nicht weiter....
Nach längerer Zeit habe ich endlich Zeit gefunden meinen Sensor in Betrieb zu nehmen und hatte schon beim Pairing mit der Windows Software Probleme, das hat gar nicht funktioniert :-(
Ich habe es immerhin geschafft, dass das Pairing mit FHEM klappt. Aber danach geht es nicht weiter, ich bekomme nur Timeouts beim Lesen der Parameter.
Die restlichen HM Komponenten funktionieren hingegen unter Windows und unter FHEM einwandfrei.
Anbei die Ausgabe vom FHEM, ich habe nur meine HMID geschwärzt.
Ein paar weitere Informationen zu meiner Konfiguration:
- Der Sensor hat die Firmware 0.14
- FHEM 5.7, aktuelle Updates installiert
- Ubuntu 16.04 auf einem odroid c1+
- ich verwende einen eigenen AES Key
- die HM Komponenten werden über den HM-CFG-LAN angesprochen
Gibt es hier einen Trick? Eine spezielle FHEM Konfiguration? Oder muss ich den Sensor updaten (das geht doch unter FHEM nur mit einem USB Stick)?
Grüße
Stefan
Zitat von: TheUnicornXXL am 22 Januar 2017, 21:52:26
Gibt es hier einen Trick? Eine spezielle FHEM Konfiguration? Oder muss ich den Sensor updaten (das geht doch unter FHEM nur mit einem USB Stick)?
Hast du den Config-Button im Anschluss gedrückt? Der verarbeitet dann getConfig oder andere Configs. Der Sensor beherrscht kein Lazy-Config.
ich vermute, dass die erforderliche fhem datei für den sensor nicht installiert ist, denn attr model ist unknown.
Danke Euch, jetzt hat es geklappt.
Habe noch nicht viel Erfahrung mit Fhem und seinen Tücken. Aber das wird schon :-)
@frank
Das erneute Einbinden alleine hat aber nicht gereicht. Ich musste den Sensor nochmal resetten, aus Fhem löschen und komplett neu anlernen. Danach ging es.
@kadettilac89
Laut Eintrag im Github wurde Lacy-Config anscheinend bei der aktuellen Version der pm Datei nachgerüstet.
@kadettilac89
Um die CMDs in einer vernünftigen Zeit abzuarbeiten (hatte keine Muße zum Warten :-) ) muss ich trotzdem auf die Taste des Sensors drücken.
Zitat von: TheUnicornXXL am 24 Januar 2017, 01:29:17
@kadettilac89
Laut Eintrag im Github wurde Lacy-Config anscheinend bei der aktuellen Version der pm Datei nachgerüstet.
funktioniert nicht. In Version history nicht enthalten, nur Test am 5. März 15.
Darum wie beschrieben Config Button nutzen ... "https://forum.fhem.de/index.php/topic,20620.msg423759.html#msg423759 (https://forum.fhem.de/index.php/topic,20620.msg423759.html#msg423759)
Eine Ergänzung in der pm-Datei reicht nicht - die Firmware muss das auch unterstützen - tut sie aber derzeit nicht.
Musste ich selber ergänzen (Handling von HAVE_DATA Messages und WKMEUP-Flags in der AskSin Lib) - dann geht's.
Martin
Hi Martin,
Zitat von: Linef am 24 Januar 2017, 19:13:24
(Handling von HAVE_DATA Messages und WKMEUP-Flags in der AskSin Lib)
Kannst du mir dazu noch ein Paar Info's geben. Dann baue ich das in die nächste FW-Version mit ein.
Gruß
Dirk
Zitat von: Dirk am 24 Januar 2017, 19:23:28
Hi Martin,
Kannst du mir dazu noch ein Paar Info's geben. Dann baue ich das in die nächste FW-Version mit ein.
Gruß
Dirk
Mir bitte auch ... Danke
Hi Gernot,
Zitat von: Gernott am 14 Januar 2017, 23:05:07
Ließe sich mit dem Universalsensor eine Spannungsmessung z.B. an einem 12 V Akku realisieren.
Hardwareseitig ist das das kleinere Problem. Im einfachsten Fall ein Spannungsteiler mit ein paar Widerständen an einen der freien AD-Eingänge des Sensors.
In der Firmware muss mann den Eingang dann "nur noch" abfragen und im einfachsten Fall den RAW-Wert Senden und in FEHM umrechnen.
Provisorisch gebaut, sollte das kein so großer "Akt" sein. Wenn es noch ein paar Tage Zeit hat, könnte ich dir da eine experimentelle FW für bauen.
Gruß
Dirk
Zitat von: Dirk am 24 Januar 2017, 19:23:28
Kannst du mir dazu noch ein Paar Info's geben. Dann baue ich das in die nächste FW-Version mit ein.
Ok, ich kann natürlich auch in dein Repo schauen :)
Hallo Dirk,
die Anpassungen hatte ich auf Basis der NewAskSin gemacht, da ich mit der "alten" Version bei meinem Sensor-Projekt nicht mehr starten wollte.
Die Version v1.3 in meinem Git-Repo läuft derzeit am stabilsten.
Am besten, Du hältst nach dem String WKMEUP Ausschau - das Flag habe ich an verschiedenen Stellen eingebaut, um der Zentrale zu signalisieren, daß das Device für Config-Daten empfangsbereit ist. Im Gegenzug muß aber auch die AS_MESSAGE_HAVE_DATA Message bearbeitet werden, um zu bestätigen, daß man empfangsbereit ist.
Grundsätzlich läuft es so: Mindestens bei den regelmäßigen Datensendungen wird das WKMEUP-Flag mit gesetzt. Die Zentrale erkennt das und sendet, falls sie Daten für das Device hat, eine "HAVE_DATA" Message. Auf die muß das Device dann mit einem ACK antworten. Dann sendet die Zentrale die in der Queue liegenden Datenpakete.
D.h. aber auch, daß nach jedem Senden von Daten das Device mind. 1/2 Sek. auf eine eventuelle HAVE_DATA-Message der Zentrale warten muß.
Martin
Zitat von: Dirk am 24 Januar 2017, 19:34:29
Wenn es noch ein paar Tage Zeit hat, könnte ich dir da eine experimentelle FW für bauen.
Hallo Dirk
Da würde ich mich sehr darüber freuen. Es ist nicht eilig. - Ich habe die Hardware auf dem Steckbrett zusammen, mir die IDE mal installiert, aber bisher null Erfahrung mit der Firmwareerstellung. Will es aber trotzdem mal lernen. Dann hätte ich schon mal etwas lauffähiges als Backup.
Gruß
G.
Hi Dirk und Martin,
was spricht dagegen wenn ihr beide Projekte in eines vereint? Ich habe einen Sensor auf Basis der ... ich nenne es mal ... linef-Implementierung und später habe ich basierend auf der Dirk-Version einen gebaut weil ich zu faul war den Luftdruck-Part in den von linef einzubauen (für den BME280).
Im Prinzip laufen alle Sensoren bei mir stabil mit geringem Stromverbrauch. Dirk, deiner hat das Include "Sensor_THP*" welches in der "measure"-Methode von Linef einfach gerufen werden könnte oder halt direkt im loop selbst. Zusätzlich noch den Bootloaderteil übernommen und es sollte fast schon laufen. Martin, du verwendest halt Atmel Studio, das könnte für manche Nachahmer eine Hürde darstellen. Ich habe es aber auch geschaff ... Anleitung ist ja in deinem GitHub-Projekt enthalten.
Ich würde das begrüßen weil ich dann meine quick-n-dirty Firmware gegen die von euch tauschen könnte :) ... Spass beiseite aber ich werde demnächst noch weitere Sensoren bauen, dann könnte ich es ggf. auch mit anderen Sensoren testen. Will SHT31 und nochmal BME280 bauen.
Martin, du hast eine Abwandlung der newAsksin, vielleicht noch mit trilu sprechen und eine neue newAsksin bauen dann wäre auch deine AES-Erweiterung im "Standard".
Hallo Martin,
Zitat von: Linef am 24 Januar 2017, 20:13:46
Am besten, Du hältst nach dem String WKMEUP Ausschau - das Flag habe ich an verschiedenen Stellen eingebaut, um der Zentrale zu signalisieren, daß das Device für Config-Daten empfangsbereit ist. Im Gegenzug muß aber auch die AS_MESSAGE_HAVE_DATA Message bearbeitet werden, um zu bestätigen, daß man empfangsbereit ist.
Danke schaue ich mir an.
ZitatGrundsätzlich läuft es so: Mindestens bei den regelmäßigen Datensendungen wird das WKMEUP-Flag mit gesetzt. Die Zentrale erkennt das und sendet, falls sie Daten für das Device hat, eine "HAVE_DATA" Message. Auf die muß das Device dann mit einem ACK antworten.
Das hatte ich eigentlich gemacht. Hin und wieder funktionierte das auch. Aber nicht stabil.
Zitat von: kadettilac89 am 24 Januar 2017, 21:02:41
was spricht dagegen wenn ihr beide Projekte in eines vereint? Ich habe einen Sensor auf Basis der ... ich nenne es mal ... linef-Implementierung und später habe ich basierend auf der Dirk-Version einen gebaut weil ich zu faul war den Luftdruck-Part in den von linef einzubauen (für den BME280).
Dieses Projekt werde ich mal angehen. Den Upgrade auf die neue Asksin-Version hatte ich ja schon länger geplant. Leider hat es an der nötigen Freizeit gefehlt. Martin war da schneller. :)
Freut mich aber. So werde ich mit Martin seiner Version mal den Upgrade starten.
ZitatMartin, du verwendest halt Atmel Studio, das könnte für manche Nachahmer eine Hürde darstellen. Ich habe es aber auch geschaff ... Anleitung ist ja in deinem GitHub-Projekt enthalten.
Ich versuche mal das Ganze sio zu modifizieren, dass das auch in der Arduino-IDE Kompiliert.
Ich selber nutze aktuell Eclipse mit dem Arduino-Plugin.
ZitatWill SHT31 und nochmal BME280 bauen.
Den BME280 und SHT21 oder ähnlich hatte ich schon mal im Auge für eine neue Platine (Vielleicht ein Universalsensor V2 oder so. Mal sehen.)
Zitatvielleicht noch mit trilu sprechen und eine neue newAsksin bauen dann wäre auch deine AES-Erweiterung im "Standard".
AES hatte ich "damals" im DEV-AES-Branch gepusht. Und ich meine das ist auch aktuell die Hauptentwicklungsbranch an der Trilu, Martin, und ich demnächst hoffentlich auch wieder weiter entwickeln. Daher kannst du die schon benutzen.
Es funktionieren dort ggf. noch nicht alle Beispiele.
Gruß
Dirk
Von mir aus gerne - Allerdings werden die Versionen immer leicht unterschiedlich sein, da ich andere Sensoren drauf habe und ich optional bei mir noch den 32KHz Quartz nutze.
Dirk hat schon angefragt, da er ja schon lange auf die NewAskSin-Lib gehen wollte. Und bei mir fehlt noch der Teil für die Bootloader-Unterstützung...
Mit trilu bin ich ständig in Kontakt - er entwickelt derzeit die NewAskSin-Lib komplett um, so daß das Zeug mit distillRegs nicht mehr notwendig ist. Mein Sensor läuft bereits mit dieser neuen NewAskSin, allerdings funktioniert Peering noch nicht (Pairing schon).
Vielleicht kann Dirk auf meiner Variante aufsetzen und seine Sensoren dazu bauen?
Änderungen können wir ja dann gegenseitig dank Git übernehmen. Ich werde weiterhin am Code von trilu dran bleiben, so daß dann sogar die ganz neue Lib mit einfließen könnte... ??
Die AES-Erweiterung ist nicht von mir (ich glaube, kam von Dirk?) - im Git ist derzeit der DevAES-Branch der aktuelle Entwicklungszweig - hat halt noch nicht in den Master-Branch zurückgefunden... Trilu hat aber AES jetzt in der neuen Lib mit drin und auch schon getestet.
Martin
Zitat von: Dirk am 24 Januar 2017, 21:19:19
Den BME280 und SHT21 oder ähnlich hatte ich schon mal im Auge für eine neue Platine (Vielleicht ein Universalsensor V2 oder so. Mal sehen.)
Der BME280 würde sich anbieten da er alle 3 Werte liefern könnte. Leider hab ich bis jetzt noch keinen erhalten der die Temperatur richtig misst. Man erhält zwar das Geld zurück, aber nach ewigem Warten wieder Ärger ... Die Chinesen löten die zu heiß dann ist die Kalibrierung weg. Zumindest liest man das so in Foren. Vielleicht gibt auch der Linearregler Wärme ab die den Wert verfälscht ... keine Ahnung. Hab für Temp. einen DS18B20 drauf was ich eigentlich nicht wollte.
Zitat von: Linef am 24 Januar 2017, 21:29:34
Von mir aus gerne - Allerdings werden die Versionen immer leicht unterschiedlich sein, da ich andere Sensoren drauf habe und ich optional bei mir noch den 32KHz Quartz nutze.
Schon das Gerüst ist hilfreich, wenn jemand andere Sensoren verwendet musss man nur die Lib tauschen und etwas anpassen.
Die Frequenz kann per #ifdef elegant ein- bzw. ausgeschaltet werden. Oder hast du sowieso schon drin. Ich nutze 8mhz (mini pro) und der läuft nun seit mehr als einem halben Jahr.
Hallo Martin,
Zitat von: Linef am 24 Januar 2017, 20:13:46
Grundsätzlich läuft es so: Mindestens bei den regelmäßigen Datensendungen wird das WKMEUP-Flag mit gesetzt. Die Zentrale erkennt das und sendet, falls sie Daten für das Device hat, eine "HAVE_DATA" Message. Auf die muß das Device dann mit einem ACK antworten. Dann sendet die Zentrale die in der Queue liegenden Datenpakete.
D.h. aber auch, daß nach jedem Senden von Daten das Device mind. 1/2 Sek. auf eine eventuelle HAVE_DATA-Message der Zentrale warten muß.
geht das auch mit FHEM oder nur mit ner CCU ? Ich kriege keine HAVE_DATA Message :-(
Zitat von: kadettilac89 am 24 Januar 2017, 22:18:45
Vielleicht gibt auch der Linearregler Wärme ab die den Wert verfälscht ... keine Ahnung.
So was ist nicht zu unterschätzen!
Nicht umsonst sind die Sensoren oftmals thermisch auf der Platine entkoppelt (komplette Fräsung um den Sensor herum - bis auf die Leitungszuführung).
Ich hab's bei meinen Sensoren gemerkt - da ist der DS18B20 ca. 2 cm vom Atmel entfernt.
Wenn der Atmel im vollen Power-Modus läuft, dann misst der Sensor 1,5-2 Grad mehr, als wenn der Atmel die überwiegende Zeit im Powersave ist...
Martin
Zitat von: papa am 24 Januar 2017, 22:26:18
Hallo Martin,
geht das auch mit FHEM oder nur mit ner CCU ? Ich kriege keine HAVE_DATA Message :-(
CCU hab ich jetzt nicht, aber ich denke, wenn dort lazy-Config mit anderen Devices funktioniert, dann kann das das nur über die HAVE_DATA Messages gehen.
Wahrscheinlich müssen beide Seiten zusammenspielen: die CCU muß wissen, daß das Device lazy-Config kann, und das Device muß in den Messages das WKMEUP-Flag setzen. Dann sollte von der Zentrale die HAVE_DATA Message kommen und das Device muß mit einem ACK darauf reagieren.
Martin
Zitat von: Linef am 24 Januar 2017, 22:38:54
CCU hab ich jetzt nicht, aber ich denke, wenn dort lazy-Config mit anderen Devices funktioniert, dann kann das das nur über die HAVE_DATA Messages gehen.
Wahrscheinlich müssen beide Seiten zusammenspielen: die CCU muß wissen, daß das Device lazy-Config kann, und das Device muß in den Messages das WKMEUP-Flag setzen. Dann sollte von der Zentrale die HAVE_DATA Message kommen und das Device muß mit einem ACK darauf reagieren.
Ich versuche das gerade mit nem HM-SEC-MDIR Nachbau und FHEM. Wenn ich in der Motion-Message das WKMEUP-Flag setzte, kriege ich CONFIG_START Message - aber keine HAVE_DATA. Darauf geht nen Ack raus - aber FHEM zeigt nach nach einiger Zeit ein MISSING ACK als Status an.
Motion
<- 0D 04 A2 41 56 78 90 63 90 87 01 04 C8 40
waitAck: 01
-> 10 05 A0 01 63 90 87 56 78 90 01 05 00 00 00 00 01
<- 0A 05 80 02 56 78 90 63 90 87 00
Zitat von: papa am 24 Januar 2017, 22:50:06
Ich versuche das gerade mit nem HM-SEC-MDIR Nachbau und FHEM. Wenn ich in der Motion-Message das WKMEUP-Flag setzte, kriege ich CONFIG_START Message - aber keine HAVE_DATA. Darauf geht nen Ack raus - aber FHEM zeigt nach nach einiger Zeit ein MISSING ACK als Status an.
Ich glaube, das läßt sich nur durch Trial und Error lösen oder mitsniffen eines offiziellen eq3-Devices.
Ich habe derzeit nur Sensoren im Einsatz - auch da mußte ich etwas rumprobieren. Trilu hatte mal vorübergehend einen ACK zuviel drin (im Umfeld des Pairings) und schon lief das HAVE_DATA nicht mehr richtig.
Oder: WKMEUP-Flag im ACK der HAVE_DATA Message... gaaanz schlecht - endlose HAVE_DATA und ACKs...
Am besten den Kommunikationsverlauf beobachten, und dort, wo ein Ende der Kommunikation eintritt, obwohl noch weitere Messages in der Queue sind, dort beim letzten ACK das WKMEUP einbauen. Damit bin ich recht weit gekommen.
Martin
Zitat von: Linef am 24 Januar 2017, 21:29:34
Allerdings werden die Versionen immer leicht unterschiedlich sein, da ich andere Sensoren drauf habe und ich optional bei mir noch den 32KHz Quartz nutze.
Das ist klar. Schon auf Grund der verschiedenen Sensorbestückung.
Die Platine vom Innensensor die Pads für den Quarz sogar schon vorbereitet. Der könnte da also nachträglich och bestückt werden.
ZitatDie AES-Erweiterung ist nicht von mir (ich glaube, kam von Dirk?)
Ja. Hab ich eingabaut. Ich hab im Sensor-Fall hier aber noch keinen zusatznutzen für AES im Kopf. Ok, evtl. einen remote-Aktivierung für den Bootloader. Oder vielleicht falls man signierte Sensordaten haben möchte.
Zitat von: kadettilac89 am 24 Januar 2017, 22:18:45
Der BME280 würde sich anbieten da er alle 3 Werte liefern könnte.
Ja, auf alle Fälle.
ZitatLeider hab ich bis jetzt noch keinen erhalten der die Temperatur richtig misst. Man erhält zwar das Geld zurück, aber nach ewigem Warten wieder Ärger ... Die Chinesen löten die zu heiß dann ist die Kalibrierung weg.
Ok, schauen wir mal ob ich das besser hinbekomme. Die Teile bekommt man ja mittlerweile auch bei den üblichen Distributoren.
Ich habe hier noch einen liegen den mir PeMue geschickt hatte. Bin da aber leider noch nicht dazu gekommen den auszubrobieren.
ZitatVielleicht gibt auch der Linearregler Wärme ab die den Wert verfälscht ... keine Ahnung.
Bei Sensoren in Dauerbetrieb könnte ich mir das auch vorstellen. Aber bei Sensoen die nur hin und wieder mal kurz aufwachen ist das eher nicht zu befürchten. Ich habe mal ein IR-Bild vom Innensensor aufgenommen. Der SHT10 ist hier höchstens 0,1 °C wärmer. Wobei ich mir nicht sicher bin, ob das in diesem Fall eher von der Umgebung kommt. AVR und Spannungsregler sind unauffällig.
ZitatHab für Temp. einen DS18B20 drauf was ich eigentlich nicht wollte.
Für eine Temp/Feuchte-Only-Version Würde ich alternativ vermutlich dann auf einen SHT21 zurück greifen.
Zitat von: Linef am 24 Januar 2017, 23:12:35
Ich glaube, das läßt sich nur durch Trial und Error lösen oder mitsniffen eines offiziellen eq3-Devices.
Oh man - ich habe das Funkmodule nach dem Ack von CONFIG_START sofort in den Idle-Modus geschickt. So kann man natürlich keine weiteren Nachrichten empfangen. Jetzt lasse ich das Funkmodule noch 10 Sekunden nach den CONFIG_START wach und schon funktioniert es.
Zitat von: papa am 24 Januar 2017, 23:26:07
Jetzt lasse ich das Funkmodule noch 10 Sekunden nach den CONFIG_START wach und schon funktioniert es.
Halbe Sekunde reicht - spart Batterie, falls drauf ankommt...
Martin
Zitat von: Linef am 24 Januar 2017, 23:29:56
Halbe Sekunde reicht - spart Batterie, falls drauf ankommt...
Ich denke hier kann man ruhig großzügig sein, so oft kommt das Ändern der Register ja nicht vor.
Jetzt scheint es wirklich zuverlässig zu funktionieren.
Danke
Hallo Dirk,
ich habe Interesse an Innen-/Aussensensoren. Könntest Du mir bitte eine PM schicken?
Danke, Gruß
Gerhard
Hallo Gernott,
anbei mal eine experimentelle Firmware wo ein ADC-Eingang (Arduino-Pin A2) ausgelesen wird.
Die Messung bezieht sich auf die interne Referenzspannung von 1,1 V An dem Eingang brauchst du zum Messen von 12 V also mindestens einen 1/10 Spannungsteiler.
Den kann man recht einfach z.B. mit einem 10 kOhm und einem 100 kOhm aufbauen.
A2 ist auf der oberen Pinleiste der Sensorplatine der 5. Pin von Links
Gnd ist der 2. Pin von Links
Sensor-Platine
+-----------o Eingang (0-12 V)
|¯|
| | 100 kOhm
|_|
|
A2 (5) o-------+
|¯|
| | 10 kOhm
|_|
|
GND (2) o-------+-----------o GND
Hier noch das Passende User-Reading:
ZitatExtSpannung { sprintf("%.1f", (ReadingsVal("$name", "luminosity", 0) * 12 / 9.96)) }
Da die Widerstände in der Regel eine mehr oder weniger große Tolerenz haben, kann man die gemessene Spannung im Userreading abgleichen.
Dafür den Sensor an eine bekannte Spannung anschließen ggf. ausmessen. Diesen Wert ist bei mir im Beispiel oben
12 V.
Dann den luminosity-Wert in FHEM ablesen. In meinem Beispiel oben
9.96.
Der Wert des ADC wird hier wieder im Helligkeitswert Übertragen. Der Sensor misst mit dieser Firmware also nur Temperatur / Feuchte / Luftdruck und Spannung
Die Messung und Übertragung der Spannung erfolgt in dieser experimentellen Firmware im 15 Sek.-Raster. Zum Testen ist das ganz ok, für den Dauereinsatz eher nicht.
Wenn du nicht selber Kompilieren kannst, dann baue ich dir auch noch eine Version mit einem anderen Sende-Intervall.
Und noch einen wichtigen Hinweis:Die Spannung die hinter dem Spannungsteiler am AVR raus kommt, darf nicht größer sein als die Betriebsspannung des Sensors. Bei den meisten, bei denen der Max 1724 bestückt ist, sind das 3,3 V. Der AVR misst hier aber ohnehin nur bis 1,1 V (interne Referenz) Also werden alle Spannungen größer 1,1 V die hinter dem Spannungsteiler ankommen mit 10.23 im luminosity-Reading angezeigt. Daher den Spannungsteiler evtl. etwas größer Dimmensionieren.
Edit:
Der Code liegt im Repo in der Branch US100-ADC
https://github.com/kc-GitHub/Wettersensor/tree/US100-ADC
Die wichtigen Änderungen sind dort im Subrepo der AskSin-Lib (Firmware-Src/Libraries/AskSin)
https://github.com/kc-GitHub/AskSin/tree/US100-ADC
@gerassimo,
Du hast Post :)
Viele Grüße
Dirk
hi dirk,
sollte die schaltung nicht besser so aussehen?
Sensor-Platine
+-----------o Eingang (0-12 V)
|
|¯|
| | 100 kOhm
|_|
|
A2 (5) o-------+
|
|¯|
| | 10 kOhm
|_|
|
GND (2) o-------+-----------o GND
gruss frank
Verdamt, du hast recht. Danke.
Ich habs geändert.
Zitat von: Dirk am 26 Januar 2017, 18:12:27
anbei mal eine experimentelle Firmware wo ein ADC-Eingang (Arduino-Pin A2) ausgelesen wird.
Hallo Dirk
Ich habe mich mal durchgekämpft und zum Schluß Deine Firmware über hmusb-OTA installiert. Leider startet der Sensor damit nicht. Am Ende des Flashvorganges fehlt das
Device rebootedDie LED hat weiterhin einmal lang und 2x kurz geblinkt.
Ich habe dann mal die normale Firmware v0.15 geflasht. Heureka! Da hat sich mein Arduino Nano brav als Innenraumsensor gemeldet. Also, prinzipiell geht es, nur die Spezialfirmware hängt beim Flashen.
Ergänzung:Da ich ja keinen Universalsensor habe, habe ich einfach den Teilerausgang an A1 gehängt. Damit bekomme ich die Spannung dann schon mit der Originalfirmware gemessen. Die Stufen sind nur etwas grob aufgelöst (0.1 V roh, ~0.3 V nach Korrektur). Das wurde wohl damals zur Beruhigung der Anzeige so eingerichtet. Werde also mich mal in die Firmware hineinvertiefen und mir eine geänderte Version kompilieren. Der Nano zieht im Betrieb etwa 6 mA, kommt vermutlich von der hellen roten Betriebs-LED. Bin froh, überhaupt soweit gekommen zu sein. Vielen Dank noch einmal!
Gruß
G.
Hallo,
ich bin von meinem Pi1 auf einen Pi3 umgezogen und bin in diesem Zuge von einem CUL auf einen HM-MOD-RPI-PCB umgestiegen (plus einen HM-LAN).
Jetzt ist mir folgendes aufgefallen: Mein HB-UW-Sen-THPL-O wird zwar noch erkannt, aber die Readings werden nicht mehr ausgelesen (Timeout).
erst nachdem ich das IO-Device auf mein HM-Lan umgestellt habe werden auch die Readings wieder ausgelesen.
Kann das jemand bestätigen? Gibt es da eine Lösung zu?
VG
Christian
Hallo Dirk,
ich habe Interesse an Innen- und Aussensensoren.
Kannst Du mir bitte eine PM schicken?
Besten Dank.
Heiko
Zitat von: Dirk am 26 Januar 2017, 18:12:27
Edit:
Der Code liegt im Repo in der Branch US100-ADC
https://github.com/kc-GitHub/Wettersensor/tree/US100-ADC
Hallo Dirk
Habe Deinen Code nach einigen Versuchen zum Laufen bekommen. Mir war aber aufgefallen, daß die Spannungswerte doch ziemlich streuen. Der Teilerausgang war stabil. Also habe ich mal den Aref oszillografiert. Da gibt es nach dem Einschalten eine ziemliche Spitze und es dauert bei meinem Nano etwa 1 bis 1.2 ms bis die Referenz stabil ist. Also habe ich den Start der Messung um 2 ms verzögert. Mit dieser Variante scheint mir nun das Resultat deutlich stabiler. Soweit ich gesehen habe, besteht das Problem mit Deiner Batteriemessung gegen die interne Referenz auch. Hier mal der geänderte Code aus der Sensor_SHT10_BMP085_TSL2561.cpp:
uint32_t SHT10_BMP085_TSL2561::adcMeasuer() {
uint16_t adcValue = 0;
ADMUX = ((1 << REFS1) | (1 << REFS0) | ADC_PIN); // Voltage Reference = Internal 1.1V Voltage Reference
ADCSRA = (1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0); // Set ADC prescaler
ADCSRA |= (1 << ADEN); // Enable ADC
_delay_ms(2); //**Wait until internal reference voltage is stable
ADCSRA |= (1<<ADSC); //**Dummy measurement
while (ADCSRA & (1<<ADSC) ) { //**Wait for completion
}
(void) ADC; //**Read once
for(int i = 0; i < ADC_NUM_MESS; i++) {
ADCSRA |= (1 << ADSC); // start conversion
while (ADCSRA & (1 << ADSC)) {} // wait for conversion complete
adcValue += ADC; //**ADC is the same as ADCW
}
ADCSRA &= ~(1 << ADEN); // ADC disable
adcValue = adcValue / ADC_NUM_MESS;
return adcValue;
}Viele Grüße
G.
Hi Dirk,
ich habe gesehen, dass du im Github eine v1.0 mit der NewAsksin baust. Wie ist der Stand dieses Branch-Zeigs. Sollte es schon halbwegs funktionieren? Ich möchte mir 2 Sensoren mit SHT30 bauen und würde die neue Version als Basis nutzen.
Sollte die IDE-Entwicklungsumgebung gehen, ich weiß dass du Eclipse verwendest, ich glaube als Compiler wird hier auch auf die Arduino-IDE zurück gegriffen oder?
Zitat von: Gernott am 02 Februar 2017, 22:35:25
Ich habe mich mal durchgekämpft und zum Schluß Deine Firmware über hmusb-OTA installiert. Leider startet der Sensor damit nicht. Am Ende des Flashvorganges fehlt das
Device rebooted
Die LED hat weiterhin einmal lang und 2x kurz geblinkt.
Ich habe dann mal die normale Firmware v0.15 geflasht. Heureka! Da hat sich mein Arduino Nano brav als Innenraumsensor gemeldet. Also, prinzipiell geht es, nur die Spezialfirmware hängt beim Flashen.
Das ist merkwürdig. Ich schaue mir das die Tage einmal an.
ZitatErgänzung:
Da ich ja keinen Universalsensor habe, habe ich einfach den Teilerausgang an A1 gehängt. Damit bekomme ich die Spannung dann schon mit der Originalfirmware gemessen. Die Stufen sind nur etwas grob aufgelöst (0.1 V roh, ~0.3 V nach Korrektur). Das wurde wohl damals zur Beruhigung der Anzeige so eingerichtet. Werde also mich mal in die Firmware hineinvertiefen und mir eine geänderte Version kompilieren. Der Nano zieht im Betrieb etwa 6 mA, kommt vermutlich von der hellen roten Betriebs-LED. Bin froh, überhaupt soweit gekommen zu sein. Vielen Dank noch einmal!
Du kannst dir auch mal den "NewAsksin-Branch" ansehen den kadettilac89 schon entdeckt hat. da ist die Spannungsmessung schon mit eingebaut. Ist aber noch nicht ganz fertig, vor allem der FHEM-Teil muss noch angepasst werden. Da kommen auch noch ein paar neue Register dazu.
Zitat von: kadettilac89 am 10 Februar 2017, 21:18:50
ich habe gesehen, dass du im Github eine v1.0 mit der NewAsksin baust. Wie ist der Stand dieses Branch-Zeigs. Sollte es schon halbwegs funktionieren?
Ja, Funktioniert schon soweit. Ist aber noch nicht voll getestet.
Dind auch schon ein paar neue Funktionen eingebaut. die beiden letzten 4 Bytes der Message enthaten aktuell die Spannung am ADC2 und die Echolänge von einem Ultraschallsensor.
ZitatIch möchte mir 2 Sensoren mit SHT30 bauen und würde die neue Version als Basis nutzen.
Mach das. Ich will vielleicht die Sensor-Funktionen noch Kapseln, so dass man mit wenig Änderungen andere Sensoren andocken kann. Mal schauen.
ZitatSollte die IDE-Entwicklungsumgebung gehen, ich weiß dass du Eclipse verwendest
Das ist das Ziel. Hab ich aber noch nicht getestet. Probier es mal Bugfixes kann ich dann mit einbauen.
Zitatich glaube als Compiler wird hier auch auf die Arduino-IDE zurück gegriffen oder?
Ja, ich benutze das Arduino-Plugin in Eclipse. Aber noch eine etwas ältere Version.
@hastrobe, hast ne PM
Zitat von: Gernott am 08 Februar 2017, 23:13:49
Habe Deinen Code nach einigen Versuchen zum Laufen bekommen. Mir war aber aufgefallen, daß die Spannungswerte doch ziemlich streuen. Der Teilerausgang war stabil. Also habe ich mal den Aref oszillografiert. Da gibt es nach dem Einschalten eine ziemliche Spitze und es dauert bei meinem Nano etwa 1 bis 1.2 ms bis die Referenz stabil ist. Also habe ich den Start der Messung um 2 ms verzögert.
Ok, guter hinweis. Soweit hatte ich das noch gar nicht getestet. Das werde ich in der neuen FW. berücksichtigen.
Viele Grüße
Dirk
Zitat von: Dirk am 10 Februar 2017, 23:20:36
Ja, Funktioniert schon soweit. Ist aber noch nicht voll getestet.
Dind auch schon ein paar neue Funktionen eingebaut. die beiden letzten 4 Bytes der Message enthaten aktuell die Spannung am ADC2 und die Echolänge von einem Ultraschallsensor.
Hi Dirk, ich habe mal zum Testen den Sketch auf einen Arduino nano gespielt. Ich habe nicht geschafft lowBatLimitTHPL auf einen anderen Wert zu setzen. Sollte das weiterhin per Config-Button gegen Masse funktionieren? Oder nur warten (lazy config)? Nach dem Drücken des Config-Buttons hatte ich dann ACK Missing oder ähnlich als Status und CMDs failed. Ich habe jetzt erstmal mit der alten Firmware gearbeitet.
Kann es sein, dass die Frequenz ein Problem macht? Der nano hat 16mhz ... kein Asksin Bootloader sondern die Serial / pairinginformation manuell gesetzt. Parameter auch auf 0 gesetzt damit die Werte nicht aus dem Bootloader gelesen werden.
Ich warte bis deine neue Version zum Testen freigegeben wird. Will dich nicht mit irgend welchen Problemen nerven solange du noch am Bauen bist.
Noch eine Frage da du dich in Asksin auskennst, weißt du warum in Asksinneu keine interne Spannungsmessung mehr enthalten ist? War in der alten in Battery.cpp enthalten.
Dirk hat einige Anpassungen von mir übernommen - ich habe seine Version mal getestet - hat bereits gut funktioniert.
Auch lazy Config. Das muss natürlich auch in der entsprechenden Datei in FHEM konfiguriert werden.
Batteriemessung ist weiterhin enthalten. Sogar mit 1/100V.
Taster sollte auch weiterhin gegen Masse geschaltet sein.
Martin
Hallo zusammen,
kann mir mal jemand bitte sagen, wie die Überprüfung der Spannung richtig funktioniert? Ich bin der Meinung, dass ich das Register lowBatLimitTHPL gesetzt habe. Muss ich sonst noch was machen? Die Batterie ist bei der Kälte vor zwei Wochen wieder in die Knie gegangen und ich habe es nur am ActionDetector gemerkt. Hier mal eine List meines Sensors:
Internals:
CHANGED
DEF F10001
IODev PMCUL01
LASTInputDev PMCUL01
MSGCNT 15
NAME HM_Dach_T_P_L
NR 241
NTFY_ORDER 50-HM_Dach_T_P_L
PMCUL01_MSGCNT 15
PMCUL01_RAWMSG A140DA270F10001F1000000C70026AF000005F40A8C::-70:PMCUL01
PMCUL01_RSSI -70
PMCUL01_TIME 2017-02-11 19:19:52
STATE T: 19.9 L: 15.24 P: 990.3 P-NN: 1018.5
TYPE CUL_HM
lastMsg No:0D - t:70 s:F10001 d:F10000 00C70026AF000005F40A8C
protCmdPend 3 CMDs pending
protLastRcv 2017-02-11 19:19:52
protSnd 15 last_at:2017-02-11 19:19:52
protState CMDs_pending
rssi_at_PMCUL01 avg:-70.4 min:-75 max:-67.5 lst:-70 cnt:15
Readings:
2017-02-11 18:50:38 Activity alive
2017-02-02 19:28:54 D-firmware 0.15
2017-02-02 19:28:54 D-serialNr USO6607220
2017-02-11 18:40:58 R-lowBatLimitTHPL set_1.8 V
2017-02-11 19:19:52 batVoltage 2.7
2017-02-11 19:19:52 battery ok
2017-02-11 19:19:52 luminosity 15.24
2017-02-11 19:19:52 pressure 990.3
2017-02-11 19:19:52 pressure-nn 1018.5
2017-02-11 19:19:52 state T: 19.9 L: 15.24 P: 990.3 P-NN: 1018.5
2017-02-11 19:19:52 temperature 19.9
cmdStack:
++A001F10000F1000100050000000000
++A001F10000F1000100081212
++A001F10000F100010006
Helper:
HM_CMDNR 13
PONtest 1
mId F102
rxType 156
Expert:
def 1
det 1
raw 0
tpl 0
Io:
newChn +F10001,02,00,00
nextSend 1486837192.27264
prefIO
rxt 2
vccu
p:
F10001
00
00
00
Mrssi:
mNo 0D
Io:
PMCUL01 -68
Prt:
bErr 0
sProc 2
Q:
qReqConf 00
qReqStat 00
Role:
chn 1
dev 1
Rpt:
IO PMCUL01
flg A
ts 1486837192.18684
ack:
HASH(0x1596df8)
0D8002F10000F1000100
Rssi:
At_pmcul01:
avg -70.4
cnt 15
lst -70
max -67.5
min -75
Shadowreg:
RegL_00. 12:12
Attributes:
IODev PMCUL01
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
event-min-interval state:360,batVoltage:43200
event-on-change-reading battery
event-on-update-reading state,batVoltage
expert 1_allReg
firmware 0.15
model HB-UW-Sen-THPL-O
peerIDs 00000000,
room 0_Dach
serialNr USO6607220
subType THPLSensor
Blöderweise funktioniert auch der Wettermast meiner WS500 Wetterstation nicht mehr , sprich bei mir auf dem Dach ist gerade echt tote Hose ;D
Danke für Eure Hilfe.
Gruß Peter
Zitat von: PeMue am 11 Februar 2017, 19:28:47
Ich bin der Meinung, dass ich das Register lowBatLimitTHPL gesetzt habe. Muss ich sonst noch was machen?
Das Reading steht noch auf set_, daher wird es noch nicht übernommen worden sein. Der noch aktive Wert war wohl bei 1.0 V, das war bei mir der Originalwert. Da kann eine der beiden Batterien/Akkus schon völlig leer bzw. umgepolt sein.
Bei meinen Sensoren habe ich zur Übernahme immer mehrfach den Anlernknopf drücken müssen, bis alle pending commands abgearbeitet waren. Danach immer ein getConfig zur Kontrolle machen und wieder ein paar Mal drücken.
Gruß
G.
Zitat von: Gernott am 11 Februar 2017, 21:44:43
Das Reading steht noch auf set_, daher wird es noch nicht übernommen worden sein.
Ok, einmal Anlernknopf drücken und das set_ ist weg. Dann muss ich das wohl beim Innensensor auch noch machen ;) Vielen Dank.
Gruß Peter
Wenn Du der Sache nicht traust, kannst Du ja mal statt Batterie ein regelbares Netzteil anschließen und die Spannung langsam unter die Schwelle senken. Versuch macht kluch...
Gruß
G.
Zitat von: Gernott am 11 Februar 2017, 23:01:37
Wenn Du der Sache nicht traust, kannst Du ja mal statt Batterie ein regelbares Netzteil anschließen und die Spannung langsam unter die Schwelle senken. Versuch macht kluch...
Solange der Sensor temporär auf dem Schreibtisch liegt und nicht auf dem Dach hängt, geht das alles ;D Aber genau das hatte ich vor. Die Bosch Rauchmelder stehen als nächstes auf dem Programm (mal schauen, ob die Mail vor dem Piepsen kommt) ...
Gruß PeMue
Zitat von: Gernott am 11 Februar 2017, 21:44:43
Bei meinen Sensoren habe ich zur Übernahme immer mehrfach den Anlernknopf drücken müssen, bis alle pending commands abgearbeitet waren. Danach immer ein getConfig zur Kontrolle machen und wieder ein paar Mal drücken.
Die bisherige Version hat Lazy-Config nicht implementiert. Zwar ist in der FHEM-Datei HMConfig_SenTHPL.pm das lc-Flag gesetzt, so daß FHEM die Funktion nutzen kann, aber in der Firmware des Sensors ist die Funktionalität nicht implementiert - deshalb muss immer noch bei jeder Config-Änderung der Knopf gedrückt werden.
Die Funktionalität wird jetzt dann aber kommen - läuft auf meinen Sensoren seit über einem halben Jahr bestens.
Martin
Zitat von: Linef am 11 Februar 2017, 23:58:03
Die Funktionalität wird jetzt dann aber kommen
Der eigentliche Antrieb des Fortschritts ist Bequemlichkeit! Danke für die Entwicklung.
Gruß
G.
Zitat von: kadettilac89 am 11 Februar 2017, 18:40:58
Kann es sein, dass die Frequenz ein Problem macht? Der nano hat 16mhz ... kein Asksin Bootloader sondern die Serial / pairinginformation manuell gesetzt. Parameter auch auf 0 gesetzt damit die Werte nicht aus dem Bootloader gelesen werden.
Bei 16 MHz kommt bei der Spannungsmessung ein weiteres Problem hinzu: der ADC wird bei einem Prescaler von 64 dann mit 250 KHz betrieben - das liegt außerhalb der Sollspezifikation von 50-200KHz. Ist zwar erlaubt, reduziert dann aber die Genauigkeit. Also dann besser den Prescaler auf 128 setzen.
Martin
Zitat von: Linef am 12 Februar 2017, 00:26:15
Bei 16 MHz kommt bei der Spannungsmessung ein weiteres Problem hinzu: der ADC wird bei einem Prescaler von 64 dann mit 250 KHz betrieben - das liegt außerhalb der Sollspezifikation von 50-200KHz. Ist zwar erlaubt, reduziert dann aber die Genauigkeit. Also dann besser den Prescaler auf 128 setzen.
Martin
Hi Martin,
Spannungsmessung war nicht das Problem. Ich hatte im Serialmonitor etliche "Timed out" messages und im Status Missing ACK. Habe nun das selbe Setup mit einem Pro Mini 8MHz gemacht und der lief auf Anhieb. Meine Vermutung war, dass der Takt 16Mhz das Timing mit dem Cul / Fhem nicht vertragen hat. Vielleich hätte ich irgendwo in einem Lib noch den Takt eintragen müssen. Aber egal, habe nun am Breadboard ein Setup mit SHT31 laufen und der meldet fleißig Werte.
Der Takt muss auf jeden Fall irgendwo eingetragen werden, da an einigen Stellen ein _delay_ms(...) verwendet wird (z.B. bei der Ansteuerung des CC1101) und dieser Delay basiert direkt auf dem CPU-Takt!
Bei mir (Atmel-Studio) muss er global über das Define F_CPU=8000000 gesetzt werden.
Martin
Zitat von: Linef am 12 Februar 2017, 10:57:00
Der Takt muss auf jeden Fall irgendwo eingetragen werden, da an einigen Stellen ein _delay_ms(...) verwendet wird (z.B. bei der Ansteuerung des CC1101) und dieser Delay basiert direkt auf dem CPU-Takt!
Bei mir (Atmel-Studio) muss er global über das Define F_CPU=8000000 gesetzt werden.
Martin
Die grundsätzliche Takteinstellung erhält der Compiler durch die Vorgabe von Typ und Takt/Spannung in den IDE-Einstellungen, das habe ich auch richtig gesetzt. Das spiegelt die F_CPU in Atmel wider. Ich habe auch einen 16mhz mit alter Firmware am laufen ohne dass ich was im Sourcecode änderte. Wahrscheinlich ist es im Sourcecode auch noch enthalten oder der Quarz auf dem nano ist zu ungenau. Ich habe vor einer Weile mit fuses und Takt rumgespielt, wenn hier im Compiler 8 statt 16 ausgewählt wird kann man nicht mal pairen ... was aber bei mir funktioniert hatte.
Ist aber nicht mehr relevant, werde sowieso meine Sensoren mit pro mini bauen da diese auch weniger Strom brauchen. Nanos sind komfortabler zum Testen da USB gleich mit an Board ist ....
Zitat von: Dirk am 10 Februar 2017, 23:20:36
Du kannst dir auch mal den "NewAsksin-Branch" ansehen den kadettilac89 schon entdeckt hat. da ist die Spannungsmessung schon mit eingebaut. Ist aber noch nicht ganz fertig, vor allem der FHEM-Teil muss noch angepasst werden. Da kommen auch noch ein paar neue Register dazu.
Hi Dirk, wenn du schon neue Register hinzufügst, kannst du einen Korrekturfaktor für die Spannung vorsehen? Ich habe mehrere Sensoren auf mini pro laufen. In jedem habe ich mit Faktoren in der Logik rumgespielt bis die Spannung passte, wahrscheinlich ist die interne 1.1V nicht so genau wie ich das gerne hätte (lt. Spezifikation 10%). 1 Byte wäre ausreichend, man kann durch 100 dividieren, 100 genau was die Logik ausgibt, 120 wären dann 20% mehr (Faktor 1.2).
Danke
Nabend, mal eine Frage, ich habe einen SHT11 dran, allerdings sehen die Plots etwas komisch aus. Es war ja heute warm aber so warm nun auch wieder nicht, und dazu die Feuchtigkeit... Was passiert eigentlich wenn der SHT11 ausfällt? Schaltet der unbemerkt auf die onBoard Temperatur um? Ich weiß nicht ob die SHT11 genauso kurzlebig sind wie die DHT22 im Außenbereich. Aber der Plot lässt ja vermuten das da was nicht stimmt.
/Daniel
Sieht nach direkter Sonneneinstrahlung aus...
Gesendet von meinem Toaster.
Da ist keine Sonne wo der Sensor ist.
Und wieso steht die Feuchtigkeit wie eine 1 da, das geht nicht.
Also der SHT11 ist wirklich ausgefallen, sieht auch etwas verkeimt aus. Glaube ich muss den eingießen im Außeneinsatz.
@Dirk: Kann man da was einbauen, das man sieht welcher Sensor gerade verwendet wird?
/Daniel
Komisch, ich habe seit drei Tagen das gleiche Problem - zumindest bekomme ich seit drei Tagen konstant 96% Luftfeuchte gemeldet. Temperatur kommt noch aber noch.
Aber ich frage mich auch wie Daniel, ob ich die Temp nur bekomme, weil das Gerät unbemerkt auf den onboard BMP180 umschaltet. Ich dachte nämlich, der SHT10 arbeitet ja noch, der liefert ja ne Temperatur...
Bei mir hängt der SHT10 in einem extra Gehäuse untendran, wegen der besseren Belüftung und geringeren Sonnenempfindlichkeit. In diesem Einsatz zeigt er eine gute Korrelation mit meinem darüber hängenden KS300. Genau diese Korrelation geht zeitlich mit dem Ausfall der Feuchtemessung flöten (ich habe das im Plot mit einer orangen Linie markiert). Die Temperatur des Universalsensors (dick grün) zeigt im ansteigenden Ast ein deutliches Überschwingen gegenüber dem KS300 (dick rot) - genau wie ich es von früher auch mit dem SHT10 kannte, als der noch nicht so gut belüftet hing.
Mein Sensor ist aber trocken und sauber. Die Platine ist evtl. feucht geworden wegen Schwitzwasser. Ich check das nochmal.
Summa: Meinen SHT10 scheint es entschärft zu haben. Kann man den SHT11 ohne weiteres als Ersatz nutzen? Geklärt: SHT10,11 und 15 kompatibel, nur jeweils genauer.
@Daniel: Woher bekommst Du günstig Ersatz?
Edit2: ich habe den Sensor nochmal auseinandergenommen und alles geprüfte. Nach dem Einsetzen der Batterien ... Geht wieder alles. :-\
Also es ist definitiv so das der auf intern umschaltet, kann man mit einem Feuerzeug ja schnell ausprobieren ;-)
Ich habe meine SHT11 bei ebay gekauft. Ob das wirklich Originale waren weiß ich nicht.
Ich hatte diese hier gekauft:
http://www.ebay.de/itm/5-Stuck-SHT11-Feuchte-und-Temperatursensor-mit-Stecker-/282361078936?hash=item41be082498:g:2vUAAOSwstxVQfQB
Meiner war innen schon total vergammelt. Also Wetterfest sind die nicht so wirklich. Ich hab den jetzt getauscht. Mal schauen wie lange das gut geht. Ein Reset ist immer blöd weil ich die Batterien entfernen muss. Wäre auch ein Feature request das ich ein Reset über FHEM ausführen kann ;-)
/Daniel
Bei Ali* findet man Sensoren incl. wasserfester Hülle. So etwas in der Art habe ich seit über einem Jahr (nachdem mein SHT10 auch 'verrotet' ist): https://de.aliexpress.com/item/2pcs-lot-Double-waterproof-PE-temperature-and-humidity-detection-sensor-probe-SHT10-soil-temperature-and-humidity/32758879181.html
Diesen würde ich nicht mehr kaufen, weil die Mutter an dem Unterteil zu rosten angefangen ist.
Evtl. probiere ich mal andere, es gibt genug verschiedene:
https://de.aliexpress.com/item/2PCS-LOT-PEG70-temperature-and-humidity-sensor-shell-cover-SHT10-SHT11-waterproof-SHT20-high-humidity/32714408421.html
https://de.aliexpress.com/item/Temperature-and-humidity-sensor-casing-protective-sleeve-SHT11-SHT20-SHT30-SHT10-waterproof-connector/32780644779.html
Und wie sieht es da mit der Luftfeuchtigkeit aus? Also wird das alle träger beim Messen?
Aber die sehen ja auch geil aus, ne Messinghülse und dann eine Kabeldurchführung von IP66 Gehäusen. Sehr nett, aber gut wenn es funktioniert. Interessant ist ja nur die Membran am Ende.
/Daniel
Die Membran lässt ja Wasserdampf problemlos durch, ist auch nicht wirklich Wasserdicht, hält es aber gut genug von dem Sensor fern.
Für die SHT1x gibt es auch eigens Hütchen mit Membran zum Einbau, hatte ich derweil gesehen. Kriegt man halt nicht. Die 5er-Packung bei e*** habe ich auch schon gesehen, sonst werden ja völlige Mondpreise in D aufgerufen *tocktocktock*
via Tapatalk
Diese Tüllen sind aber reiner Goldstaub kann das sein? Da kann ich ja 10 Jahre lang den Sensor wechseln...
Hallo,
ich habe eine CCU2 als RaspberryMatic aufgesetzt und bekomme einen HB-UW-Sen-THPL-I nicht gepaired. Er ist mit der 0.15 geflashed. An der HMLan mit Fhem war das kein Problem.
In Fhem hab ich den Sensor erst auf unpair gesetzt und dann gelöscht.
Klappt das bei euch?
Hallo zusammen,
sorry, dass ich hier so doof Frage, aber ich habe bei über 150 Seiten Forum AskSin / NewAskSin und verschiedenen Versionen der Wetterstation Software absolut den Überblick verloren.
Ich habe diese Version https://github.com/kc-GitHub/Wettersensor/tree/Firmware_newAsksin (https://github.com/kc-GitHub/Wettersensor/tree/Firmware_newAsksin) der Software mit der Arduino IDE 1.8.2 auf meinen Pro Mini 3,3V 8Mhz und CC1101 868Mhz Funkmodul aufgespielt. Kompilieren und hochladen verläuft ohne Probleme. Mit dem Schalter bekomme ich den Arduino auch zur Ausgabe verschiedener Blinkcodes. Der Serielle Monitor zeigt auch sinnvolle Ausgaben.
Starting sketch for HB-UW-Sen-THPL (May 2 2017 16:15:39)
AskSin-Lib V 0.2.4
Get HMID and HMSR from Bootloader-Area
SerialData: FF FF FF FF FF FF FF FF FF FF FF FF FF
Master-ID: 00 00 00
Ready.
lowBat: 21
led: 64
bRx: 0
transTryMax: 3
alt: 0
<- 18 00 82 70 FF FF FF 00 00 00 4F 97 00 00 00 00 64 00 C8 13 A4 00 00 00 00 (1415)
<- 1A 01 86 00 FF FF FF 00 00 00 10 FF FF FF FF FF FF FF FF FF FF FF FF 70 01 01 00 (165254)
<- 18 02 82 70 FF FF FF 00 00 00 4F 97 00 00 00 00 64 00 C8 13 A4 00 00 00 00 (166664)
Der CC1101 funktioniert (habe den an einem Raspberry mit homegear getestet) und ich habe Ihn höchstwarscheinlich auch richtig an den Arduino angeschlossen (nach Schaltplan im Wiki und Abgleich der comments im .ino Code).
Mein Problem ist allerdings, dass ich ihn nicht mit homegear gepaired bekomme. Ich muss dazu sagen, dass ich bisher weder einen Sensor angeschlossen habe, noch etwas in der Register.h eingetragen habe. Was müsste denn passieren? Müsste er in der homegear Liste erscheinen? Wenn ja, als was für ein Gerät? Ist es ein Problem, dass ich nichts in der Register.h eingetragen und noch keinen Sensor angeschlossen habe oder müsste er auch mit den Dummy-Werten erkannt werden? Ist das langsame Dauerblinken der Pairmodus?
Hoffe ihr könnt mir helfen :) Danke
Viele Grüße
Andi
Hast du nach dem Pairversuch den Config-Button an deinem Nano-CC1101-Aufbau gedrückt?
Ich starte zuerst den Arduino, dann das Pairing in Homegear und dann einmal kurz den Configbutton am Arduino. Im Homegear Errorlog erscheint dann die Nachricht, dass der Gerätetyp 0xFFFF nicht erkannt werden kann. Falls die Vorgehensweise falsch ist, wie läuft das Pairing richtig ab?
USE_ADRESS_SECTION steht auf 1, woher bekäme der Arduino einen Gerätetyp?
wenn du das log anschaust steht dass du die Seriennummer und HMID aus dem Bootloader ziehst. Wenn du keinen Askin-Bootloader geflashed hast dann musst du den Sourcecode nochmal prüfen. Wenn du Seriennummer und HMID manuell im Source setzen wiilslt musst du das "use_adress-section" an 2 stellen setzen. Hast du das? Stellen musst du dir suchen, hab keinen Zugriff auf meine Sketches.
WetterSensor.h
/**
* Must set in AskSinMain.h too !!!
*
* Set to 1 to read address data from end of bootloader section
* Set to 0 to read address data from program space
*/
#define USE_ADRESS_SECTION 1
==> Adress-Secion = 1 wenn du Werte aus dem Bootloader verwenden willst, ansonsten 0 um die Werte aus dem Sourcecode zu verwenden. Zu setzen in WetterSensor.h + AskSinMain.h
Danke schonmal für deine Antworten.
Ich glaube das Problem geht schon da los, dass ich die newasksin library verwende, so wie im Github vom WetterSensor verlinkt.
newasksin.h enthält USE_ADRESS_SECTION nicht.
Dennoch habe ich mal USE_ADRESS_SECTION = 0 in der Register.h gesetzt und folgende HM Parameter eingestellt:
// HMID, Serial number, HM-Default-Key, Key-Index
uint8_t HMSerialData[] = {
/* HMID */ 0x11, 0x12, 0x13,
/* Serial */ 'N','E','Q','1','1','1','1','1','1','1',
/* Default-Key */ 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,
/* Key-Index */ 0xFF
};
uint8_t dev_static[] = {
/* firmwareVersion 1 byte */ FIRMWARE_VERSION,
/* modelID 2 byte */ 0x00,0x40,
/* subTypeID 1 byte */ 0x70,
/* deviceInfo 3 byte */ 0x01,0x01,0x01,
};
Damit wird jetzt sogar ein gerät in Homegear gepaired, aber trotzdem gibt es da noch Probleme:
Die Serialnummer ist 000A00 und das wars auch schon. Serial number = "alt:" und dann bricht die Zeile ab.
Type etc. zeigt mir die Homegear CLI dann schon garnicht mehr an.
Ich würde an deiner Stelle erstmal nur die Einstellungen (Model-ID und so) verwenden die im Code sind und nur USE_ADRESS_SECTION umstellen. Ist Model-ID 00 40 definiert? F1 01 ist es, ist der Temp-Sensor.
Wenn das dann funktioniert kannst den Typen ändern und weitermachen.
Die Aussage von mir mit den 2 Stellen bezog sich auf die ältere Version auf Basis der AskSin. Der neue Branch mit NewAskSin ist relativ neu. Ob hier alles schon funktioniert weiß ich nicht mehr. Ich habe einen Sensor damit zum Laufen gekriegt, aber habe den dann umgeflasht. Weiß nicht mehr was nicht ging, vielleicht lag es an meinen Änderungen.
Du willst scheinbar was anderes als den Temperatursensor da du die Model ID geändert hast. Schau dir mal alternativ den AskSin++ Zweig von Papa an. https://forum.fhem.de/index.php/topic,57486.0.html (https://forum.fhem.de/index.php/topic,57486.0.html) vielleicht tust du dich damit leichter.
Klappt leider genauso wenig.
Ich habe die device id nur geändert, weil Homegear ebenso wie bei FF FF, beanstandet, dass F1 01 nicht kompatibel sei.
Danke für den Hinweis mit AskSin++, das werde ich mir mal ansehen und hoffe dass ich damit besser zurecht komme.
ich kenne Homegear nicht wirklich. Wenn die ModelID nicht erkannt wird, kann es sein,, dass du die device.list.txt dort irgend wie bekannt machen musst?
Im Default von Homegear hast du nur eine kleine Auswahl an Homematic geräten. Im Verzeichnis "/etc/homegear/devices" brauchst du ein Device-File für den jeweiligen Sensor. Diese Datei sehe ich im Download nicht ... zumindest nicht mit Namen HM_WDS10_TH_O. Heizkörperthermostate sind vorhanden, darum kannst die auch anlegen.
Ich denke du musst hier erstmal im Homegear-Forum die Devicefiles suchen oder erstellen (lassen). Damit verlässt du aber das Fhem-Umfeld.
Hallo zusammen,
ich habe mir bei Dirk den Universalsensor geholt und ausschließlich einen Lichtsensor verbauen lassen. Durch die UV Folie erhalte ich auch recht brauchbare Werte. Allerdings tue ich mich noch ein wenig schwer damit, eine Entscheidung zu treffen, wann nun wirklich direkte Sonneneinstrahlung statt findet und wann es nur bedeckt ist.
Fakt ist (und das ist auch normal): Morgens ist der gelieferte Wert trotzt direkter Sonneneinstrahlung noch recht gering, wohingegen mittags dieser Wert selbst bei sehr bedecktem Wetter um einiges höher ist als morgens mit Sonne.
Derzeit nutze ich den Höhenwinkel des Sonnenstandes um mir einen Vergleichsparameter zu schaffen. Aber so ganz will das nicht funktionieren. Gerade am Morgen oder gegen Abend kommt es schonmal zu Fehlinterpretationen.
Hatte jmd. von euch ein ähnliches Problem? Wie erkennt ihr, ob es sonnig ist oder eben nicht?
Viele Grüße
Thomas
Moin Thomas
Ich habe das empirisch ermittelt. Nehme dazu noch die Aussentemperatur und den Sonnenstand. Fuer die Rollaeden habe ich dann einen Wert fuer runter und einen entsprechenden fuer rauf definiert.
Gruss Christoph
Hallo Thomas,
ich kann mich da nur anschließen.
Ich habe den Sensor auf der Südseite direkt an einem der Fenster das ich beschatten will und ihn dort so positioniert, dass er auch bis es relevant wird quasi im Schatten steht.
Meine Werte sind dann so eindeutig, dass es da um 5.000 LUX hin oder her nicht ankommt.
Grüße
Knut
Zitat von: KNUT345 am 13 Mai 2017, 10:38:04
Ich habe den Sensor auf der Südseite direkt an einem der Fenster das ich beschatten will und ihn dort so positioniert, dass er auch bis es relevant wird quasi im Schatten steht.
Andere Variante:
Innenraumsensor mit Photodiode an geeignetem Platz
im Raum. Wenn es im Sommer zu hell und zu warm im Raum wird, fährt das Rollo runter und die Lamellen schließen sich in mehreren Schritten (shade). Wenn es im Winter zu hell wird und es noch Wärme braucht, fährt es komplett hoch und heizt (siehe Plot). Läuft so im Dachstudio mit großer Fensterwand nach SW.
Gruß
G.
Zitat von: thobo am 11 Mai 2017, 11:14:47
Wie erkennt ihr, ob es sonnig ist oder eben nicht?
Am Output der PV-Anlage auf dem Dach.... Die Kurve sieht dann genauso aus wie Deine. Ich weiß, es ist die Edelvariante eines Sonnensensors.
Gruß
G.
Zitat von: Gernott am 13 Mai 2017, 11:39:49
Die Kurve sieht dann genauso aus wie Deine. Ich weiß, es ist die Edelvariante eines Sonnensensors.
;D ;D ;D
Und wie ist es, wenn Du beide "Sensoren" vergleichst, hast Du da eine (konstante) Übereinstimmung?
Gruß PeMue
Zitat von: PeMue am 13 Mai 2017, 16:08:43
Und wie ist es, wenn Du beide "Sensoren" vergleichst, hast Du da eine (konstante) Übereinstimmung?
Nein, weil beide Sensoren verschiedene Himmelsrichtungen betrachten. - Wie im Vorvorpost ausgeführt, halte ich es für Raumverschattungszwecke für genauer, die Helligkeit immer direkt im betroffenen Raum messen. Für einen Außensensor sehe ich bei mir (EFH) wenig Anwendungen, zumal z.B. Bewegungsmelder auch eine Helligkeitsinfo an ihrer Position liefern.
Gruß
G.
Habe die ersten Seiten mal etwas überflogen. Gibts diesen Sensor noch irgendwo fertig zu kaufen oder einen Bausatz?
Moin,
mein Sensor ist heute ausgestiegen, ich nehme mal an, weil die Batterien alle sind. Die letzte Meldung war aber:
Universalsensor_Balkon:batVoltage 2.30 2017-05-30 13:25:49
Universalsensor_Balkon:battery ok 2017-05-30 13:25:49
Firmware ist die 0.14 laut Readings.
Hat das jemand mal getestet wie weit die Batteriespannung sinken darf bis das Teil aussteigt?
/Daniel
Die Batterien sind übrigens komplett leer, also die 2,3V können nicht stimmen.
/Daniel
Hi Dirk,
ich habe am Wochenende etwas mit der NewAskSin-Version getestet. Mir ist aufgefallen, dass Batterie-Status immer Low war obwohl die Spannung über Schwellwert war.
Du hast (vermutlich versehentlich) Variable shadowing gemacht.
Superclass BAT (\libraries\NewAskSin\as_battery.h) hat in Zeile 19 Member "uint8_t measure_value;"
Selbe Member var. hast du in deiner Ableitung BATTERY (.\as_battery.h) in Zeile 22 redefiniert "uint8_t measure_value;".
In Methode BATTERY->do_measure() weist du dann einen Wert dem Member BATTERY->measure_value zu. Später prüft Methode BAT->get_status den Wert von BAT->measure_value der aber immer 0 ist (da ja das Attribut der Ableitung aber nicht der Superklasse gesetzt wurde).
Wenn das Member in der redefinierten Klasse entfernt wird, wird immer die Variable der Superklasse gesetzt und gelesen. Habe es bei mir so gelöst.
Solltest du irgendwann eine neue Version einchecken, könntest du das ggf. mit abändern.
Hoffe dass es verständlich war.
Zitat von: b4rRa am 30 Mai 2017, 16:23:31
Habe die ersten Seiten mal etwas überflogen. Gibts diesen Sensor noch irgendwo fertig zu kaufen oder einen Bausatz?
Würde mich auch interessieren...
Gesendet von meinem SM-G935F mit Tapatalk
Zitat von: Pfriemler am 02 November 2016, 16:36:44
Feuchte und Temperatur kommen vom SHT. Der BMP180 ist nur noch für den Luftdruck zuständig.
Wie ist Deine Erfahrung in Bezug auf die Kalibrierung ? Der SHT misst bei mir ca. 0,6 Grad mehr als der BMP180. Da ich das als CCU-Nutzer nicht korrigieren kann nervt das total.
Wer kann mir einen Tip geben, wo ich eine Korrektur(möglichkeit) unterbringen könnte? Ich habe mir die FW-Quellen angesehen und muss leider feststellen, dass ich ohne Hilfe hier nicht weiterkomme. Meine Arduino-"Programmierkenntnise" reichen dafür leider nicht aus. Ich könnte damit leben, dass ich mir für jeden Sensor eine eigne FW bastele, die die jeweilige Abweichung kompensiert. Ideal wäre es natürlich, wenn man wie in Bezug auf die Luftdruckkorrektur wie beim HB-UW-Sen-THPL bzw. in Bezug auf die Temperaturkorrektur beim HmIP-STHD, das in der UI der CCU einstellen könnte.
Zitat von: cactus-online am 10 Juli 2017, 12:26:15
Wie ist Deine Erfahrung in Bezug auf die Kalibrierung ? Der SHT misst bei mir ca. 0,6 Grad mehr als der BMP180. Da ich das als CCU-Nutzer nicht korrigieren kann nervt das total.
Und welcher Sensor ist korrekt, hast du einen Vergleich? Meine Erfahrung mit ähnlichen Sensoren ist, dass Bosch BME280 fast 1 Grad zu hoch liefert und meine SHT33 sehr genau.
Auf deine andere Frage zurück zu kommen ... welchen Sourcecode verwendest du, die 0.* basierend auf alter Asksin, oder Version 1.0 die auf NewAsksin läuft?
bei der alten würde ich es hier irgendwo einbauen ...
Sensor_SHT10_BMP085_TSL2561.cpp
void SHT10_BMP085_TSL2561::poll_measureTHP(void) {
// Disable I2C
TWCR = 0;
uint16_t rawData;
uint8_t shtError = sht10->measTemp(&rawData);
// Measure temperature and humidity from Sensor only if no error
if (!shtError) {
float temp = sht10->calcTemp(rawData);
tTemp = temp * 10;
sht10->measHumi(&rawData);
tHum = sht10->calcHumi(rawData, temp);
// Serial << F("raw: ") << rawData << F(" mH: ") << tHum << (F("\n");
}
if (bm180 != NULL) { // only if we have a valid module
bm180->begin(BMP085_ULTRAHIGHRES); // BMP085_ULTRALOWPOWER, BMP085_STANDARD, BMP085_HIGHRES, BMP085_ULTRAHIGHRES
// simple barometric formula
tPres = (uint16_t)((bm180->readPressure() / 10) + (tAltitude / 0.85));
//Serial << F("tPres: ") << tPres << F("\n");
if (tPres > 300) {
// get temperature from bmp180 if sht10 no present
if (shtError) {
// temp from BMP180
tTemp = bm180->readTemperature() * 10;
}
} else {
tPres = 0;
}
}
In NewAsksin sind in cmSensor.cpp ähnliche Stellen an denen eine Variable wie tTemp gefüllt wird.
Wenn dein BMP180 die Temperatur korrekt misst, kannst auch den Sourcecode dahingehend ändern und diesen Wert setzen lassen. Sourcecode ist gut lesbar. Entsprechende Klassen habe ich dir genannt.
OK, vielen Dank ! ich schaue mal, ob ich damit etwas anfangen kann.
Referenz für die Messung sind verschiedene HM_WDS10_TH_O, die alle verschieden messen, sowie ältere (abzulösende) Temperatursensoren, sowie ein etwa 5 m entfernter Kombisensor HM-WDS-OC3 (der zu den "amtlichen Meßwerten" in der Regel dichter dran ist, als die HM_WDS10_TH_O) Sensoren.
Zitat von: b4rRa am 30 Mai 2017, 16:23:31
Habe die ersten Seiten mal etwas überflogen. Gibts diesen Sensor noch irgendwo fertig zu kaufen oder einen Bausatz?
Mich würde es ebenso interessieren...
grtz
Cmda
Hallo,
Zitat von: kadettilac89 am 20 Juli 2017, 12:22:27
Auf deine andere Frage zurück zu kommen ... welchen Sourcecode verwendest du, die 0.* basierend auf alter Asksin, oder Version 1.0 die auf NewAsksin läuft?
wo finde ich denn die v1.0 mit der NewAsksin? Bei papa auf github? Ansonsten finde ich hier https://github.com/kc-GitHub/Wettersensor nur bis v0.15.
Danke + Gruß
PeMue
Zitat von: PeMue am 22 Juli 2017, 05:12:13
Hallo,
wo finde ich denn die v1.0 mit der NewAsksin? Bei papa auf github? Ansonsten finde ich hier https://github.com/kc-GitHub/Wettersensor nur bis v0.15.
Danke + Gruß
PeMue
Schalte auf Branch "Firmware_newAsksin" um. Du suchts im "master" branch
Hallo,
Zitat von: kadettilac89 am 22 Juli 2017, 08:35:10
Schalte auf Branch "Firmware_newAsksin" um. Du suchts im "master" branch
das ist dann das hier:
https://github.com/kc-GitHub/Wettersensor/tree/Firmware_newAsksin ?
Gibt es das auch in compiliert, oder muss ich das selber machen? Ich gestehe, ich stehe etwas auf Kreigsfuß mit der Arduino IDE ;D ;D ;D
Gruß PeMue
Zitat von: PeMue am 22 Juli 2017, 16:34:08
Hallo,
das ist dann das hier:
https://github.com/kc-GitHub/Wettersensor/tree/Firmware_newAsksin ?
Gibt es das auch in compiliert, oder muss ich das selber machen? Ich gestehe, ich stehe etwas auf Kreigsfuß mit der Arduino IDE ;D ;D ;D
Gruß PeMue
Ich denke die Version ist noch nicht voll einsatzbereit. Zumindest habe ich den Eindruck dass der Batterieverbrauch höher ist. Ich habe es als Basis für meine Sensoren verwendet, habe aber andere Temp-Sensoren verbaut und dadurch auch etliches angepasst. Damit helfen dir meine Hex-Files nicht, sonst hätte ich sie dir gegeben.
Wenn du den Sensor wie im Schema im Einsatz hast, wird es besser sein die 0.15 zu verwenden da die V1.0 keine Neurungen hat, nur die neue Asksin. Ansonsten .... https://forum.fhem.de/index.php/topic,20620.msg645146.html#msg645146 ... das hat mich etwas Zeit gekostet.
Mal 'ne Frage: Ließe sich mit dem Universalsensor auch ein Feinstaubsensor SDS011 in Homematic integrieren? Hat jemand schon mal so etwas versucht?
Gruß
G.
Zitat von: Gernott am 27 Juli 2017, 22:03:24
Mal 'ne Frage: Ließe sich mit dem Universalsensor auch ein Feinstaubsensor SDS011 in Homematic integrieren? Hat jemand schon mal so etwas versucht?
Aktuell so nicht vorgesehen. Habe zumindest noch nichts darüber gelesen dass es in Homematic ginge.
Option 1: Wenn du einen der bestehenden Kanäle, z. B. Helligkeit nicht benötigst diesen missbrauchen und die Werte darüber schicken. Ist ne Quck'n'Dirty Lösung aber funktioniert
Option 2: Zusätzliche Cannel für Feinstaub einbauen
Option 3: ... es gibt Bastelprojekte für Feinstaub ... Aufwand ist hier wahrscheinlich geringer auch wenn du dafür noch zusätzliche Hardware brauchst ... https://forum.fhem.de/index.php/topic,66674.0.html
Bei 1) + 2) musst du erstmal selber an der Firmware Hand anlegen
Der Sensor für Feinstaub braucht 5V wenn ich mich nicht irre, d. h. du brauchst einen zusätzlichen Level-shifter ... Batterieverbrauch hier wahrscheinlich das Kriterium das du als erstes prüfen solltest.
Zitat von: kadettilac89 am 28 Juli 2017, 09:34:39
Option 1: Wenn du einen der bestehenden Kanäle, z. B. Helligkeit nicht benötigst diesen missbrauchen und die Werte darüber schicken. Ist ne Quck'n'Dirty Lösung aber funktioniert
Option 2: Zusätzliche Cannel für Feinstaub einbauen
Option 3: ... es gibt Bastelprojekte für Feinstaub ... Aufwand ist hier wahrscheinlich geringer auch wenn du dafür noch zusätzliche Hardware brauchst ... https://forum.fhem.de/index.php/topic,66674.0.html
Bei 1) + 2) musst du erstmal selber an der Firmware Hand anlegen
Der Sensor für Feinstaub braucht 5V wenn ich mich nicht irre, d. h. du brauchst einen zusätzlichen Level-shifter ... Batterieverbrauch hier wahrscheinlich das Kriterium das du als erstes prüfen solltest.
Die WLAN-Variante mit einem Wemos läuft hier schon, ich will aber Nachts wie gehabt mein WLAN runterfahren, ohne auf Messwerte zu verzichten. Batteriebetrieb ist mit dem Sensor sowieso nicht drin, der zieht relativ viel Strom beim Messen (u.a. wegen des Lüfters). Werde mich mal mit der Option 1 beschäftigen. Man braucht zwei Kanäle, da der Sensor zwei Werte ausgibt. Vielleicht steige ich irgendwie durch.
Zitat von: Gernott am 31 Juli 2017, 17:56:50
Die WLAN-Variante mit einem Wemos läuft hier schon, ich will aber Nachts wie gehabt mein WLAN runterfahren, ohne auf Messwerte zu verzichten. Batteriebetrieb ist mit dem Sensor sowieso nicht drin, der zieht relativ viel Strom beim Messen (u.a. wegen des Lüfters). Werde mich mal mit der Option 1 beschäftigen. Man braucht zwei Kanäle, da der Sensor zwei Werte ausgibt. Vielleicht steige ich irgendwie durch.
in der neuen Version ist Luminosity uint32. Da kannst leicht die beiden Werte für PM2.5 und PM10 unterbringen.
Hi,
ich habe mal eine Frage zu dem Wettersensor. Ich habe von einem User dankenswerterweise ein paar Wetterplatinen bekommen und würde die gerne bestücken und dann auch selbst löten. Ich hab dazu mal ein paar Fragen:
- kann ich statt des Atmega Chips zwischen den beiden 12 Pin Headers jetzt ein Arduino Pro Mini packen? Dann spar ich mir den Chip und alles, was zwischen den beiden 12 Pin Headers sind, oder? (sorry, wenn das eine dumme Frage ist, aber ich hab mir sowas grad erst angefangen)
- Ansonsten, ich hab mir das Eagle File von Github gezogen und per BOM.upl die Stückliste anzeigen lassen. Brauche ich alle Teile davon? Auf dem Bild im Wiki scheinen ein paar Sachen zu fehlen.
Der Sensor soll mit einem BMP180 und TSL2561 bestückt werden.
Vielen Dank schonmal im voraus
Zitat von: Kai-Alfonso am 09 August 2017, 12:48:14
...
Brauche ich alle Teile davon? Auf dem Bild im Wiki scheinen ein paar Sachen zu fehlen.
...
Einige Bauteile werden wohl nur benötigt, wenn die entsprechenden Sensoren bestückt sind. So scheinen C3 und C4 zum ebenfalls nicht bestückten BMP180 zu gehören (Auf dem Bild im Wiki, Außensensor)
Was mich aber interessieren würde: was ist das für eine Gehäuseform beim L1? Bei den Abmessungen scheint es ähnlich wie 1206 zu sein, aber eben nur ähnlich. Hat vielleicht jemand einen Link zur Bezugsquelle, idealerweise Aliexpress?
Danke im Voraus!
Sorry, aber ich möchte jetzt nicht unbedingt die vorangehenden 157 Seiten durchsuchen:
kann man das Modul/ Platine/ fertigen Baustein noch irgendwo erwerben?
Hallo Dirk,
ich habe Interesse an einem Innensensor.
Kannst Du mir bitte eine PM schicken?
Besten Dank.
Friedhelm
Hallo zusammen!
Einer meiner Innensensoren meldet Temperaturen um die 125 °C und ich bin mir sicher, dass derartige Temperaturen nicht in meiner Wohnung herrschen. ;D
Kann sich jemand das Verhalten erklären und hat eine Lösung dafür?
Zitat von: Spezialtrick am 26 September 2017, 12:15:00
Hallo zusammen!
Einer meiner Innensensoren meldet Temperaturen um die 125 °C und ich bin mir sicher, dass derartige Temperaturen nicht in meiner Wohnung herrschen. ;D
Kann sich jemand das Verhalten erklären und hat eine Lösung dafür?
Welchen Sensor hast du, manche Sensoren melden einen extremen Wert wenn nicht initialisiert werden konnte, oder der Sensor an sich defekt ist. Wenn es immer der selbe Wert ist könnte ich mir das vorstellen. Selbes Problem wenn du mal Batterie rausnimmst? Liegt die benötigte Spannung am Sensor an? Ggf. kalte Lötstelle oder defekter Spannungswandler ...
Zitat von: kadettilac89 am 26 September 2017, 14:34:29
Welchen Sensor hast du, manche Sensoren melden einen extremen Wert wenn nicht initialisiert werden konnte, oder der Sensor an sich defekt ist. Wenn es immer der selbe Wert ist könnte ich mir das vorstellen. Selbes Problem wenn du mal Batterie rausnimmst? Liegt die benötigte Spannung am Sensor an? Ggf. kalte Lötstelle oder defekter Spannungswandler ...
Es handelt sich um einen SHT10. Es wird nun immer 124,1 °C angezeigt.
Batteriewechsel hat nichts gebraucht und das erneute Aufspielen der Firmware auch nicht. Der Sensor lief sicher über ein Jahr ohne Probleme und zeig nun seit paar Tagen die falschen Temperaturen an.
Zitat von: Spezialtrick am 26 September 2017, 15:43:50
Es handelt sich um einen SHT10. Es wird nun immer 124,1 °C angezeigt.
Batteriewechsel hat nichts gebraucht und das erneute Aufspielen der Firmware auch nicht. Der Sensor lief sicher über ein Jahr ohne Probleme und zeig nun seit paar Tagen die falschen Temperaturen an.
Schwer zu sagen, ich tippe auf Sensor oder Lötstellle. Hast du ein Multimeter? Leiterbahnen lt. Schaltplan durchmessen. Auch im Betrieb wie viel Spannung anliegt.
Welchen Sensor hast du, Platine Außensensor oder selber verdrahtet? Hast du die Möglichkeit, den Sensor an einen Arduino oder Raspberry direkt anzuschließen und mit der Library direkt zu testen, ohne Wettersensor-Hardware.
Zitat von: kadettilac89 am 26 September 2017, 22:52:30
Schwer zu sagen, ich tippe auf Sensor oder Lötstellle. Hast du ein Multimeter? Leiterbahnen lt. Schaltplan durchmessen. Auch im Betrieb wie viel Spannung anliegt.
Welchen Sensor hast du, Platine Außensensor oder selber verdrahtet? Hast du die Möglichkeit, den Sensor an einen Arduino oder Raspberry direkt anzuschließen und mit der Library direkt zu testen, ohne Wettersensor-Hardware.
Ich habe einen Innensensor von Dirk und grad mal alles durchgemessen. Am SHT10 und auch am Atmega liegen nur 2,44 V an. Es sollte ja 3,3 V sein. Offenbar ist der StepUp defekt. Wenn ich den gesamten StepUp Teil überbrücke, sendet der Sensor wieder normale Werte.Ich versuche mal den StepUp zu ersetzen. 8)
Es war der StepUp. Der Sensor läuft wieder astrein. :)
Hallo zusammen,
ich habe hier mittlerweile beinahe alle Bauteile für einen Außensensor zusammen. Ich würde gerne den Atmega vor dem Löten flashen, im Wiki steht auch was von einem OTA-Bootloader, ohne jedoch genauer drauf einzugehen, wie man ihn drauf kriegt. Ich kenne den OTA-Bootloader von papa von dem Fensterdrehgriffkontakt und Relais-Board, ist es etwa der gleiche? Wird damit auch die 0.15-Firmware unterstützt?
Danke im Voraus!
Im Prinzip ist das ser selbe Bootloader. Du kannst Dir hiermit einen passenden erzeugen.
https://github.com/pa-pa/AskSinPP/blob/master/bootloader/avr/makeota.html
Bitte den richtigen Modeltyp F102 setzen.
Hi papa,
danke für die Info!
Weißt Du oder jemand anders, ob "HB-UW-Sen-THPL_update_V0_15_000_150303.eq3" aus https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release (https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release) damit out-of-the-box funktioniert? D.h. ob sie die im Bootloader hinterlegte HMId und Seriennummer nutzt?
Sollte gehen, da ich die gleichen Adressen im Bootloader verwende. Habe das aber noch nicht selbst probiert.
Hey zusammen,
Ich habe auch mal angefangen mir eine kleine Wetterstation mit Batterie und Solarmodul zu bauen.
Ein BMP280 misst aktuell die Temperatur und den Luftdruck - Ein TSL2561 die Helligkeit. Auf den Sensor für die Luftfeuchtigkeit warte ich zur Zeit noch.
Das Pairing und der Empfang in FHEM klappen einwandfrei. Ich habe es auch soweit hin bekommen, die Messages mit den obigen Werten zu füttern. Allerdings versteht FHEM die letzten 4 Blöcke (Für die Helligkeit in Lux) leider nicht.
Temp: 20.26 | Humidity: 50 | Lux: 95 | Airpressure: 100388
<- 12 00 A0 70 34 56 78 00 00 00 00 CA 32 27 36 00 00 00 5F
00 CA: 20.2°C
32: 50% Luftfeuchtigkeit (noch ein Dummy)
27 36: 10038 DekaPascal
00 00 00 5F: 95 Lux
In FHEM kommt allerdings nur das an:
HM_345678 - T: 20.2 H: 50 AP: 10038
Der CUL empfängt allerdings die gesamte Message...
Wie kann ich FHEM denn nun mitteilen, dass da hinten noch die Helligkeit dran hängt? :)
LG
Zitat von: Benny am 12 Oktober 2017, 15:23:33
Der CUL empfängt allerdings die gesamte Message...
Wie kann ich FHEM denn nun mitteilen, dass da hinten noch die Helligkeit dran hängt? :)
LG
Welches Modul hast du in Fhem, das angepasste von Github?
Teste das mal ....
https://github.com/kc-GitHub/Wettersensor/blob/master/Contrib/FHEM/HMConfig_SenTHPL.pm (https://github.com/kc-GitHub/Wettersensor/blob/master/Contrib/FHEM/HMConfig_SenTHPL.pm)
Edit: ... lösche oder rename das bestehende Modul HMConfig_SenTHP.pm um damit wirklich das neu reinkopierte verwendet wird. Restart von FHEM durchführen und erneut testen ....
Ich hatte noch das Standard Modul der HMConfig von FHEM genutzt.
Habe gerade mal das von GitHub getestet, scheint aber leider trotzdem nicht zu funktionieren...
Der Sensor in FHEM liefert mir folgendes:
Zitat
2017-10-12_16:04:54 HM_345678 airpress: 10039
2017-10-12_16:04:54 HM_345678 battery: ok
2017-10-12_16:04:54 HM_345678 humidity: 50
2017-10-12_16:04:54 HM_345678 T: 20.4 H: 50 AP: 10039
2017-10-12_16:04:54 HM_345678 temperature: 20.4
Der CUL in FHEM empfängt aber folgende Nachricht:
Zitat2017.10.12 16:00:50 4: CUL_Parse: nanoCUL868 A 12 00 A070 345678 000000 00CC3227380000005B08 -70
2017.10.12 16:00:50 5: nanoCUL868: dispatch A1200A07034567800000000CC3227380000005B::-70:nanoCUL868
2017.10.12 16:00:55 5: CUL/RAW: /A1200A07034567800000000CC3227380
2017.10.12 16:00:55 5: CUL/RAW: A1200A07034567800000000CC3227380/000005B08
Der Sensor sendet auch die obige Nachricht:
ZitatTemp: 20.45 | Humidity: 50 | Lux: 91 | Airpressure: 100390
<- 12 00 A0 70 34 56 78 00 00 00 00 CC 32 27 38 00 00 00 5B
welche Version der Firmware hast du auf dem Sensor?
Die AskSin++ und dann selbst angepasst, da ich ja andere Sensoren nutze.
Ist nur die Frage ob ich an dem Code selbst was nicht stimmt, oder in FHEM noch was angepasst werden muss - Der Sensor funkt ja im Prinzip nur Hexadezimal Ketten. Die Interpretation findet doch nur in FHEM statt oder?
Ich habe auch Asksin++ als Basis verwendet. Ein paar kleine Sachen sind noch nicht so sauber. Würde jetzt nicht unterschreiben, dass alles passt. Wenn du Programmierkenntnisse hast dann flashe mal die alte Firmware und setzte Dummy-Werte, dann siehst du erstmal ob FHEM selbst alles benötigte hat. Sollte nicht zu viel Aufwand sein.
Auch wenn Werte ankommen kann es sein, dass eine Stelle zu viel, zu wenig, falsch geshiftet ... ankommt.
Zitat von: Benny am 12 Oktober 2017, 16:35:09
Die AskSin++ und dann selbst angepasst, da ich ja andere Sensoren nutze.
Ist nur die Frage ob ich an dem Code selbst was nicht stimmt, oder in FHEM noch was angepasst werden muss - Der Sensor funkt ja im Prinzip nur Hexadezimal Ketten. Die Interpretation findet doch nur in FHEM statt oder?
Hast Du den richtigen Modeltyp gesetzt ?
Mach mal nen List vom Device.
Zitat von: papa am 12 Oktober 2017, 16:55:25
Hast Du den richtigen Modeltyp gesetzt ?
Mach mal nen List vom Device.
Wird erkannt als:
Zitat
model: HM-WDS10-TH-O
Das ist falsch. Es müsste HB-UW-Sen-THPL-O sein. Hast Du DEVICE_MODEL auf 0xf1,0x02 ?
Zitat von: papa am 12 Oktober 2017, 17:46:15
Das ist falsch. Es müsste HB-UW-Sen-THPL-O sein. Hast Du DEVICE_MODEL auf 0xf1,0x02 ?
Okay das war einfacher als gedacht... Model geändert, neu gepairt und jetzt klappt es - Vielen lieben Dank! :)
Hallo zusammen,
ich habe mir gestern endlich einen HB-UW-Sen-THPL-O zusammengelötet. Bis auf Angabe der Batteriespannung scheint auch erstmal alles zu funktionieren, aber die Spannungswerte machen mir doch Sorgen, zwischen
batVoltage: 3.00 und
batVoltage: 6.40
ist alles dabei, mit der Häufung bei 5 V.
Auf dem Board messe ich mit dem Multimeter direkt am Step-Up und bei den beiden Sensoren etwa 3.3 V, die tatsächliche Batteriespannung betragt etwa 2.4 V. Woher kommen also diese Werte?
Und was mich noch interessieren würde: wo ist eingestellt, wie häufig der Sensor die Werte überträgt? Im Moment meldet er sich alle 2 bis 6 Minuten, es sind keine "event-*"-Attribute konfiguriert.
Der Sensor sendet die Werte im Abstand von 2-3 Minuten. Der Abstand wird bei jeder Message neu berechnet, verändert sich also ständig und läßt sich nicht einstellen (außer man ändert die Firmware des Sensors).
Viele Grüße,
Martin
Hi Martin,
Danke für die Info!
Ne Idee bzgl. der komischen Spannungswerte hast Du aber auch nicht?
Nein, keine direkte Idee...
Batteriespannung und generierte Spannung hören sich erst mal gut an.
Die Spannungsteilerwiderstände (R3/R4) sind richtig platziert und gut verlötet?
Martin
Das war wohl ein Treffer. Habe die Widerstände R2-R5 noch mal nachgemessen und Lötkolben drangehalten, nun bekomme ich auch 4 Mal hintereinander 2.4 V angezeigt. Aber eigentlich sind doch nur R2 und R3 relevant für die Spannungsmessung und nicht R3/R4, wie Du geschrieben hast?
Wie auch immer, vielen Dank für Deine Hilfe!
Hat irgendjemand mal versucht einen Impulszähler aus der Universalsensor-Platine zu machen?
@Dirk: Verkaufst Du noch Platinen (bevorzugt bestückt)?
Mein Ziel:
Der Wasserzähler hat schon einen funktionierenden Impulsausgang und ich würde diesen gerne in FHEM erschliessbar machen, aber das ganze MBUS-Zeugs ist mir zu teuer also doch selber etwas bauen.
tndx, prima, daß es nun funktioniert.
R2/R3 oder R3/R4 - je nachdem, ob man die Außen- oder Innenvariante betrachtet - wir meinten beide das gleiche ;-)
Hallo,
ich bin auf der suche nach einer bezahlbaren Bezugsquelle für das Innengehäuse. Hat jemand einen Tip?
Gruß Rolf
Hallo Rolf,
Zitat von: rvideobaer am 19 November 2017, 20:57:50
ich bin auf der suche nach einer bezahlbaren Bezugsquelle für das Innengehäuse. Hat jemand einen Tip?
das http://www.tme.eu/de/details/box-sens-white/gehaeuse-fuer-alarmanlagen-und-sensoren/supertronic/ ist Dirks Originalgehäuse.
Ob die Platine da https://www.ebay.de/itm/2x-NEW-Plastic-Project-Box-Electronic-Junction-Case-DIY-27x54x75mm-construction-/150866356642?hash=item232055e9a2:m:mdi9gTNIphXh20kZhHiER0g reinpasst, weiß ich nicht. Das Gehäuse sieht aber auch nicht schlecht aus und ist "bezahlbarer" ;)
Gruß Peter
Zitat von: PeMue am 19 November 2017, 21:53:38
Ob die Platine da https://www.ebay.de/itm/2x-NEW-Plastic-Project-Box-Electronic-Junction-Case-DIY-27x54x75mm-construction-/150866356642?hash=item232055e9a2:m:mdi9gTNIphXh20kZhHiER0g reinpasst, weiß ich nicht. Das Gehäuse sieht aber auch nicht schlecht aus und ist "bezahlbarer" ;)
Ich kenne das Gehäuse, die Platine dürfte da nicht reinpassen (zu schmal). TME-Gehäuse wirkt auch deutlich hochwertiger.
Zitat von: hexenmeister am 20 November 2017, 19:40:21
Ich kenne das Gehäuse, die Platine dürfte da nicht reinpassen (zu schmal). TME-Gehäuse wirkt auch deutlich hochwertiger.
rvideobaer verwendet nicht die originale Platine, sondern das I2C-Sensor Addon zur HM-Universal-Hardware (https://forum.fhem.de/index.php/topic,73954.msg656384.html#msg656384). Ich vermute mit der 2-AAA-Basis. Das sollte mit 48mm x 51mm gerade so rein gehen.
Hallo,
Danke für die Tips, das ebay Gehäuse gefällt mir ehrlich gesagt nicht. Ich werde jetzt das andere besorgen.
Gruß Rolf
Hallo zusammen,
habe mir nun auch einen Innensensor zusammengelötet und alle 3 Sensoren bestückt. Funktioniert soweit unauffällig, meldet sich aber FHEM gegenüber als "HB-UW-Sen-THPL-O". Lt. Wiki soll es aber auch einen "HB-UW-Sen-THPL-I" geben, woran erkennt die Firmware, dass sie auf einem "I" läuft? Kennung im Bootloader? Wenn ja, wie lautet die richtige für den Innensensor? Gibt es sonst irgendwelche Unterschiede bei den beiden Versionen, außer der Kennungen?
Hallo,
der unterschied ist nur in der Device-ID im Bootloader, im Gerät selbst gibt es sonst keinen Unterschied.
Gruß Rolf
Hi,
wie ist denn die Device-ID für den Innensensor? Für den Außensensor wurde mir "F102" genannt.
Hallo
F101
Rolf
Vielen Dank!
folgende Frage zu meinem HB-UW-Sen-THPL-I, es ist jetzt das 2. mal innerhalb von ca. 2 Wochen passiert das der Sensor aussteigt. Seit ich diesen Sensor nutze funktionierte er problemlos.
Vor ca. 2 Wochen habe ich dann mal die Batterien erneuert nun zeigt er aber wieder "Activity dead" eine Batteriemeldung habe ich nicht bekommen und auch keine Fehlermeldung, ich sehe es nur an der Temperatur die nicht stimmen kann, wenn ich auf das Datum schaue ist es der 09.12.2017 als er wohl ausgestiegen ist.
Kann ich den eigentlich so wieder zum leben erwecken, ich meine das es irgendwie ging.
Wollte das jetzt mal so testen ansonsten nehme ich nochmal die Batterien heraus.
Internals:
CFGFN ./FHEM/Temperaturen.cfg
DEF 2FA573
IODev HMUSB
NAME Temperatur_Terrasse
NOTIFYDEV global
NR 3261
STATE set_reset
TYPE CUL_HM
protCmdPend 7 CMDs_pending
protState CMDs_pending
READINGS:
2017-12-09 15:14:25 Activity dead
2017-11-26 14:26:28 D-firmware 0.14
2017-11-26 14:26:28 D-serialNr UWS4019322
2017-12-03 23:26:39 batVoltage 3.30
2017-12-03 23:26:39 battery ok
2017-12-03 23:26:39 humidity 99
2017-12-03 23:26:39 luminosity 0
2017-12-03 23:23:49 pressure 1017.1
2017-12-03 23:23:49 pressure-nn 1044.7
2017-12-03 23:26:39 rssi_at_HMUSB -77
2017-12-10 15:43:04 state set_reset
2017-12-03 23:26:39 temperature 4.2
cmdStack:
++A0011EA1212FA573010E
++A0111EA1212FA5730400
++A0011EA1212FA57300040000000000
++A0011EA1212FA5730103
++A0041EA1212FA5730100
++A0041EA1212FA5730101
++A0111EA1212FA5730400
helper:
HM_CMDNR 146
cfgChkResult No regs found for:Temperatur_Terrasse-ret--ret-
getCfgListNo
mId F101
rxType 156
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +2FA573,02,00,00
prefIO
rxt 2
vccu
p:
2FA573
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 2
q:
qReqConf
qReqStat 00
role:
chn 1
dev 1
tmpl:
nb:
cnt 2
Attributes:
IODev HMUSB
actCycle 000:10
actStatus dead
alias Terrasse Süden
autoReadReg 4_reqStatus
expert 2_full
firmware 0.14
group Temperatur Alle
model HB-UW-Sen-THPL-I
room Temperaturen
rssiLog 1
serialNr UWS4019322
sortby 11
subType THPLSensor
verbose 0
Hallo Dirk,
verkaufst Du noch Sensoren ? Ich hätte Interesse.
Viele Grüße
R.
Ich hätte noch einen Innen und ein Außensensor vom Dirk abzugeben wegen Systemumstellung. Wenn jemand Interesse hat kann er sich gerne per PM melden.
Hallo Zusammen,
gibt es noch eine Möglichkeit einen Sensor zu bestellen?
Gruß
Alex
Hallo zusammen,
hat schon jemand mit dem HM-MOD-RPI-PCB (https://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=52520) die Firmware des Universalsensors OTA geflasht? Bei mir hat das Ding irgendwie rumgezickt (unknown command oder so). Da ich noch einen CUL auf Homematic laufen habe, habe ich es damit gemacht. Da ging es problemlos.
Danke für Eure Rückmeldungen.
Gruß PeMue
Hallo,
ja habe ich schon gemacht funktioniert ohne Probleme und fast doppelt so schnell wie mit Cul.
Gruß Rolf
Hat jemand von Euch mit dem HM-MOD-RPI-PCB Empfangs-/Reichweitenprobleme mit Dirks Universalsensor?
Ich komme mit dem HM-MOD-RPI-PCB nur noch 1 1/2 Wandstärken (7 m Luftlinie) weit, dann ist kein Empfang mehr möglich (RSSI bei Empfang ca. -55 dBm).
War mir vorher, als ich noch den Busware-CUL hatte, nicht aufgefallen.
Außerdem reagiert der Universalsensor mittlerweile sehr merkwürdig, man kann ihn nicht mehr resetten (die LED zeigt einen langen Tastendruck nicht mehr an), ein getconfig mit Tastendruck wird überhaupt nicht mehr beantwortet...
Gruß,
Friedhelm
Zitat von: FFHEM am 29 Januar 2018, 20:41:56
Hat jemand von Euch mit dem HM-MOD-RPI-PCB Empfangs-/Reichweitenprobleme mit Dirks Universalsensor?
Das Modul ist an sich schon sehr taub. Ich betreibe es (wie sehr viele andere auch) mit einer externen Antenne.
Stabantennen haben sich als nicht sonderlich nützlich erwiesen.
Eine Flachantenne oder am besten eine Groundplane holt da sehr viel mehr raus!
Ich habe mir eine Flachantenne gebaut und komme damit übers gesamte 1000m²-Grundtstück.
Bauanleitung habe ich von hier: https://www.stall.biz/project/externe-flachantenne-fuer-die-homematic-und-vergleich-mit-anderen-loesungen (https://www.stall.biz/project/externe-flachantenne-fuer-die-homematic-und-vergleich-mit-anderen-loesungen)
LG, JP
Falls jemand den HB-UW-Sen-THPL per Funk am RaspberryMatic betreiben möchte - ich habe das Addon für CCURM portiert: https://github.com/jp112sdl/Wettersensor/tree/master/Contrib/CCURM (https://github.com/jp112sdl/Wettersensor/tree/master/Contrib/CCURM)
Hinweis:
Nach der Installation wird RaspberryMatic automatisch neu gestartet.
Nachdem das System wieder hochgefahren ist, ist anschließend noch ein weiterer Neustart erforderlich, bevor ein HB-UW-Sen-THPL angelernt werden kann.
Hallo,
hat jemand noch Platinen auf Lager die mir verkaufen möchte. Ich möchte mir ein Multi-Temperaturerfassungssystem für meine Heizung, WW Speicher und Außentemperatur aufbauen.
Danke aus Nürnberg
Joachim
Hallo Dirk,
ich habe Interesse an einem Innensensor.
Kannst Du mir bitte eine PM schicken?
Besten Dank.
Joachim
Moin,
sagt mal misst der Außen Sensor falsch oder warum stirbt der bei mir immer bei:
batVoltage 2.10 2018-02-25 00:24:04
battery ok 2018-02-25 00:24:04
Wenn der StepUp bis 1,2V arbeitet?
Firmware ist 0.14 laut Attribut Angabe.
/Daniel
Hat jemand schon mal das Modul mit Funk und 1-wire Sensoren aufgebaut? Über einen kurzen Hinweis mit Schaltplan würde ich mich freuen.
Gruss
Ich hab mir Temperatur- und Feuchtesensoren mit nem DS18B20 und DHT22 aufgebaut.
Basierend auf Dirks Sensor.
Siehe hier: https://github.com/LineF/HM-Sensor
Hallo Linef,
hast Du evtl. noch eine Platine übrig? Bestücken könnte ich selbst. Oder einen Kontakt wo ich mir die Platinen fertigen lassen könnte.
Danke
Hallo fj3847,
ja, ich hab noch welche übrig.
Meld Dich einfach per PM, dann können wir das Weitere ausmachen.
Gruss,
Martin
Zitat von: ext23 am 25 Februar 2018, 09:38:45
Moin,
sagt mal misst der Außen Sensor falsch oder warum stirbt der bei mir immer bei:
batVoltage 2.10 2018-02-25 00:24:04
battery ok 2018-02-25 00:24:04
Wenn der StepUp bis 1,2V arbeitet?
Firmware ist 0.14 laut Attribut Angabe.
/Daniel
Das Gleiche Problem habe ich auch, bei 2.1 Volt steigt er immer aus. Ich kann eigentlich die Uhr danach stellen: Ich ersetze jedes Jahr Mitte März/ Anfang April die Batterien, die Batteriespannung zeigt 2.1 Volt / Batteriestatus ok. Aber er sendet nicht mehr.
-> Batterien ersetzten und alles geht bis zum nächsten Jahr wieder....
Zitat von: Jens_B am 21 März 2018, 09:45:06
Das Gleiche Problem habe ich auch, bei 2.1 Volt steigt er immer aus. Ich kann eigentlich die Uhr danach stellen: Ich ersetze jedes Jahr Mitte März/ Anfang April die Batterien, die Batteriespannung zeigt 2.1 Volt / Batteriestatus ok. Aber er sendet nicht mehr.
-> Batterien ersetzten und alles geht bis zum nächsten Jahr wieder....
Was haltet ihr von dieser Theorie: Die Batteriemessung wird unbelastet sehr hochohmig mit 570k gemacht (Theorie, ich habe mir nicht den ganzen thread durchgelesen, nur mal in die Schaltung geschaut, wie die SW misst habe ich nicht reingeschaut.). Das gibt nicht den realen Batteriestatus wieder. Wenn dann einige 10mA beim Senden mit CC1101 fließen bricht eine schwache Batterie zusammen ohne das es vorher bei einer hochohmigen Messung zu bemerken ist.
jp112sdl beschreibt hier ein Problem wo ein HM Device bei ihm auf Dauersenden geht
https://forum.fhem.de/index.php/topic,57486.msg783197.html#msg783197 (https://forum.fhem.de/index.php/topic,57486.msg783197.html#msg783197)
Wir haben das etwas diskutiert, er glaubt das tritt vorzugsweise bei schwacher Batterie auf. Wäre m.E ein Fall der ähnlich ist, nur dass dort der CC1101 oder der AVR durch den Zusammenbruch auf Dauersendung geht. Durch die hochohmige Batteriemessung vorher nicht zu erkennen.
Der Step-up geht laut Datenblatt sogar bis 0,8V runter. Bei 2,1V die belastbar wären gäbe es keinen Grund auszusteigen.
Hallo zusammen,
wenn die Außensensoren eine Weile draußen hängen, sollte man ab und zu die Dichtung der Gehäuse wechseln. Ansonsten läuft der Sensor mehr oder weniger mit Wasser voll ???
Dichtungen dazu gibt es bei Reichelt (https://www.reichelt.de/?ARTICLE=193577&PROVID=2788&gclid=EAIaIQobChMIyouEkbiO2gIVjrztCh1wTwzaEAQYASABEgJ7VvD_BwE).
Gruß PeMue
Dort wo man sie tauschen kann macht es Sinn. Neuerdings sind die eingegossen. Aber ich hatte bis jetzt keine Probleme auch nach 5 Jahren. Die Feuchtigkeit kommt bei mir wenn dann durch die Steckverbinder rein. Und man sollte es bevorzugt im Winter schließen und nicht im Sommer, oder gel rein.
/Daniel
Zitat von: PeMue am 28 März 2018, 09:00:05
wenn die Außensensoren eine Weile draußen hängen, sollte man ab und zu die Dichtung der Gehäuse wechseln. Ansonsten läuft der Sensor mehr oder weniger mit Wasser voll
Danke für den Tipp mit den Dichtungen - aber mein Sensorgehäuse hat unten ein großes Loch (10 mm), das mit einem Fliegengitter verklebt ist. So ist das Gehäuse stets gut belüftet, es bildet sich nur noch wenig Kondenswasser, was aber immer von selbst im Laufe des Tages abtrocknet. Und vollaufen geht schon gar nicht.
Hauptzweck der Belüftung war aber die Versorgung der Sensoren mit hinreichend Umgebungsklima...
Guten Abend,
ich habe hier seit einiger Zeit 2 von den Innensensoren im Einsatz. Funktionieren soweit ganz OK, allerdings sendet einer der beiden keine Helligkeitswerte, sobald die Helligkeit 0 ist. Das ist mir erst gar nicht aufgefallen, da es selten absolut dunkel ist, dann hielt ich das für normal, bzw. habe mir nichts dabei gedacht, doch der 2. schickt immer den Helligkeitswert, auch wenn er 0 ist. Kann das vielleicht jemand auflösen? Ist das eine Einstellungssache, Hardwarefehler oder noch irgendwas anderes?
Erster Schnellschuss:
Hast Du evtl. ein event-on-change-reading gesetzt? Wenn sich keines der betroffenen Readings ändert, gibt's auch kein Event und alles bleibt beim alten...?
Nein, ist nicht gesetzt. Die Temperatur und die Feuchtigkeit ändern sich auch nicht und werden trotzdem jedes Mal gesendet. Wenn ich das Licht anmache, dann wird die Helligkeit auch gesendet, bis es wieder dunkel ist, dann 1-2 Mal 0, dann erstmal keine Helligkeit, dann nach etwa einer Stunde wieder vereinzelt eine 0, während der andere Sensor brav die ganze Zeit eine 0 sendet.
Habe heute den auffälligen Sensor ein wenig gequält: zurückgesetzt, sämtliche Bauteile nachgelötet, SW neu geflasht, in FHEM gelöscht und neu anlegen lassen: keine Änderung. Was kann die 2 Atmegas noch veranlassen, bei gleicher Schaltung / Bauteilen und SW sich unterschiedlich zu verhalten? Bauteiltoleranzen?
Habe ich denn theoretisch irgendwelche Nachteile durch diesen nicht gesendeten Helligkeitswert? Die Sensoren wollte ich unter anderem für die Rolladensteuerung einsetzen, bin da noch weit von entfernt. Falls ich aber doch irgendwann mal soweit sein sollte: kann dann der plötzlich nicht vorhandene Werte die Steuerung durcheinanderbringen?
Hallo,
dann setzt doch ein userReading da kannst du bewirken das wenn kein wert kommt null gesetzt wird.
Rolf
Ich mache auch mal ein neues Thema auf:
Seit vier Wochen macht mir der Außensensor mit Breakout-Sensor SHT10 Probleme: Die Feuchtigkeitswerte driften gelegentlich um bis zu 20% nach unten ab. Das war nach dem 4. März so, zwischenzeitlich hat sich das wieder gefangen, dann ging es wieder los. Siehe ersten und zweiten Screenshot. Geändert wurde nix, kein Restart, kein Batteriewechsel, Firmwareupdate etc.
Der SHT10 ist sauber, hängt luftig und frei in einem Wettersensorgehäuse (gestapelte Schirme).
Als Vergleich dient dabei ein KS300 - beide hängen 40 cm voneinander entfernt am gleichen Mast im Garten. Sonst sind die Sensoren ja ganz gut beisammen, wie man sieht.
Feuchtewerte sind die dünnen olivgrünen (KS300) und grauen (TH_O) Linien (die dicken roten und grünen sind die Temperatur)
Als Vergleichsnormal dient weiterhin ein YahooWeather, dessen Feuchtewert in unteren einstelligen Bereich vom KS300 abweicht - der dürfte also richtig liegen.
Irgendjemand ne Idee was da schief laufen könnte?
Im freien? Wie lange läuft der schon? Ich habe auch so ein Schirm, aber ohne speziellen Filter muss man die alle 2-3 Jahre tauschen. Ich habe ein SHT11 ohne Schutz. Ich hab überlegt mir mal ein Filter zu kaufen, gibts ja bei Ali aber mhh die kosten auch Geld und wenns nur alle 2-3 Jahre ist dann kann ich mit leben.
Vielleicht funktioniert bei deinem auch die Heizung nicht. Ich glaube die haben so ein Heizelement drin damit eventuelle Betauung verdampft.
Und hast du die Lötstellen mit Urethan 71 oder sowas behandelt, die gammeln sonst auch durch.
Aber wenn das nur sporadisch auftritt ist es komisch ja.
/Daniel
Der läuft dort seit ... drei Jahren, etwa, schätze ich mal. Filter habe ich natürlich keinen drauf, habe keinen Händler gefunden, der passende Stückzahlen zu akzetablen Preisen liefert - vielleicht sollte man mal eine Sammelbestellung organisieren...
Defekte Heizung ... hm ... dann hätte ich einen zu hohen Wert angenommen. Eine Heizung haben die Dinger aber wohl kaum wirklich. Zumindest finden sich keine Hinweise darauf im Manual.
Schutzlack? Eher eine Frage bei Totalausfall, denn gammlige Lötstellen dürften die digital übermittelten Werte des Sensors ja kaum beeinflussen...
Generell treffen sich die beiden Sensoren inzwischen nur nur bei ~60%, also wenn es wirklich mal so trocken wird.
Und dann sind da so die seltsamen Sprünge, wenn der Gesamtverlauf eher konstant ist, siehe dieses Bild. Beim 4. März beginnt die (erste dokumentierte) Abweichung hingegen mit einer Drift.
Wie auch immer: SHT1x kommen mal auf die Einkaufsliste.
Dass Feuchtesensoren im Laufe der Zeit schwach werden, kenne ich sonst nur von meinen WS2000-Sensoren - die zeigen auch gut 30% zu wenig, das aber nach 20 Jahren...
Hallo Experten der Sensorik,
ich habe mir mit Hilfe der AskSin++ Library einen Prototyp eines Universalsensors auf Lochrasterplatine gebaut,
https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/Images/Prototyp_HB-UNI-Sensor1.jpg (https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/Images/Prototyp_HB-UNI-Sensor1.jpg)
Den wollte ich jetzt provisorisch in eine gewöhnliche 100x100 Abzweigdose bauen
https://www.kabelscheune.de/Abzweigdosen-Kaesten/Abzweigdose-IP54-grau-Aufputz-100x100x40-mm.html (https://www.kabelscheune.de/Abzweigdosen-Kaesten/Abzweigdose-IP54-grau-Aufputz-100x100x40-mm.html)
und den ein paar Monate draußen zum Testen laufen lassen bevor ich eine richtige Platine mit kleinerem Gehäuse mache.
Worauf muss ich bei der Luftfeuchtemessung für außen achten?
Mein Plan war ein paar Löcher, z.B. 5mm, in die Unterseite, also regengeschützt, zu bohren und diese innen mit Fliegengitter verkleiden.
Reicht das für eine reale Luftfeuchtemessung oder wird sich innen eine Art Mikroklima bilden die von der Luftfeuchte außen abweicht?
Ausserdem lese ich im wiki von einer speziellen Filter für die Feuchte, "atmungsaktivem Nylon". Habt ihr dazu einen aktuellen link wie das aussieht und was das kostet?
Danke
Pfriemler: Doch steht im Datasheet, aber ist wohl nur für Testzwecke die Heizung. Tja und mit dem gammeligen Lötstellen, mag sein das es nicht stört, viele sagen auch man braucht keinen Kondensator dicht am Chip etc. Viele sagen aber auch ihr Sensor misst Misst ;-)
Meiner läuft "noch" ohne murren, aber eben ohne Filter. Mal schauen wie lange noch. Ich weiß nicht mal ob ich originale habe, aber bei einem Preis von 5 Euro pro Stück nehme ich mal an es sind Kopien. Ka was du bezahlt hast aber die original kosten ein vielfaches mehr.
/Daniel
@ext23: Hab's jetzt auch gesehen mit der Heizung.
Tja, Ersatz ...
SHT10,11,15 sind abgekündigt, es wird auf SHT3x verwiesen.
Ein SHT30-Breakout-Board kostet ungefähr die Hälfte eines SHT10.
Dann gibt es diverse Dinger wie AM2320, die mit "Ersatz für SHT10" werben.
Hat jemand ne Ahnung, wie kompatibel die sind oder ob ich die Firmware dafür modifizieren muss?
Ich glaube die AM2320 sind doch nur sone DHT22 Teile oder, also was das Messverfahren angeht. Also eigentlich ist es ein DHT22, nur das der AM2320 auch I2C kann. Der 1:1 DHT22 ist ja der AM2302.
Aber das die SHT1x abgekündigt sind habe gar nicht mitbekommen, aber gut zu wissen, danke.
/Daniel
Wenn es den SHT10 nicht mehr zu kaufen geben sollte (wobei ich davon ausgehe, dass man ihn privat noch lange Zeit bei Ali bekommen wird), könnte man ja dann auch auf den vom Hersteller empfohlenen SHT3x ausweichen.
Ggf die Lib wechseln und die Sensorklasse anpassen sind nicht schwer.
Den DHT22 mag ich gar nicht.
Den muss man 3x höflichst bitten, bis er seine Werte rausrückt.
Es hatte sich jemand bei mir gemeldet, weil der WDS10 Nachbau häufig 0/0-Werte sendet. Ich konnte es auf Anhieb nachstellen.
Habe nun die Dht Sensorklasse angepasst und einen Pullrequest eingestellt.
Bin da noch ein bisschen mit papa am verhandeln ;)
Gesendet von iPhone mit Tapatalk
Falls man noch welche braucht. Diese hatte ich vor einiger Zeit auch bestellt:
https://www.ebay.de/itm/10-Stuck-SHT11-Feuchte-und-Temperatursensor-mit-Stecker/282878550072
Zitat von: jp112sdl am 02 April 2018, 22:16:58
Den DHT22 mag ich gar nicht.
Den muss man 3x höflichst bitten, bis er seine Werte rausrückt.
Es hatte sich jemand bei mir gemeldet, weil der WDS10 Nachbau häufig 0/0-Werte sendet. Ich konnte es auf Anhieb nachstellen.
Hmmm, meine "DHT22" laufen in 6 Sensoren seit 1,5 Jahren problemlos - ohne einen einzigen fehlerhaften Wert.
Allerdins sind es China-Klone: AM2302 - kompatibel zum DHT22...
Martin
Ich mag die DHT22 auch nicht, ich habe 5 nebeneinander gelegt und alle haben komplett andere Werte was die Luftfeuchtigkeit angeht.
Und im freien überleben die auch nicht lange.
/Daniel
Zitat von: ext23 am 03 April 2018, 06:49:51
Und im freien überleben die auch nicht lange.
Wenn man die wieder reinholt, gehen sie meist noch passabel. Sie sind halt nur nicht so gerne draußen.
Hallo
Ich bin aktuell auf der Suche nach einem zuverlässigen wetterfesten Helligkeitssensor.
Idealerweise Homematic oder Jeelink kompatibel.
So bin ich auf diesen Thread gestoßen.
Meine Fähigkeiten mit dem Lötkolben sind allerdings sehr begrenzt.
Gibt es hier jemanden der den bauen und mir fertig verkaufen würde?
Gruß
Daniel
Ich hab jetzt die kleine Platine hier liegen. Rev 1.2
Was für eine Größe haben denn die SMD Bauteile? Ist das noch 0815?
Edit:
Hab einfach mal die 0815 aufgelegt und sie scheinen zu passen :D
Hallo Dirk,
ich hätte auch Interesse an 2-3 Platinen für den Außensensor. Würdest du mir eine PN schreiben?
Ansonsten macht es eventuell Sinn, dass du die Platinen - sofern deine Lizenz das zulässt - bei https://aisler.net/ einstellst? Dort funktioniert das ähnlich wie bei Oshpark und du kannst die Platine als Projekt teilen und jeder kann sich selbst einen Dreierpack bestellen.
Gruß und Danke für deine Arbeit,
Patrik
Hi
Ich habe seit iniegn Tagen den Außensensor im Test.
Hier die Konfiguration:
define OG2_KZ_Helligkeitssensor CUL_HM 309E03
attr OG2_KZ_Helligkeitssensor IODev LGW1
attr OG2_KZ_Helligkeitssensor IOgrp vccu:LGW1
attr OG2_KZ_Helligkeitssensor actCycle 000:10
attr OG2_KZ_Helligkeitssensor actStatus alive
attr OG2_KZ_Helligkeitssensor autoReadReg 5_readMissing
attr OG2_KZ_Helligkeitssensor event-min-interval 1800
attr OG2_KZ_Helligkeitssensor event-on-change-reading luminosity
attr OG2_KZ_Helligkeitssensor expert 2_raw
attr OG2_KZ_Helligkeitssensor firmware 0.15
attr OG2_KZ_Helligkeitssensor model HB-UW-Sen-THPL-O
attr OG2_KZ_Helligkeitssensor peerIDs 00000000,
attr OG2_KZ_Helligkeitssensor room CUL_HM
attr OG2_KZ_Helligkeitssensor serialNr VDTEANFYJ8
attr OG2_KZ_Helligkeitssensor subType THPLSensor
Das der Helligkeitssensor bei zu starker Sonne übersteuert habe ich gelesen und von vornherein eine Sonnenschutzfolie angebracht.
Dennoch ist hat sich der Sensor inzwischen mehrfach nicht mehr gemeldet. Wie hoch darf der Wert "luminosity" sein bevor der Sensor übersteuert?
Darüber hinaus reagiert der Sensor nicht auf ein getConfig.
protCmdPend 3 CMDs pending
Erst wenn ich die Taste drücke meldet sich der Sensor ordnungsgemäß auf das getConfig.
Ist das normal?
Gruß
Daniel
Hallo Daniel,
Zitat von: WhyTea am 21 Mai 2018, 17:27:45
Dennoch ist hat sich der Sensor inzwischen mehrfach nicht mehr gemeldet. Wie hoch darf der Wert "luminosity" sein bevor der Sensor übersteuert?
das Übersteuern sollte vom Senden unabhängig sein, wenn übersteuert, meldet der Sensor 65535.
Zitat von: WhyTea am 21 Mai 2018, 17:27:45
Darüber hinaus reagiert der Sensor nicht auf ein getConfig.
protCmdPend 3 CMDs pending
Hast Du danach die Config Taste gedrückt?
Gruß Peter
Hallo Peter
Danke für die schnelle Antwort.
Wenn ich die Tatse drücke meldet sich der Sensor auf das getConfig.
Also verursacht das Übersteuern keinen Absturz des Sensors? Das Wundert mich jetzt.
Was könnte den sonst dazu führen das der Sensor sich nicht mehr meldet?
Bisher ist es nur aufgetreten wenn der Sensor einige Zeit in der direkten Sonne lag.
Kann das ein Temperaturpoblem sein? In dem geschlossenen Außengehäuse wird es natürlich ordentlich warm!
Hallo Daniel,
Zitat von: WhyTea am 21 Mai 2018, 17:34:29
Bisher ist es nur aufgetreten wenn der Sensor einige Zeit in der direkten Sonne lag.
...
Kann das ein Temperaturpoblem sein? In dem geschlossenen Außengehäuse wird es natürlich ordentlich warm!
hätte ich jetzt auch mal getippt. Decke den Sensor doch mal mit einem Karton mit einem Loch für den Helligkeitssensor ab, damit er nicht so warm wird.
Gruß Peter
Hi,
ich hatte vor einiger Zeit genau das umgekehrte Problem, meine Sensoren haben nachts (wenn es kälter wurde) nicht mehr ordnungsgemäß gesendet. Bei mir war die Lötstelle der Antenne am C1101 Modul kalt. Ordentlich nachgelötet und schon ging wieder alles.
Einer meiner Sensoren erwärmt sich in der Sonne auf über 45 Grad Celsius und übersteht das klaglos.
Guten Morgen,
ich hatte das Thema hier etwas länger auf dem Schirm, die Platinen auch zu Hause, bin aber irgendwie nie dazu gekommen, mir die Bauteile zu besorgen.
Naja, irgendwann hab ich die dann in China bestellt und jetzt ist alles da und ich habe gestern meinen ersten Sensor gelötet. Jetzt ist mir aufgefallen, das ich die (dummerweise) die falsche Speicherdrossel bestellt habe.
Statt einer mir 10 µH habe ich eine mit 4,7 µH eingebaut - ich habe mich schon gewundert, wieso die so heiß wird :o ;D ;D ;D ;D
Anyway - ich habe eine andere Frage: welche Brücke muss ich denn durchtrennen, um den Max zu nutzen? Hier im Thread steht irgendwo JP1, aber im Eagle File ist das doch die untere Pinleiste, sofern ich mich nicht irre. Laut Schema müsste es SJ1 sein, die ist aber ab Werk schon bei mir unterbrochen. Evtl habe ich eine neuere Revision der Platine?
Gruß
Kai
Für MAX1724 Einsatz muss SJ1 komplett unterbrochen sein, keine Brücken zwischen 1-2 oder 2-3.
Laut Schematic-RF.pdf ist die auch im Layout bereits unterbrochen.
Habe übrigens beim MAX1724 ein paar Messungen zur Restwelligkeit gemacht.
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2)
Zitat von: Tom Major am 08 Juni 2018, 10:32:27
Für MAX1724 Einsatz muss SJ1 komplett unterbrochen sein, keine Brücken zwischen 1-2 oder 2-3.
Laut Schematic-RF.pdf ist die auch im Layout bereits unterbrochen.
Habe übrigens beim MAX1724 ein paar Messungen zur Restwelligkeit gemacht.
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2)
Alles klar, dann hat mich das ein wenig verwirrt - lieber dem Schema trauen :-)
Hat jemand eine Idee wie ich testen kann ob das Funkmodul richtig angesprochen wird und funktioniert? Ich habe 5 Sensoren. 4 Stück konnte ich ohne Probleme über OTA mit einer Firmware bespielen. Der 5. meldet sich nicht beim nanoCUL zum flashen.
Die LED blinkt beim Starten 7 mal, also sollte der Bootloader richtig drauf sein und der ATMega funktionieren.
hast du mal gesnifft mit welchen daten (hmid, SN) sich der bootloader meldet?
Zitat von: frank am 16 Juni 2018, 20:42:56
hast du mal gesnifft mit welchen daten (hmid, SN) sich der bootloader meldet?
Mit was kann ich das denn machen? Hab hier ein paar Arduinos liegen die man als "serielle bridge" nehmen könnte. oder tut es auch ein USBASP?
Sniffen geht so:
https://wiki.fhem.de/wiki/Homematic_Nachrichten_sniffen (https://wiki.fhem.de/wiki/Homematic_Nachrichten_sniffen)
Frank will darauf hinaus, dass der OTA-Flasher möglicherweise auf ein anderes Device wartet, als das, wofür sich Dein THPL-Sensor ausgibt. Hast Du geprüft, ob die SN im Bootloader und beim Aufruf des OTA-Flashers übereinstimmen?
Hi,
Ich habe mal eine Frage: ich habe jetzt 2 Innen und 2 Außensensoren gelötet. Bei 3 von denen wird die Drosselspule sehr heiß und dampft auch kurz. Hab schon alles auf Kurzschluss etc überprüft. Versucht zu flashen hab ich bei denen nicht. Bei einem habe ich kein Problem mit der Drossel und der Sensor läuft mittlerweile 2 Tage fehlerfrei.
Wo könnte der Fehler liegen?
Vielen Dank
Beziehst du dich auf diese Schaltung
https://github.com/kc-GitHub/Wettersensor/blob/master/Schematic/Schematic-RF.pdf (https://github.com/kc-GitHub/Wettersensor/blob/master/Schematic/Schematic-RF.pdf) ?
Und dort auf L1? (falls ja, dafür darf keine Drosselspule verwendet werden sondern eine Leistungsinduktivität die für DC/DC-Konverter Einsatz geeignet ist)
Zitat von: Tom Major am 28 Juni 2018, 22:47:45
Beziehst du dich auf diese Schaltung
https://github.com/kc-GitHub/Wettersensor/blob/master/Schematic/Schematic-RF.pdf (https://github.com/kc-GitHub/Wettersensor/blob/master/Schematic/Schematic-RF.pdf) ?
Und dort auf L1? (falls ja, dafür darf keine Drosselspule verwendet werden sondern eine Leistungsinduktivität die für DC/DC-Konverter Einsatz geeignet ist)
Guten Morgen :)
Ja, ich beziehe mich auf diese Schaltung und L1. Sorry, wenn der Begriff Drosselspule falsch war - ich dachte, man nennt dieses Bauteil so. Verbaut habe ich folgendes Bauteil bei L1
ZitatMurata LQH43CN100K03L Induktivität SMD 1812 10 µH 0.65A
Link: https://www.voelkner.de/products/288322/Murata-LQH43CN100K03L-Induktivitaet-SMD-1812-10-H-0.65A-1St..html
Zitat von: Kai-Alfonso am 29 Juni 2018, 06:05:23
Guten Morgen :)
Ja, ich beziehe mich auf diese Schaltung und L1. Sorry, wenn der Begriff Drosselspule falsch war - ich dachte, man nennt dieses Bauteil so. Verbaut habe ich folgendes Bauteil bei L1
Link: https://www.voelkner.de/products/288322/Murata-LQH43CN100K03L-Induktivitaet-SMD-1812-10-H-0.65A-1St..html
Die Spule passt, die verwende ich auch. Ich wollte nur durch die Wortwahl sicherstellen dass du keine herkömmliche (Entstör-) Drossel verwendest, die sind für DC-DC Einsatz absolut ungeeignet.
Layout bei DC-DC ist ziemlich wichtig, da du bei allen 4 die Platine verwendest kann man das wohl ausschließen.
ZitatBei 3 von denen wird die Drosselspule sehr heiß und dampft auch kurz
Der +3,3V Out könnte einen Kurzschluss gegen Gnd haben, das würde einen hohen Strom durch L1 und die Hitze erklären, wenn der Max1724 versucht dagegen zu arbeiten.
Ich würde
- nochmal alles auf Kurzschluss, Lötbrücken usw. checken, besonders die +3,3V Schiene
- Stromaufnahme von Bat messen (am besten Netzteil mit Strombegrenzung)
- +3,3V Out Spannung kontrollieren
- falls das nicht passt +3,3V am Max1724 auftrennen und schauen ob es ohne Last geht..
Wenn der Max1724 korrekt arbeitet sieht man seine DC-DC Regelung an einer gewissen Restwelligkeit am Ausgang:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2)
Hallo zusammen,
ich habe basierend auf dieser Firmware (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1) Dirk's Außensensor modifiziert und einen BME280 bzw. DS18B20 mit draufgepackt, siehe Schaltplan bzw. Bilder im Anhang. Es wäre schön, wenn jemand noch mal kritisch draufschauen könnte, wenn alles ok, werde ich demnächst 10 Leiterplatten bestellen.
PS: Die v1.3 hat den BME280 drauf bzw. GDO2 verkabelt, diese Version werde ich aber nicht bestellen, ich wollte diese aber nicht in die Tonne werfen.
Danke + Gruß
PeMue
Sieht prinzipiell gut aus. :)
Kann ich 2 Platinen bei Dir bestellen? Passen die in das "BOX-SENS-WHITE" Gehäuse von TME?
Ich würde folgende Punkte noch in Erwägung ziehen:
- am CC1101 (generell an jedem Sendemodul) ist es guter Stil, dort einen extra Abblock-C an Vcc zu haben, ich würde 1uF vorschlagen.
- Die Restwelligkeit am MAX1724 ist mit einem 10uF Kerko noch relativ hoch, siehe meine Messung hier https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2)
Kannst Du dort noch einen Tantal-Elko im Layout vorhalten?, muss man ja nicht bestücken wer nicht will, ich würde es tun. Details zur Bauform kann ich gern liefern.
- Nur als Option, ich habe mir ein paar Gedanken zum Thema "Schutz vor "Babbling Idiot" gemacht, https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Babbling%20Idiot%20Protection (https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Babbling%20Idiot%20Protection)
Aus meiner Sicht wäre es schön, für die Batteriemessung die Schaltung A vorzuhalten, für eine bessere Info über den Batteriezustand. Nur als Überlegung und Option, kostet nur einen Mosfet mehr. Wenn es damit nichts wird, auch ok, ein BI kann nur relativ unangenehm werden (https://forum.fhem.de/index.php/topic,57486.msg783197.html#msg783197 (https://forum.fhem.de/index.php/topic,57486.msg783197.html#msg783197)) >:(
- TSL2561 bin ich gerade noch am experimentieren und vergleichen mit 2 anderen Sensoren. Der TSL2561 hat def. Probleme bei hohen Helligkeiten. Solange er aber nicht in die Sonne blickt sieht es noch ok aus. Wenn ich weitere Ergebnisse habe werde ich die im HB-UNI-Sensor1 Projekt darstellen.
Zitat von: Tom Major am 02 Juli 2018, 20:00:51
Kann ich 2 Platinen bei Dir bestellen?
Ob Du kannst, kann ich nicht beurteilen, ich habe notiert, dass Du gerne zwei Platinen haben willst 8) 8) 8)
Mit oder ohne aufgelötetem BME280?
Zitat von: Tom Major am 02 Juli 2018, 20:00:51
Passen die in das "BOX-SENS-WHITE" Gehäuse von TME?
Nein, das Layout ist für den Außensensor, der passt in ein Gainta Gehäuse, ich meine
G250 G201, siehe auch Wiki (https://wiki.fhem.de/w/images/3/3e/Universalsensor-CC1101-Aussen.jpg).
Zitat von: Tom Major am 02 Juli 2018, 20:00:51
- am CC1101 (generell an jedem Sendemodul) ist es guter Stil, dort einen extra Abblock-C an Vcc zu haben, ich würde 1uF vorschlagen.
erledigt
Zitat von: Tom Major am 02 Juli 2018, 20:00:51
- Die Restwelligkeit am MAX1724 ist mit einem 10uF Kerko noch relativ hoch, siehe meine Messung hier https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2)
Kannst Du dort noch einen Tantal-Elko im Layout vorhalten?, muss man ja nicht bestücken wer nicht will, ich würde es tun. Details zur Bauform kann ich gern liefern.
erledigt, Tantal Bauform A bzw. 3216 sollte passen, da müsste es 22 µF/10 V geben
Zitat von: Tom Major am 02 Juli 2018, 20:00:51
- Nur als Option, ich habe mir ein paar Gedanken zum Thema "Schutz vor "Babbling Idiot" gemacht, https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Babbling%20Idiot%20Protection (https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Babbling%20Idiot%20Protection)
Aus meiner Sicht wäre es schön, für die Batteriemessung die Schaltung A vorzuhalten, für eine bessere Info über den Batteriezustand. Nur als Überlegung und Option, kostet nur einen Mosfet mehr. Wenn es damit nichts wird, auch ok, ein BI kann nur relativ unangenehm werden (https://forum.fhem.de/index.php/topic,57486.msg783197.html#msg783197 (https://forum.fhem.de/index.php/topic,57486.msg783197.html#msg783197)) >:(
Ist m.E. nur für den Betrieb mit einer Zelle notwendig, ich habe das Phänomen bei locutus FHT Nachbau: die Spannung reicht nicht aus, um zu senden, der Prozessor geht in Reset und das Ganze geht von vorne los. Das Gute: die Batterie ist recht schnell leer.
Ich habe es umgesetzt, allerdings musste das zweite Bohrloch für den Batteriehalter weichen.
Zitat von: Tom Major am 02 Juli 2018, 20:00:51
... kostet nur einen Mosfet mehr.
Nein, einen MOSFET und einen Widerstand ;D ;D ;D
Schaltplan und Layout im Anhang. Wenn es keine Einwände gibt, werde ich mal eine Charge bestellen.
Für das Thema Firmware compilieren bzw. flashen bräuchte ich dann etwas Nachhilfe, genauso für das Dimensionieren des Spannungsteilers bzw. Ausrechnen des ADC Werts der Spannungsmessung.
Gruß PeMue
Hallo,
kann man die Teile auch komplett bestückt bekommen - und was würde das kosten. Ich habe nicht das entsprechende Equipment um selber zu bestücken. Ich hätte Interesse an einem.
Gruß Christoph
Zitat von: Bennemannc am 03 Juli 2018, 21:01:15
Hallo,
kann man die Teile auch komplett bestückt bekommen - und was würde das kosten. Ich habe nicht das entsprechende Equipment um selber zu bestücken. Ich hätte Interesse an einem.
Gruß Christoph
Ich wäre da auch interessiert. Wäre das möglich?
Zitat von: PeMue am 03 Juli 2018, 15:31:22
Ob Du kannst, kann ich nicht beurteilen, ich habe notiert, dass Du gerne zwei Platinen haben willst 8) 8) 8)
Mit oder ohne aufgelötetem BME280?
Nein, das Layout ist für den Außensensor, der passt in ein Gainta Gehäuse, ich meine G250, siehe auch Wiki (https://wiki.fhem.de/w/images/3/3e/Universalsensor-CC1101-Aussen.jpg).
erledigt
erledigt, Tantal Bauform A bzw. 3216 sollte passen, da müsste es 22 µF/10 V geben
Ist m.E. nur für den Betrieb mit einer Zelle notwendig, ich habe das Phänomen bei locutus FHT Nachbau: die Spannung reicht nicht aus, um zu senden, der Prozessor geht in Reset und das Ganze geht von vorne los. Das Gute: die Batterie ist recht schnell leer.
Ich habe es umgesetzt, allerdings musste das zweite Bohrloch für den Batteriehalter weichen.
Nein, einen MOSFET und einen Widerstand ;D ;D ;D
Schaltplan und Layout im Anhang. Wenn es keine Einwände gibt, werde ich mal eine Charge bestellen.
Für das Thema Firmware compilieren bzw. flashen bräuchte ich dann etwas Nachhilfe, genauso für das Dimensionieren des Spannungsteilers bzw. Ausrechnen des ADC Werts der Spannungsmessung.
Gruß PeMue
Ich schaue tagsüber noch mal in Ruhe drüber.
Das bestellen "können" war als höfliche Anfrage gemeint ob du sowas überhaupt in Betracht ziehst ;) Ja, ich würde gern 2 Platinen nehmen :)
- Du bestellst die BME280 als chip in China und lötest die selber drauf? Mit Heissluft oder hast du einen Reflow Ofen?
- Gainta G250 Gehäuse, alles klar, passt für mich.
- Tantal Bauform A passt, da gibt es bei Farnell > 50 versch. Typen für 22u und >= 10V.
- Aus meiner Sicht ist meine BI "Schutzschaltung" auch für die Variante mit 2 Zellen ohne Step-up gut. Dort kann m.E. der BI Effekt genau so auftreten (und tat es wahrscheinlich auch bei dem verlinkten Post von jp112sdl, glaub nicht das da ein Step-Up drin war.
- Kannst Du noch bis Wochenende mit dem Bestellen warten? Ich würde gern noch den MAX44009 gegen den TSL2561 testen, das Teil ist da. Der TSL2561 hat wie geschrieben ein Problem bei hohen Helligkeiten.
- Falls der MAX besser abschneidet: wäre schön wenn dein SV1 Stecker zum MAX44009 Modul passen würde (VIN/GND/SCL/SDA)
https://www.aliexpress.com/item/GY-49-MAX44009-Ambient-Light-Sensor-Module-for-Arduino-with-4P-Pin-Header-Module/32821853886.html (https://www.aliexpress.com/item/GY-49-MAX44009-Ambient-Light-Sensor-Module-for-Arduino-with-4P-Pin-Header-Module/32821853886.html)
Spannungsmessung Variante mit Mosfet habe ich hier bereits implementiert:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-SEC-WDS-2)
Nehme ich als Option noch in den Unisensor auf.
Hallo zusammen,
Zitat von: Bennemannc am 03 Juli 2018, 21:01:15
... kann man die Teile auch komplett bestückt bekommen - und was würde das kosten.
Zitat von: holzwurm83 am 03 Juli 2018, 22:27:27
Ich wäre da auch interessiert. Wäre das möglich?
wenn jemand von Euch das Sourcing der (Haupt-)-Bauteile übernehmen kann, dann ja (in kleiner Stückzahl).
Den Kleinkram (Widerstände, Kondensatoren, etc.) habe ich, Prozessor und Sensoren müsstet ihr bestellen und mir zuschicken.
Zitat von: Tom Major am 04 Juli 2018, 00:06:12
- Du bestellst die BME280 als chip in China und lötest die selber drauf? Mit Heissluft oder hast du einen Reflow Ofen?
Mittlerweile mit Schablone und Reflow Ofen. Das funktioniert ziemlich gut, ich mache das für die kritischen Bauteile (BME180, BME280 bzw. Lichtsensor), den Rest bestücke ich per Hand.
Gruß PeMue
Edit:Platinenbedarfv1.[2|4|5]1x vbs (kompletten Sensor, Version egal)
v1.4 (max. 6 Stück)1x Bennemannc (bestückt)
?x holzwurm83 (bestückt) per PM gestrichen
2x Tom Major per PM gestrichen (außer BME280)
1x sentinel1 -> erl.
1x oli82 -> erl.
3x Kai-Alfonso (mit BME280 (Reichelt)) -> erl.
v1.55x PeMue -> erl.
2x Tom Major mit BME280/MAX40009? per PM gestrichen
3x Gernott (per PM) -> erl.
4x Kai-Alfonso per PM
Zitat von: Tom Major am 04 Juli 2018, 00:06:12
- Kannst Du noch bis Wochenende mit dem Bestellen warten? Ich würde gern noch den MAX44009 gegen den TSL2561 testen, das Teil ist da. Der TSL2561 hat wie geschrieben ein Problem bei hohen Helligkeiten.
Mache ich, vorher komme ich sowieso nicht dazu, mir die Leiterplatte noch mal genau anzuschauen.
Zitat von: Tom Major am 04 Juli 2018, 00:06:12
- Falls der MAX besser abschneidet: wäre schön wenn dein SV1 Stecker zum MAX44009 Modul passen würde (VIN/GND/SCL/SDA)
https://www.aliexpress.com/item/GY-49-MAX44009-Ambient-Light-Sensor-Module-for-Arduino-with-4P-Pin-Header-Module/32821853886.html (https://www.aliexpress.com/item/GY-49-MAX44009-Ambient-Light-Sensor-Module-for-Arduino-with-4P-Pin-Header-Module/32821853886.html)
erledigt, den TSL ersetze ich nicht, weil ich noch eine von Dirk's Platinen habe und eine Schablone dazu bestellen möchte ;)
Gruß PeMue
Zitat von: PeMue am 04 Juli 2018, 16:03:24
Mittlerweile mit Schablone und Reflow Ofen. Das funktioniert ziemlich gut, ich mache das für die kritischen Bauteile (BME180, BME280 bzw. Lichtsensor), den Rest bestücke ich per Hand.
Klingt ziemlich professionell. Die BME280 müsste ich Dir vorher liefern. nehme ich an, Lager hast du sicher keins ;)
Glaubst Du den kann man auch von der Seite löten? Die Pads müssten dafür etwas länger sein und über das Gehäuse rausgehen.
Könntest Du bitte bei Gelegenheit das Eagle file posten oder mir mailen? Dann schaue ich da noch mal übers Layout.
Zitat- Falls der MAX besser abschneidet: wäre schön wenn dein SV1 Stecker zum MAX44009 Modul passen würde (VIN/GND/SCL/SDA)
https://www.aliexpress.com/item/GY-49-MAX44009-Ambient-Light-Sensor-Module-for-Arduino-with-4P-Pin-Header-Module/32821853886.html
erledigt, den TSL ersetze ich nicht, weil ich noch eine von Dirk's Platinen habe und eine Schablone dazu bestellen möchte ;)
Wenn der SV1 Stecker geändert ist reicht mir das völlig um das MAX44009 Modul drauf zusetzen, Danke :)
Habe heute erste Tests mit dem MAX44009 gemacht, den werde ich nehmen.
Der TSL2561 übersteuert zu leicht, und auch bei der Lux Berechnung liegen Welten dazwischen.
Beim MAX kommt ein fertiger Lux Wert mit im Hintergrund laufenden Autoranging raus, beim TSL muss man mit einem Rudel Magic Numbers hantieren, die auch noch package-abhängig sind und sich um die Integrationszeit selber kümmern.
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SensorTest_Lux (https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SensorTest_Lux)
@PeMue
ich würde auch eine Platine nehmen,falls eine übrig bleibt.
Gruß,
Claudiu
Guten Morgen,
ich habe mal eine Frage zu dem TSL2561. Soweit ich hier gelesen hab, hat die Firmware vorher den vom Sensor ermittelten Wert in Lux wiedergegeben, dieser wurde jedoch auf Luminosity geändert. Welche Maßeinheit hat denn Luminosity? Für nicht Physiker ist der Unterschied zwischen Lux, Lumen, Candela, Watt etc schwer zu kapieren. 8) 8) :o :o
Meine Frage: Wie rechne ich von Luminosity zu Lux zurück? (falls das geht). Ich habe jetzt 2 Outdoor Sensoren an der gleichen Stelle platziert, einen mit einer Fensterfolie (beliebige von Amazon), einen ohne. Das Verhältnis zueinander habe ich mit einem Dreisatz ermittelt und dann per userReading wieder dargestellt.
PS:
@PeMue
2 Platinen würde ich auch nehmen :-)
Zitat von: Kai-Alfonso am 12 Juli 2018, 08:47:27
@PeMue
2 Platinen würde ich auch nehmen :-)
Ist oben eingetragen. Ich habe gestern mal 10 Platinen bestellt.
Gruß PeMue
Zitat von: PeMue am 12 Juli 2018, 09:35:47
Ist oben eingetragen. Ich habe gestern mal 10 Platinen bestellt.
Gruß PeMue
Super danke - sind die jetzt dann mit BME280 schon bestückt von Dir? Das ging jetzt aus den Antworten glaube ich nicht hervor
Edit: ach, überlesen. Also ich besorge die Sensoren und die bestückst die dann mit deinem Ofen? Den Rest kann ich dann per Hand löten. Hab ich das richtig verstanden?
Zitat von: Kai-Alfonso am 12 Juli 2018, 10:07:23
Edit: ach, überlesen. Also ich besorge die Sensoren und die bestückst die dann mit deinem Ofen? Den Rest kann ich dann per Hand löten. Hab ich das richtig verstanden?
Ja, hast Du richtig verstanden.
Gruß PeMue
Zitat von: PeMue am 12 Juli 2018, 12:14:40
Ja, hast Du richtig verstanden.
Gruß PeMue
Super - den Sensor nehm ich an plain ohne Breakout Board - so wie ich z.B Reichelt anbietet?
https://www.reichelt.de/kombo-sensor-luftdruck-luftfeuchtigkeit-temp-bme-280-p159825.html?GROUPID=8097& (https://www.reichelt.de/kombo-sensor-luftdruck-luftfeuchtigkeit-temp-bme-280-p159825.html?GROUPID=8097&)
Wie sieht es eigentlich mit dem Helligkeitssensor aus?
@Tom Major
Du hast ja den MAX44009 getestet. Wird der schon in der Master Branch des Wettersensors unterstützt?
Zitat von: Kai-Alfonso am 12 Juli 2018, 08:47:27
Guten Morgen,
ich habe mal eine Frage zu dem TSL2561. Soweit ich hier gelesen hab, hat die Firmware vorher den vom Sensor ermittelten Wert in Lux wiedergegeben, dieser wurde jedoch auf Luminosity geändert. Welche Maßeinheit hat denn Luminosity? Für nicht Physiker ist der Unterschied zwischen Lux, Lumen, Candela, Watt etc schwer zu kapieren. 8) 8) :o :o
Meine Frage: Wie rechne ich von Luminosity zu Lux zurück? (falls das geht). Ich habe jetzt 2 Outdoor Sensoren an der gleichen Stelle platziert, einen mit einer Fensterfolie (beliebige von Amazon), einen ohne. Das Verhältnis zueinander habe ich mit einem Dreisatz ermittelt und dann per userReading wieder dargestellt.
Die zwei internen Kanäle (CH0/CH1) beim TSL2561 liefern aufgrund des chip designs ganz bestimmte, "spezielle" Helligkeitswerte. Die Entwickler haben dann wahrscheinlich ein Luxmeter danebengestellt und versucht, Formeln zur Lux-Berechnung aus den Helligkeiten zu generieren ;D
Eine Formel über den ganzen Bereich ging wohl nicht, deshalb sieht das Ergebnis so aus (Datenblatt S.23):
CS Package
For 0 < CH1/CH0 <= 0.52 Lux = 0.0315 CH0 − 0.0593 CH0 ((CH1/CH0)1.4)
For 0.52 < CH1/CH0 <= 0.65 Lux = 0.0229 CH0 − 0.0291 CH1
For 0.65 < CH1/CH0 <= 0.80 Lux = 0.0157 CH0 − 0.0180 CH1
For 0.80 < CH1/CH0 <= 1.30 Lux = 0.00338 CH0 − 0.00260 CH1
For CH1/CH0 > 1.30 Lux = 0
T, FN, and CL Package
For 0 < CH1/CH0 <= 0.50 Lux = 0.0304 CH0 − 0.062 CH0 ((CH1/CH0)1.4)
For 0.50 < CH1/CH0 <= 0.61 Lux = 0.0224 CH0 − 0.031 CH1
For 0.61 < CH1/CH0 <= 0.80 Lux = 0.0128 CH0 − 0.0153 CH1
For 0.80 < CH1/CH0 <= 1.30 Lux = 0.00146 CH0 − 0.00112 CH1
For CH1/CH0 > 1.30 Lux = 0
Zitat von: Kai-Alfonso am 12 Juli 2018, 13:26:49
@Tom Major
Du hast ja den MAX44009 getestet. Wird der schon in der Master Branch des Wettersensors unterstützt?
Sensorklasse für den Max hatte ich schon eingecheckt, Integration in den Unisensor passiert die nächsten Tage.
Zitat von: Tom Major am 12 Juli 2018, 15:15:22
Die zwei internen Kanäle (CH0/CH1) beim TSL2561 liefern aufgrund des chip designs ganz bestimmte, "spezielle" Helligkeitswerte. Die Entwickler haben dann wahrscheinlich ein Luxmeter danebengestellt und versucht, Formeln zur Lux-Berechnung aus den Helligkeiten zu generieren ;D
Eine Formel über den ganzen Bereich ging wohl nicht, deshalb sieht das Ergebnis so aus (Datenblatt S.23):
CS Package
For 0 < CH1/CH0 <= 0.52 Lux = 0.0315 CH0 − 0.0593 CH0 ((CH1/CH0)1.4)
For 0.52 < CH1/CH0 <= 0.65 Lux = 0.0229 CH0 − 0.0291 CH1
For 0.65 < CH1/CH0 <= 0.80 Lux = 0.0157 CH0 − 0.0180 CH1
For 0.80 < CH1/CH0 <= 1.30 Lux = 0.00338 CH0 − 0.00260 CH1
For CH1/CH0 > 1.30 Lux = 0
T, FN, and CL Package
For 0 < CH1/CH0 <= 0.50 Lux = 0.0304 CH0 − 0.062 CH0 ((CH1/CH0)1.4)
For 0.50 < CH1/CH0 <= 0.61 Lux = 0.0224 CH0 − 0.031 CH1
For 0.61 < CH1/CH0 <= 0.80 Lux = 0.0128 CH0 − 0.0153 CH1
For 0.80 < CH1/CH0 <= 1.30 Lux = 0.00146 CH0 − 0.00112 CH1
For CH1/CH0 > 1.30 Lux = 0
Ah ja - verstehe - ist halt dann quasi eine rechnerische Annäherung an den Lux wert, aufgrund der Gemessenen Strahlungsenergie auf dem Chip? So kann ich mir das jedenfalls gut vorstellen.
ZitatSensorklasse für den Max hatte ich schon eingecheckt, Integration in den Unisensor passiert die nächsten Tage.
Super, klasse - ich bin mal beim Chinahändler ;D
Guten Morgen,
ich habe mal eine Frage und vielleicht kann mir das jemand mal (physikalisch) erklären.
Ich habe ein Folie, die ich zweilagig über den TSL2561 gelegt habe. Um den Filterwert zu ermitteln, habe ich einen Außensensor ohne Folie bestückt - beide sind an der selben Stelle nebeneinander am Gebäude. Meine Erwartung war, das ich jetzt durch die Messung von beiden den Filterwert ermitteln kann und dieser Wert immer konstant ist. Leider scheint der Wert der gefilterten UV Strahlen aber zu unterscheiden. Ich hab gestern mal zwischen 16 Uhr und 22 Uhr eine Messung rausgesucht (es war nicht so hell, so das der Sensor ohne Filter keinen Überlauf hat), wo die Werte zwischen 32% und 64% geschwankt sind.
Hat jemand dafür eine Erklärung? Im Anhang sind einmal im gewählten Zeitslot der Graph für den Filterwert (grün) und einmal die gemessene Helligkeit vom Sensor ohne Filter (rot)
Die von mir weiter oben geposteten Näherungsformeln der TSL Chip-Designer für die Lux Berechnung lassen eine starke Nichtlinearität zwischen Helligkeit und Lux für ihren Chip vermuten, sonst müssten sie die Formeln nicht in 5 Bereiche aufteilen. Insofern dürfte der errechnete Filterwert auch keine Konstante sein.
Ich sehe ziemliche Helligkeitsschwankungen - kenne ich bin meinem bei leichter Bewölkung. Die Sensoren messen nicht zum gleichen Zeitpunkt - insofern ist bei solchen Verhältnissen auch mit entsprechenden Fluktuationen zu rechnen - logisch, dass das Verhältnis dann nicht konstant bleibt. So um 18.15 Uhr, bei konstanter Helligkeit, hat sich auch der Quotient beruhigt.
Interessant auch der konstant niedrigere Quotient bei abfallender Helligkeit kurz davor. Wenn die Quotientenberechung immer zum Zeitpunkt des Sensors mit Filter erfolgt, wäre das auch eine Erklärung.
Ich würde das nicht überinterpretieren.
Hallo zusammen,
die Platinen Rev. 1.4 liegen auf der Post und ich komme die Ganze Woche nicht rechtzeitig heim, um die zu holen >:( >:( >:(
Gruß PeMue
Edit: Die Platinen wurden doch ausgeliefert, warum auch immer ;D
Zitat von: Pfriemler am 24 Juli 2018, 09:39:11
Ich sehe ziemliche Helligkeitsschwankungen - kenne ich bin meinem bei leichter Bewölkung. Die Sensoren messen nicht zum gleichen Zeitpunkt - insofern ist bei solchen Verhältnissen auch mit entsprechenden Fluktuationen zu rechnen - logisch, dass das Verhältnis dann nicht konstant bleibt. So um 18.15 Uhr, bei konstanter Helligkeit, hat sich auch der Quotient beruhigt.
Interessant auch der konstant niedrigere Quotient bei abfallender Helligkeit kurz davor. Wenn die Quotientenberechung immer zum Zeitpunkt des Sensors mit Filter erfolgt, wäre das auch eine Erklärung.
Ich würde das nicht überinterpretieren.
Also, wenn ich das richtig sehe, wird dann nicht in Lux gemessen, sondern der Wert ist fiktiv auf einer Scala von 0 (dunkel) bis ca 40.000 (hell, je nachdem wo der Puffer überläuft) - ich dachte erst, die Grenze wäre bei 32.767, das würde bedeuten, das die als vartype integer genommen hätten statt long. Allerdings hab ich auch Werte jenseits der 34.000er gemessen.
Auf jeden Fall kann ich mir dann doch das Rausrechnen des Filterwerts sparen, wenn ich alle Aussensensoren mit dem gleichen Filter bestückt habe. Weil das Verhältnis von dunkel zu hell bleibt ja gleich, oder?
Ach, der Chip ist echt Käse
Wieso sollte das Ding nicht in Lux messen? Verträgt halt keine pralle Sonne, deswegen der Filter als "Divisor", mit dessen Wert man hinterher wieder die originale Helligkeit berechnet. Ich komme aktuell auf bis zu 130.000 lx in praller Sonne, gemeinhin betrachtet man 100.000 lux als Sommermittagshelligkeit. Wo ist das Problem?
Wenn Du alle Sensoren mit der gleichen Folie bestückst und nur vergleichst, brauchst Du keine Umrechnung. Spätestens wenn Du eine andere Messeinrichtung, die Lux liefert, dazu nimmst, denkst Du doch über eine Umrechnung nach. Tut doch auch nicht weh, so ein Userreading.
Ich habe für meine Folie damals mit einem handelsüblichen Luxmeter 0.279 als Faktor ermittelt. Das kann man heute doch mit fast jedem Handy und einer App.
Habe meine Tests mit TSL2561 und MAX44009 bei hoher Helligkeit abgeschlossen. Den TSL2561 werde ich nicht mehr einsetzen.
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SensorTest_Lux (https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SensorTest_Lux)
Hallo die Runde
Hätte noch jemand jeweils 2 Platinen für den Innensensor und den Außensensor abzugeben?
Viele Grüße
G.
Hallo alle zusammen!
Mit großem Interesse lese ich hier seit einiger Zeit mit... und habe nun beschlossen, mir die Sensoren selbst zu bauen. Es wird zwar mein erstes SMD Löt Projekt - aber man wächst ja bekanntlich an seinen Aufgaben :).
Zuerst möchte ich mit dem Ultraschalsensor (https://forum.fhem.de/index.php/topic,89857.0.html (https://forum.fhem.de/index.php/topic,89857.0.html)) beginnen, da der auf dem Universalsensor basiert, schreibe ich mal hier.
Das Wiki dazu (https://wiki.fhem.de/wiki/Universalsensor (https://wiki.fhem.de/wiki/Universalsensor)) habe ich gelesen, das GitHub Repository (https://github.com/kc-GitHub/Wettersensor (https://github.com/kc-GitHub/Wettersensor)) wahrgenommen.
Da das hier meine erste bestellte Platine wird (früher habe ich selbst geätzt), verzeiht mir bitte die Frage, wie ich an die Gerber Dateien komme. Mit dem Schematic-RF.pdf komme ich ja nicht weiter, oder? Im Repository stehen Eagle Files (https://github.com/kc-GitHub/Wettersensor/tree/master/Schematic (https://github.com/kc-GitHub/Wettersensor/tree/master/Schematic)). Wie bekomme ich aus denen die Gerber Files? Und - kann mir bitte jemand einen Tip geben, wo ich die Platinen dann ordern kann?
Der zweite Step wäre dann das Bestellen der benötigte Bauteile. Folgendes habe ich gefunden:
Funkmodul (CC1101)
https://de.aliexpress.com/item/CC1101-Wireless-Module-Long-Distance-Transmission-Antenna-868MHZ-M115/32635393463.html
MAX1724 Step-Up-Converter
https://de.aliexpress.com/item/5PCS-MAX1724EZK33-MAX1724EZK-MAX1724EZ-MAX1724E-MAX1724-SOT23-5/32353066414.html
Passt das beides?
Wo bestellt ihr den Atmega 328p? Da habe ich leider nichts unverbautes gefunden...
Welche Bauform müssen die SMD R's und C's haben? Wo bestellt ihr die für Euch?
Hat jemand einen Link für die 10yH Induktivität (ich glaube mich zu erinern, dass hier irgendwo in den 165 Seiten einer enthalten war, habe ihn aber nicht wieder gefunden)?
Jetzt fehlen mir nur noch der Config Taster und die LED - habt ihr bitte einen Link, damit die Bauform passt?
Die Quellen für Ultraschall Sensor und Batteriehalter stehen im Thread zum Ultraschallsensor (https://forum.fhem.de/index.php/topic,89857.0.html (https://forum.fhem.de/index.php/topic,89857.0.html)).
Danke!
Peter
Zitat von: PSI69 am 17 August 2018, 11:03:46
Wie bekomme ich aus denen die Gerber Files? Und - kann mir bitte jemand einen Tip geben, wo ich die Platinen dann ordern kann?
Ggf. Online Converter ....
https://www.pcbway.com/blog/News/New_feature_released___convert_Eagle_brd_to_Gerber_file_by_one_click_online.html
Platinen bestellen ....
https://jlcpcb.com/
-> Kostet 2$ + 6$ Versand (Versand +/- 1$, bin mir micht mehr sicher)
-> Wenn du PCP dort bestellst kannst SMD-Teile ohne zusätzliche Versandkosten mitbestellen. Vor ein paar Wochen zusätzlich Gutschein 4 oder 5$ als Erstbesteller.
-> Habe vor kurzem dort bestellt, Qualität sehr gut, Lieferung hat ca. 2 Wochen gedauert
Zitat von: PSI69 am 17 August 2018, 11:03:46
Wo bestellt ihr den Atmega 328p? Da habe ich leider nichts unverbautes gefunden...
Zum Beispiel da ...
https://de.aliexpress.com/item/ATMEGA328P-AU-QFP-ATMEGA328-AU-TQFP-ATMEGA328P-MEGA328-AU-SMD-new-and-original-IC-ATMEGA328P-U/32887927630.html?spm=a2g0x.search0104.3.2.37ab4894YaXXRg&ws_ab_test=searchweb0_0,searchweb201602_2_10320_10152_10151_10065_10344_10068_10342_10547_10343_10340_10548_10341_10696_5013115_10084_10083_10618_10304_10307_10820_10821_10302_10843_10059_100031_5013415_10319_5013215_10103_5013315_10624_10623_10622_10621_10620,searchweb201603_51,ppcSwitch_5&algo_expid=1a3b921d-5b2e-4fbe-a1bb-9e0a0334c3a8-0&algo_pvid=1a3b921d-5b2e-4fbe-a1bb-9e0a0334c3a8&transAbTest=ae803_1&priceBeautifyAB=0
Bei den restlichen Fragen kann ich dir leider nicht helfen. Habe keinen Universalsensor. Meine Homematic basieren auf der Basis von ...
https://github.com/pa-pa/HMSensor/tree/master/HMSensor-StepUp
@kadettilac89
Danke, das hilft mir weiter!
@All
Die Speicherdrossel habe ich inzwischen wieder gefunden (Murata Serie LQH4C/LQH3C). Bei Ali habe ich das so nicht gefunden; also Reichelt? Hat jemand eine 'Fernost' Bezugsquelle?
Zu den SMDs glaube ich mal Bauform 0805 gelesen zu haben. Kann das jemand bestätigen? Dann decke ich mich damit bei Ali ein...
Bleiben die LED (auch SMD 0805?) und der Cfg Taster.
[Edit]
Passen die Taster? https://de.aliexpress.com/item/10pcs-2x4-2-4-3-5-MM-Micro-SMD-Tact-Switch-Side-Button-Switch-MP3-MP4/32823317862.html (https://de.aliexpress.com/item/10pcs-2x4-2-4-3-5-MM-Micro-SMD-Tact-Switch-Side-Button-Switch-MP3-MP4/32823317862.html)
[Edit2]
OK, die LQH3C von Reichelt ist Bauform 1210, also das hier https://de.aliexpress.com/item/50-teile-los-SMD-Inductor-1210-1UH-10UH-15UH-22UH-47UH-100UH-SMD-Wicklung-inductor/32849482515.html (https://de.aliexpress.com/item/50-teile-los-SMD-Inductor-1210-1UH-10UH-15UH-22UH-47UH-100UH-SMD-Wicklung-inductor/32849482515.html)?
Danke
Peter
die von dir geposteten taster wirst du schwer löten können.
taster müssten diese hier sein ...
https://de.aliexpress.com/item/100PCS-3X6X2-5mm-Tactile-Push-Button-Switch-Tact-Switch-Micro-Switch-2-Pin-SMD/32672806661.html?spm=a2g0x.search0104.3.214.4aaadc29E2ZaDo&ws_ab_test=searchweb0_0,searchweb201602_2_10320_10152_10151_10065_10344_10068_10342_10547_10343_10340_10548_10341_10696_5013115_10084_10083_10618_10304_10307_10820_10821_10302_10843_10059_100031_5013415_10319_5013215_10103_5013315_10624_10623_10622_10621_10620,searchweb201603_51,ppcSwitch_5&algo_expid=204f3a8f-6b05-46df-b72a-f099ab9192da-30&algo_pvid=204f3a8f-6b05-46df-b72a-f099ab9192da&transAbTest=ae803_1&priceBeautifyAB=0
SMD-Teile nicht besser bei jlcpcb wenn du dort die PCB bestellst? SMD-Shop heißt https://lcsc.com ... beide gehören zu / nutzen https://easyeda.com/
SMD-Größe dürfte 0805 sein, bei der Platine von papa sind es 0805, und die sehen ähnlich aus.
@kadettilac89
Dann schaue ich mich auf https://lcsc.com (https://lcsc.com) nach den SMDs um - wie gesagt, meine erste PCB Bestellung und mein erster Ausflug ins SMD Gefielde. Nach diversen Videos dazu, denke ich - machbar...
Ich danke Dir noch einmal!
Peter
Alles halb so wild. Nur eine Frage der Technik. Bestell dir am besten ein paar atmega328 als Reserve. Und ggf lötpaste.
OT:
Paste ist schon bestellt - wobei theoretisch auch Kolofonium in Spiritus reichen müßte; werde ich dann sehen. Jetzt geht es übers WE ans Bestellen. Zum Lötkolben greife ich dann, wenn die Temperaturen draußen wieder kälter und die Nachmittage dunkel sind. Halt Winterbeschäftigung.
Peter
Ich rede von lötpaste nicht von flussmittel
Hallo Namenskollege,
Zitat von: PSI69 am 17 August 2018, 11:03:46
Der zweite Step wäre dann das Bestellen der benötigte Bauteile. Folgendes habe ich gefunden:
Funkmodul (CC1101)
https://de.aliexpress.com/item/CC1101-Wireless-Module-Long-Distance-Transmission-Antenna-868MHZ-M115/32635393463.html
MAX1724 Step-Up-Converter
https://de.aliexpress.com/item/5PCS-MAX1724EZK33-MAX1724EZK-MAX1724EZ-MAX1724E-MAX1724-SOT23-5/32353066414.html
Passt das beides?
ja, das passt.
Zitat von: PSI69 am 17 August 2018, 11:03:46
Wo bestellt ihr den Atmega 328p?
Wenn es schnell gehen muss, bei Voelkner, da geht es ab 29 € portofrei, sonst bei Aliexpress.
Zitat von: PSI69 am 17 August 2018, 11:03:46
Welche Bauform müssen die SMD R's und C's haben?
Ich habe mal die exportierte Stückliste angehängt, da stehen die Bauformen drin.
Zitat von: PSI69 am 17 August 2018, 11:03:46
Wo bestellt ihr die für Euch?
Ebenfalls bei Voelkner oder bei Aliexpress.
Zitat von: PSI69 am 17 August 2018, 11:03:46
Hat jemand einen Link für die 10yH Induktivität (ich glaube mich zu erinern, dass hier irgendwo in den 165 Seiten einer enthalten war, habe ihn aber nicht wieder gefunden)?
Müsste direkt auf dem Schaltplan bzw. in der Stückliste stehen. Dann mit der Bezeichnung bei Voelkner bzw. Reichelt suchen.
Zitat von: PSI69 am 17 August 2018, 14:11:57
... also das hier https://de.aliexpress.com/item/50-teile-los-SMD-Inductor-1210-1UH-10UH-15UH-22UH-47UH-100UH-SMD-Wicklung-inductor/32849482515.html (https://de.aliexpress.com/item/50-teile-los-SMD-Inductor-1210-1UH-10UH-15UH-22UH-47UH-100UH-SMD-Wicklung-inductor/32849482515.html)?
Diese würde ich ohne Datenblatt oder genaue Bezeichnung nicht kaufen, Du brauchst einen Typ, der den Strom kann (siehe auch Datenblatt MAX1724).
Zitat von: PSI69 am 17 August 2018, 11:03:46
Jetzt fehlen mir nur noch der Config Taster und die LED - habt ihr bitte einen Link, damit die Bauform passt?
Der Taster heißt DTSM-3, einfach bei Aliexpress danach suchen.
Zitat von: PSI69 am 17 August 2018, 11:03:46
Zuerst möchte ich mit dem Ultraschalsensor (https://forum.fhem.de/index.php/topic,89857.0.html (https://forum.fhem.de/index.php/topic,89857.0.html)) beginnen, da der auf dem Universalsensor basiert ...
Wenn Du noch
ein bisschen (lange?) wartest, ich layoute gerade einen Ultraschallsensor, der in ein kleineres Gehäuse passt, damit ich den in meinen Öltank einbauen kann.
Zitat von: PSI69 am 17 August 2018, 15:04:55
Paste ist schon bestellt
Lötest Du mit dem Fön oder mit dem Ofen :o? Ich würde ein gutes (dünnes) Lötzinn besorgend und dann mit einer dünner Spitze löten. Oder Du baust Dir vorher den DIY Lötkolben aus der Bastelecke, der hat 1206 Bauteile ;D.
Gruß Peter
@kadettilac89
OK: Lötpaste != Flussmittel in Gelform, habe ich noch nicht benutzt... Wieder etwas gelernt!
@PeMue
Danke für Hinweise und Stückliste! Ich will meinen ersten Versuch mit feiner Spitze + Pinzette und Lupenlampe durchführen; schauen wir mal. Ofen habe ich nicht, mit Fön meinst Du einen Heissluftfön?
@All
Wie fixiert ihr die SMD (Klein-)Bauteile zum Löten auf der Platine. Bei den ICs habe ich auf Youtube gesehen - einfach einen PIN nach dem Ausrichten anlöten, den Rest dann ganz in Ruhe. Oder nehmt ihr alle Ofen/Fön + Lötpaste?
... fragt sich gerade der
Peter
So ein Schitt - ich scheitere gerade daran, an die Gerber Files zu kommen. Bei https://www.pcbway.com/member/brdtogerber.aspx (https://www.pcbway.com/member/brdtogerber.aspx) schlägt bei allen 3 Boards das Konvertieren fehl - auf der Seite steht etwas von Eagle Version 7.7. Keine Ahnung, welche Version die Files aus 2015 sind?!?
OK, also KiCad auf den iMac gepackt und versucht damit die Files zu öffnen - auch wieder negatives Ergebnis. Dito für DipTrace (läuft mit Wine auf dem Mac). DipTrace benötigt beim Import von Eagle mindestens Version 7.5; scheint also eine ältere Version zu sein.
Bin jetzt frustriert und hoffe auf einen Tip...
Peter
@PeMue
Ich suche mir gerade die Teile zusammen...
Den DTSM-3 Taster finde ich bei Ali (in welcher Schreibweise auch immer) nicht. Kann ich den von kadettilac89 empfohlenen (https://de.aliexpress.com/item/100PCS-3X6X2-5mm-Tactile-Push-Button-Switch-Tact-Switch-Micro-Switch-2-Pin-SMD/32672806661.html (https://de.aliexpress.com/item/100PCS-3X6X2-5mm-Tactile-Push-Button-Switch-Tact-Switch-Micro-Switch-2-Pin-SMD/32672806661.html)) nehmen? Wenn ich mir die Platine auf dem PDF und die angegebenen Maße bei AliExpress ansehe - sollte das doch passen?
Danke Peter
Hallo Peter,
Zitat von: PSI69 am 18 August 2018, 09:51:13
Ofen habe ich nicht, mit Fön meinst Du einen Heissluftfön?
ich meine damit eine Heißluft"pistole". Ich schau mal nach einem Link. Mit Lötspitze ist aber m.E. besser.
Zitat von: PSI69 am 18 August 2018, 09:51:13
Wie fixiert ihr die SMD (Klein-)Bauteile zum Löten auf der Platine.
Ein Pad verzinnen, einen Pin anlöten, kurz warten. Dann den anderen Pin sauber anlöten. Wieder kurz warten, danach den ersten Pin sauber verlöten.
Zitat von: PSI69 am 18 August 2018, 11:00:33
Den DTSM-3 Taster finde ich bei Ali (in welcher Schreibweise auch immer) nicht. Kann ich den von kadettilac89 empfohlenen (https://de.aliexpress.com/item/100PCS-3X6X2-5mm-Tactile-Push-Button-Switch-Tact-Switch-Micro-Switch-2-Pin-SMD/32672806661.html (https://de.aliexpress.com/item/100PCS-3X6X2-5mm-Tactile-Push-Button-Switch-Tact-Switch-Micro-Switch-2-Pin-SMD/32672806661.html)) nehmen? Wenn ich mir die Platine auf dem PDF und die angegebenen Maße bei AliExpress ansehe - sollte das doch passen?
3x6x2.5 mm tactile switch passt.
Zitat von: PSI69 am 18 August 2018, 10:34:58
So ein Schitt - ich scheitere gerade daran, an die Gerber Files zu kommen.
Ich schau mal, dass ich die Gerberdaten heute erzeuge, dann lade ich sie auf meinen github Account hoch. Alternativ: Eagle Demoversion (ab 6.x) installieren und selber machen ;).
Gruß Peter
ZitatEin Pad verzinnen, einen Pin anlöten, kurz warten. Dann den anderen Pin sauber anlöten. Wieder kurz warten, danach den ersten Pin sauber verlöten.
OK, so hatte ich mir das vorgestellt, schön dass Du das auch so machst...
ZitatIch schau mal, dass ich die Gerberdaten heute erzeuge, dann lade ich sie auf meinen github Account hoch. Alternativ: Eagle Demoversion (ab 6.x) installieren und selber machen
Dankeschön! Das mit der Eagle Testversion hatte ich auch schon überlegt, war bisher aber der Meinung, die gibt es nur für Windows - habe mich gerade eines besseren belehren lassen. Das Thema wollte ich mir sowieso einmal näher ansehen über den nächsten Winter - früher einmal (als die Hühner noch Schleppsäbel trugen) - habe ich das mit Millimeterpapier erledigt.
Peter
Hallo Peter,
Zitat von: PeMue am 18 August 2018, 11:25:54
Ich schau mal, dass ich die Gerberdaten heute erzeuge, dann lade ich sie auf meinen github Account hoch. Alternativ: Eagle Demoversion (ab 6.x) installieren und selber machen ;).
siehe hier https://github.com/pemue-git/pcb/tree/master/homematic. Die Formatierung läßt noch etwas zu wünschen übrig, aber das wird noch ;D.
Einfach die Gerberdaten packen (zip) und mal bei OSHPark.com (https://oshpark.com) hochladen und anschauen.
Gruß Peter
Zitat von: PeMue am 18 August 2018, 14:18:04
Einfach die Gerberdaten packen (zip) und mal bei OSHPark.com (https://oshpark.com) hochladen und anschauen.
Bei jlcpcb gibt es gerade 10 Platinen für 2 USD + langsamer Versand < 10 $.
Zitat von: PeMue am 18 August 2018, 14:18:04
Einfach die Gerberdaten packen (zip) und mal bei OSHPark.com (https://oshpark.com) hochladen und anschauen.
Ich meinte auch nur zum Prüfen ;), bestellen natürlich bei JLCPCB.
Gruß PeMue
Hallo zusammen,
ich habe festgestellt, dass ich den falschen TSL2561 bei Aliexpress bestellt habe (die kleinere Variante). Daher habe ich beschlossen, den auf die kleinere Variante zu ändern und alternative einen MAX44009 mit draufzupacken (Schaltplan im Anhang). Könnte bitte jemand drüberschauen, ob der MAX44009 so richtig verdrahtet ist?
Danke + Gruß
PeMue
Zitat von: PeMue am 18 August 2018, 15:58:38
Hallo zusammen,
ich habe festgestellt, dass ich den falschen TSL2561 bei Aliexpress bestellt habe (die kleinere Variante). Daher habe ich beschlossen, den auf die kleinere Variante zu ändern und alternative einen MAX44009 mit draufzupacken (Schaltplan im Anhang). Könnte bitte jemand drüberschauen, ob der MAX44009 so richtig verdrahtet ist?
Danke + Gruß
PeMue
Sieht ok aus. Weiß aber nicht was du mit 2*2 beim Gnd pin meinst.
INT Anschluss wird bei allen Treiber-Libs die ich bisher gesehen habe (einschließlich meiner) nicht verwendet, schadet sicher aber auch nicht.
Zitat von: Tom Major am 18 August 2018, 17:34:05
Weiß aber nicht was du mit 2*2 beim Gnd pin meinst.
Ups, scheint ein Fehler in der Bibliothek zu sein. Ich schau's mir an.
Danke + Gruß
PeMue
Zitat von: PeMue am 18 August 2018, 14:18:04
Einfach die Gerberdaten packen (zip) und mal bei OSHPark.com (https://oshpark.com) hochladen und anschauen.
Hallo Peter
sieht gut aus! Vielen Dank und noch ein schönes Wochenende!
Peter
[EDIT]
Ich habe die Files jetzt in Eagle offen; hast Du einen Tip, wie ich damit die Gerber Files erstellen kann? Sonst muss ich Dich ja ggf. für den Innensensor wieder 'nerven'. Ich sehe da 'CAM Prozessor' und 'Generate CAM Data', letzteres scheint aber mehr zu sein, als nur die Gerber Files zu erstellen...
Danke!
[EDIT2]
Ich dachte, ich habe es (https://pic-projekte.de/blog/gerber-dateien-aus-eagle-exportieren/ (https://pic-projekte.de/blog/gerber-dateien-aus-eagle-exportieren/)), allerdings stimmen Anzahl und Dateinamenserweiterungen der erzeugten Files nicht mit Deinen Gerber Files überein...
[Tante EDIT, die 3.]
Bei OSH Park gab es ein CAM File für Eagle, damit klappt das Erstellen der Gerber Files und der Check.
Ich noch einmal...
Da ich ja bald genug Platinen habe - ich überlege mir für einen Innen- und Außensensor die benötigten Sensoren zu ordern. Hier gelesen habe ich, der SHT11 ist alt, der SHT22 mag 'manchmal' nicht, einen SHT31 gibt es wohl auch noch; hm... Ich bin jetzt unschlüssig, was ich verwenden soll.
Was verbaut ihr?
Den SHT31 habe ich hier https://www.aliexpress.com/item/SHT30-SHT31-SHT35-digital-temperature-and-humidity-sensor/32864434777.html (https://www.aliexpress.com/item/SHT30-SHT31-SHT35-digital-temperature-and-humidity-sensor/32864434777.html) gefunden, der ist teurer als ich dachte!
Den BMP180 habe ich hier https://de.aliexpress.com/item/BMP180-Druck-Sensor-4-35-PSI-15-95-PSI-30-kPa-110-kPa-absolute-16-19/32883254438.html (https://de.aliexpress.com/item/BMP180-Druck-Sensor-4-35-PSI-15-95-PSI-30-kPa-110-kPa-absolute-16-19/32883254438.html) gefunden, etwas über 8€ für 20 Stück finde ich günstig.
Helligkeit benötige ich nicht - ich kann hierfür die PV Anlage abgreifen...
Passt der BMP180 und habt ihr eine günstigere Bezugsquelle für den SHT31 (wenn das denn der richtige Temperatur/Feuchte Sensor ist und mit der vorhandenen FW läuft)?
Danke Peter
Zitat von: PSI69 am 21 August 2018, 10:56:15
Ich noch einmal...
Da ich ja bald genug Platinen habe - ich überlege mir für einen Innen- und Außensensor die benötigten Sensoren zu ordern. Hier gelesen habe ich, der SHT11 ist alt, der SHT22 mag 'manchmal' nicht, einen SHT31 gibt es wohl auch noch; hm... Ich bin jetzt unschlüssig, was ich verwenden soll.
Was verbaut ihr?
Ganz aktuell dazu im anderen Thread:
https://forum.fhem.de/index.php/topic,73954.msg828882.html#msg828882 (https://forum.fhem.de/index.php/topic,73954.msg828882.html#msg828882)
Sensorvergleich:
http://www.kandrsmith.org/RJS/Misc/Hygrometers/calib_many.html
Zitat von: PSI69 am 21 August 2018, 10:56:15
Den BMP180 habe ich hier https://de.aliexpress.com/item/BMP180-Druck-Sensor-4-35-PSI-15-95-PSI-30-kPa-110-kPa-absolute-16-19/32883254438.html (https://de.aliexpress.com/item/BMP180-Druck-Sensor-4-35-PSI-15-95-PSI-30-kPa-110-kPa-absolute-16-19/32883254438.html) gefunden, etwas über 8€ für 20 Stück finde ich günstig.
Hast du das notwendige Equipment um den BMP180 so zu verlöten? Ich würde ja eher zu kleinen Breakout-Boards greifen, wenn du keinen Ofen hast.
Zitat von: Tom Major am 21 August 2018, 11:25:22
Ganz aktuell dazu im anderen Thread:
https://forum.fhem.de/index.php/topic,73954.msg828882.html#msg828882 (https://forum.fhem.de/index.php/topic,73954.msg828882.html#msg828882)
Sensorvergleich:
http://www.kandrsmith.org/RJS/Misc/Hygrometers/calib_many.html
OK, stellt sich für mich nur die Frage, welche der Sensoren mit der aktuell vorliegenden Firmware unterstützt werden? Wenn der BME280 'drin' ist, dann versuche ich diesen.
Zitat von: gloob am 21 August 2018, 11:32:18
Hast du das notwendige Equipment um den BMP180 so zu verlöten? Ich würde ja eher zu kleinen Breakout-Boards greifen, wenn du keinen Ofen hast.
Ich hatte gehofft, mit einer feinen Spitze von der Seite arbeiten zu können. Wenn Du meinst - besser nicht - dann nehme ich ein Breakout-Board. Danke für den Hinweis!
Peter
Zitat von: PSI69 am 21 August 2018, 12:53:39
Ich hatte gehofft, mit einer feinen Spitze von der Seite arbeiten zu können. Wenn Du meinst - besser nicht - dann nehme ich ein Breakout-Board. Danke für den Hinweis!
Ich habe es noch nie probiert, aber ich denke, da machst Du mehr Kurzschlüsse zum Gehäuse als vernünftige Verbindungen. Entweder Schablone + Ofen oder
breakout Board.
Gruß Peter
Zitat von: PSI69 am 21 August 2018, 10:56:15
Da ich ja bald genug Platinen habe - ich überlege mir für einen Innen- und Außensensor die benötigten Sensoren zu ordern. Hier gelesen habe ich, der SHT11 ist alt, der SHT22 mag 'manchmal' nicht, einen SHT31 gibt es wohl auch noch; hm... Ich bin jetzt unschlüssig, was ich verwenden soll.
Was verbaut ihr?
Ich habe die hier ....
https://de.aliexpress.com/item/Free-shipping-SHT31-Temperature-SHT31-D-Humidity-Sensor-module-Breakout-Weather-for-Arduino/32700738393.html?spm=a2g0x.search0104.3.56.48257689BoE62H&ws_ab_test=searchweb0_0,searchweb201602_2_10320_10152_10065_10151_10344_10068_10342_10547_10343_10340_10341_10548_10696_10084_10083_10618_10304_5725020_10307_10820_10821_10302_5724920_5724120_10843_5724020_10059_100031_10319_5724320_10103_10624_10623_10622_10621_10620_5724220,searchweb201603_51,ppcSwitch_5&algo_expid=220102d5-24ca-48b7-a770-6ea5f32d07c4-8&algo_pvid=220102d5-24ca-48b7-a770-6ea5f32d07c4&transAbTest=ae803_1&priceBeautifyAB=0
Laufen schon über 1 Jahr in mehreren Sensoren. Mit BME280 hatte ich vermutlich mehrfach Pech. Temperautr immer zu hoch. Habe da 2 im Einsatz, jedoch als Temp-Sensor mit DS18B20. BME nur Humid + Press.
Löten bei SHT31 only, ohne Board wird schwer sein wenn du das Equipment nciht hast.
Zitat von: kadettilac89 am 21 August 2018, 16:21:10
Laufen schon über 1 Jahr in mehreren Sensoren.
Super, Danke! Bestellt...
Peter
Tag zusammen,
@PSI69, du kannst bei Oshpark wie auch bei Aisler einfach das Eagle-brd-File hochladen.
Ich kann anbieten die Platinen fertig bestückt bei uns im Shop zum Verkauf anzubieten. Im Homegear-Umfeld haben wir schon ein wenig mit dem CC1101 gemacht (https://shop.codm.de/module/3/cc1101-raspberry-pi-spi-modul-v0.3)...
Habe die Rev 1.2 der Platinen hier. Bin daran leider ein wenig verzweifelt, vor allem wegem dem fehlenden ISP Header.
Hatte aus Spaß mal an einer eigenen (einfachen) Version gebaut. Wollte die Kompatibilität zum Arduino-Pro-Mini weglassen, also keine Header mehr dafür einbauen. Natürlich den ISP-Header und u.FL-Buchse hinzufügen und eventuell sogar den Arduino-Bootloader flashen, also mit RXD/TXD/DTR Header bauen.
Für die Sensoren wollte ich verschiedene Steckmöglichkeiten für die bekannten Adapterboards vorsehen, primär für den BME280 und keine Sensoren mehr auf die Platine packen. Als CC1101 Modul nehme ich das, was ich sowieso wegen meines CC1101-SPI-Adapter hier habe.
Den MAX1724 wollte ich drauf lassen und noch eine JST-Buchse zum Anschluss von Lithium-Packs hinzufügen. Die Belegung soll wie bei der bekannten Platine bleiben (Softwarekompatibiliät).
Was haltet von der Idee?
Allgemein ist mein Anliegen die Einstiegshürde zu senken und den Leuten die Möglichkeit geben die Platinen bei uns im Shop zu kaufen. Sonst muss man ja Glück haben, dass im Forum noch jemand eine hat.
Gruß,
Patrik
Achso, hier (Anhang) noch mein Schaltplan bist jetzt...
Und, wer Interesse hat, hier die Entwicklung des SPI-CC1101 Adapters:
* https://allgeek.de/2017/09/23/cc1101-spi-adapter-mit-u-fl-antennenbuchse/
* https://forum.homegear.eu/t/cc1101-rpi-spi-adapter/1381
Zitat von: pmayer am 21 August 2018, 22:18:45
Ich kann anbieten die Platinen fertig bestückt bei uns im Shop zum Verkauf anzubieten. Im Homegear-Umfeld haben wir schon ein wenig mit dem CC1101 gemacht (https://shop.codm.de/module/3/cc1101-raspberry-pi-spi-modul-v0.3)...
Habe die Rev 1.2 der Platinen hier. Bin daran leider ein wenig verzweifelt, vor allem wegem dem fehlenden ISP Header.
Ist zwar O.T. aber die lila Adapterplatine ist echt sexy :) ... wie macht ihr das im Homegear? Simuliert ihr da einen CUL mit irgend welcher Software oder wie läuft da die Kommunikation?
SPI im Raspberry kann (theoretisch) 2 Slaves bedienen. Wäre es möglich im Homegear 2 cc1101 direkt übereinander zu stapeln um damit unterschiedliche Protokolle zu bedienen? Es gab ja die Abstimmung.
Danke für die Blumen ;-) Sie ist aber mittlerweile grün, da ich wegen des kürzeren Postwegs bei Aisler bestelle.
Der CC1101 ist softwareseitig komplett in Homegear implementiert für Homematic und Max!. Es funktioniert definitiv beide SPI's zu benutzen, allerdings habe ich dafür keine Platine. Demnächst wird Homegear auf diese Weise auch Zigbee implementieren können... ich muss mir also was Ausdenken, wie man mehr als ein Modul da aufstecken kann. Siehe: https://forum.homegear.eu/t/Zigbee-support/1439/26
Es gibt sogar noch einen weiteren SPI (/dev/spi1.0) hintem an GPIO-Pin 40.
Hallo Patrik,
Zitat von: pmayer am 21 August 2018, 22:21:53
Achso, hier (Anhang) noch mein Schaltplan bis jetzt ...
ich würde noch Tom Majors Lastschaltung für die Strommessung mit aufnehmen, siehe auch den Schaltplan des Außensensors v1.4 weiter oben.
Gruß Peter
Zitat von: pmayer am 21 August 2018, 22:18:45
Ich kann anbieten die Platinen fertig bestückt bei uns im Shop zum Verkauf anzubieten. Im Homegear-Umfeld haben wir schon ein wenig mit dem CC1101 gemacht (https://shop.codm.de/module/3/cc1101-raspberry-pi-spi-modul-v0.3)...
Habe die Rev 1.2 der Platinen hier. Bin daran leider ein wenig verzweifelt, vor allem wegem dem fehlenden ISP Header.
Hatte aus Spaß mal an einer eigenen (einfachen) Version gebaut. Wollte die Kompatibilität zum Arduino-Pro-Mini weglassen, also keine Header mehr dafür einbauen. Natürlich den ISP-Header und u.FL-Buchse hinzufügen und eventuell sogar den Arduino-Bootloader flashen, also mit RXD/TXD/DTR Header bauen.
Für die Sensoren wollte ich verschiedene Steckmöglichkeiten für die bekannten Adapterboards vorsehen, primär für den BME280 und keine Sensoren mehr auf die Platine packen. Als CC1101 Modul nehme ich das, was ich sowieso wegen meines CC1101-SPI-Adapter hier habe.
Den MAX1724 wollte ich drauf lassen und noch eine JST-Buchse zum Anschluss von Lithium-Packs hinzufügen. Die Belegung soll wie bei der bekannten Platine bleiben (Softwarekompatibiliät).
Was haltet von der Idee?
Allgemein ist mein Anliegen die Einstiegshürde zu senken und den Leuten die Möglichkeit geben die Platinen bei uns im Shop zu kaufen. Sonst muss man ja Glück haben, dass im Forum noch jemand eine hat.
Gruß,
Patrik
Hallo Patrick,
Ich habe auch vor, eine Art Funk Universal-Board zu machen, AVR + CC1101 + ISP + SerialProg.-Header + I2C-Header + (Option Max1724) + (Option meine Batt.messung unter Last). Insofern deckt sich das ziemlich und ich finde deine Idee gut das fertig anzubieten.
Header für den Pro Mini finde ich auch ziemlich unnötig wenn man den AVR direkt drauf hat, würde ich weglassen.
Da du einen Shop hast und insofern eine gewisse kommerzielle Komponente im Spiel ist, würde ich natürlich zunächst gern wissen wollen, welchen Preis du dir für die fertig bestückte Platine so vorstellst..
Zitat von: Tom Major am 22 August 2018, 10:59:39
Da du einen Shop hast und insofern eine gewisse kommerzielle Komponente im Spiel ist, würde ich natürlich zunächst gern wissen wollen, welchen Preis du dir für die fertig bestückte Platine so vorstellst..
Hey Tom,
das hier wäre nichts wo ich "das große Geld" mit verdienen will. Die Platinen muss ich in den Stückzahlen die zu erwarten sind sowieso in Handbestückung machen. Damit habe ich mit dem SPI-Adapter bis jetzt gute Erfahrungen gemacht - das ist ja quasi genau so ein Projekt.
Ein Nutzen und entsprechende Richtkosten beim Bestücker würden Preis einfach zu sehr in die Höhe treiben. Man könnte das natürlich angehen, würde aber erst ab ca. 100 Stück Sinn machen.
Die Platine würde ich günstig über Aisler produzieren lassen und dann eben + Bauteile + Bestückungsaufwand.
ATMega328 + CC1101 + Max1724 + passive Bauteile sollten bei ca 8-10€ EK liegen, Platine denke ich bei 3-5€.
Meine Vorstellung wäre um 23-26€ netto, also grob ~28-32€ brutto. Ich bitte zu bedenken, dass wir WEEE registriert sind und auch die Versanverpackung gemäß VerE lizensieren. Wir dürfen also "offiziell" in DE Elektronik verkaufen und müssen da auch eine monatliche Mengenmeldung machen. Was da alles dazu gehört habe ich mal für unsere DMX-Bridge zusammengeschrieben: https://allgeek.de/2018/07/22/professionelle-ethernet-dmx-bridge-udp/
Die CC1101 Module importiere ich zum Beispiel offiziell mit EORI-Nummer und Einfuhrumsatzsteuer aus China.
Der Preis bedingt natürlich, dass wir wirklich nur die verlötete/bestückte (Open-Source-) Hardware anbieten und nicht anfangen können Support für die Software zu machen - die kommt ja eh hier aus dem Forum.
Wir können unsere Designs auch gerne zusammenschmeißen, bzw zusammen dran weiter arbeiten :-)
Ich glaube das Hauptproblem für die Leute ist: Wo bekomme ich einen CC1101 her und wie verlöte ich alles? Zusammenstecken und Software aufspielen sollte man von einem FHEM-Nutzer ja erwarten können ;-)
Zitat von: PeMue am 22 August 2018, 07:59:34
Hallo Patrik,
ich würde noch Tom Majors Lastschaltung für die Strommessung mit aufnehmen, siehe auch den Schaltplan des Außensensors v1.4 weiter oben.
Gruß Peter
Gerne! War bis dato nur von der Rev 1.2 ausgegangen.
Hallo Patrick,
wenn Du die kommerzielle Interessen verfolgst, dann bleibe bitte in Deinem Shop. Es ist zwar schön, dass ...
Zitat von: pmayer am 21 August 2018, 22:18:45
Allgemein ist mein Anliegen die Einstiegshürde zu senken und den Leuten die Möglichkeit geben die Platinen bei uns im Shop zu kaufen. Sonst muss man ja Glück haben, dass im Forum noch jemand eine hat.
Man muss aber nicht gleich alles kommerzialisieren mit WEEE und EORI und Hastdunichtgesehen. Bis jetzt funktioniert es hier auch so, es gibt Platinen, Sammelbestellungen, Löthilfe und auch ab und an Fertiggeräte im Marktplatz und das soll mMn auch so bleiben.
Was Du in Deinem Shop machst, bleibt natürlich Dir überlassen, aber bitte keine Hinweise a la "Jetzt neu bei uns!" hier!
Just my 2 cents.
Zitat von: Horti am 22 August 2018, 17:11:27
Just my 2 cents.
Da lege ich auch noch 2 drauf. - Ich freue mich auch, wenn jemand was schwieriges für mich lötet und zahle ihm gerne den verlangten Aufwand, aber brutto geht schon mal gar nicht.
Ok... ich habe da einen anderen Standpunkt/Information. Jeder der in DE/EU Elektronik verkauft muss für die Entsorgung beim Einbringen in den deutschen Markt zahlen, dafür ist die WEEE-Registrierung. Was privat passiert, ist natürlich auf diesem Wege nicht kontrolierbar. Im schlimmsten Fall kommt aber eben bei mir in der Firma jemand vorbei und will einen Nachweis darüber, dass ich alles abgeführt habe für die Elektronik, die ich verkauft habe.
Es geht mir in keinster Weise darum das zu kommerzialisieren... das EU-Recht sieht es aber eben vor, dass ich das muss wenn ich es offiziell mache.
Versteht mich nicht falsch, ich nehme eure beiden Posts sehr ernst und schätze euer Argument. Ich sehe es aber eben als Vorteil, dass wir diese Dinge (WEEE, VerE, etc.) wegen unserem normalen Geschäft bereits alle erledigt haben und die Forenmitglieder dadurch die Möglichkeit haben die Platinen fertig zu kaufen.
Zitat von: Gernott am 22 August 2018, 18:07:43
Da lege ich auch noch 2 drauf. - Ich freue mich auch, wenn jemand was schwieriges für mich lötet und zahle ihm gerne den verlangten Aufwand, aber brutto geht schon mal gar nicht.
Wie meinst du das? "Brutto" ist alles was du als Privatperson - also inkl. Mehrwertsteuer - kaufst. Netto ist ohne MwSt...
Hallo Patrik,
ich sehe das etwas entspannter als die Kollegen. Wenn jemand die kompletten Module/Sensoren/etc. bei Dir kaufen will, dann ist das für mich ok. Ich weiß aus Erfahrung, was das für ein Aufwand ist:
- Leiterplatten layouten
- Leiterplatten bestellen
- Bauteile bestellen
- Bauteile raussuchen und verlöten und
- dann das Ganze noch irgendwie testen.
Und das ganze geht bei mir zum (aufgerundeten) Selbstkostenpreis. Wenn das jemand professionell übernimmt, würde das bestimmt auch einen Markt haben.
Es wäre jedoch gut, wenn Du Dich dann als "commercial developer" (oder so ähnlich) im Forum registrieren würdest, dann ist klar, dass Du einen (zumindest begrenzten) kommerziellen Hintergrund hast. Meine Meinung bezüglich WEEE Registrierung: Wenn kommerziell, dann richtig.
Gruß Peter
Zitat von: PeMue am 22 August 2018, 19:41:39
ich sehe das etwas entspannter als die Kollegen. Wenn jemand die kompletten Module/Sensoren/etc. bei Dir kaufen will, dann ist das für mich ok. Ich weiß aus Erfahrung, was das für ein Aufwand ist:
- Leiterplatten layouten
- Bauteile bestellen
- Bauteile raussuchen und verlöten und
- dann das Ganze noch irgendwie testen.
Und das ganze geht bei mir zum (aufgerundeten) Selbstkostenpreis. Wenn das jemand professionell übernimmt, würde das bestimmt auch einen Markt haben.
Danke! Das Problem ist ja, dass man zum Selbstkostenpreis für den Selbstbau viele Kostenpunkte gar nicht einplanen kann oder muss. Mir sind als "offizieller" Anbieter genaugenommen die Hände gebunden...
Davon, dass die Chinhändler - auch auf Amazon - genau genommen gar nicht in DE verkaufen dürfen, weil sie eben diese Abgaben eben nicht leisten, fange ich gar nicht erst an ;-)
Zitat von: PeMue am 22 August 2018, 19:41:39
Es wäre jedoch gut, wenn Du Dich dann als "commercial developer" (oder so ähnlich) im Forum registrieren würdest, dann ist klar, dass Du einen (zumindest begrenzten) kommerziellen Hintergrund hast. Meine Meinung bezüglich WEEE Registrierung: Wenn kommerziell, dann richtig.
Mache ich sehr gerne, wie geht das?
Noch mal zur Klarstellung: Mir geht es in keiner Weise darum hiermit die schnelle Mark zu machen. Die Platinen würden genauso als Open-Source, inkl. Files, zur Verfügung gestellt. Mein Antrieb war viel mehr eine einfache Möglichkeit zur Verfügung zu stellen die Platinen zu beziehen. Hatte ja selbst die Erfahrung gemacht, dass man erst mal jemand im Forum finden muss der noch welche hat und dann war die Einstiegshürde recht hoch, wenn man keinen Arduino-Pro-Mini drauf packt.
Auch noch dazu: Freue mich über jeden Post diesbezüglich und es ist völlig ok, wenn hinten bei raus kommt, dass es keinen Bedarf gibt :-)
Hallo Patrik,
Zitat von: pmayer am 22 August 2018, 19:53:43
Mache ich sehr gerne, wie geht das?
siehe hier: https://forum.fhem.de/index.php/topic,60272.msg516360.html#msg516360
Gruß Peter
Hi Patrick,
ich will ja WEEE gar nicht in Frage stellen, ich bin nur der Meinung, dass hier kein Händler mit WEEE-Registrierung und anderen notwendigen Formalitäten benötigt wird. Natürlich soll jeder für seinen Aufwand entsprechend entschädigt werden, aber bis jetzt war das auch ganz gut von privat zu privat möglich. Deswegen mache es wie die NanoCUL-Ebay-Anbieter und Konsorten: versuche Dein Glück, aber lasse das Forum dabei außen vor. Dann wird auch niemand was dagegen haben, wenn Du Dich hier an Diskussionen beteiligst.
Zitat von: Horti am 22 August 2018, 20:14:23
Hi Patrick,
ich will ja WEEE gar nicht in Frage stellen, ich bin nur der Meinung, dass hier kein Händler mit WEEE-Registrierung und anderen notwendigen Formalitäten benötigt wird. Natürlich soll jeder für seinen Aufwand entsprechend entschädigt werden, aber bis jetzt war das auch ganz gut von privat zu privat möglich. Deswegen mache es wie die NanoCUL-Ebay-Anbieter und Konsorten: versuche Dein Glück, aber lasse das Forum dabei außen vor. Dann wird auch niemand was dagegen haben, wenn Du Dich hier an Diskussionen beteiligst.
Danke für den Beitrag. Allerdings glaube ich, dass du etwas falsch verstehst. Du DARFST in Deutschland keine Elektronik verkaufen ohne das Recycling selbiger beim Verkauf bezahlt zu haben. Das regelt in Deutschland das ElektroG, was für alle "Inverkehrbringer" gilt. Du darfst als Firma also gar keine Elektronik verkaufen, wenn du nicht bei der EAR eine WEEE-Registrierung machst.
Gleiches gilt für die Verpackung dieser Elektronik, das regelt das VerpackG vormals VerpackV...
Siehe:
- https://www.buzer.de/gesetz/11738/a194993.htm
- https://verpackungsgesetz-info.de/
Was man privat macht und was "auffällt" steht natürlich auf einem anderen Blatt. Dazu https://www.elektrogesetz.de/hintergruende/faq/ -> Rollen -> "Das wird doch sicher alle nicht so heiß gegessen, wie es gekocht wird. Ich ignoriere das Elektrogesetz erst einmal und registriere mich ggf. später."
Bei meiner Firma kann ich dieses Risiko leider nicht eingehen.
Es ist natürlich völlig ok, wenn ein kommerzieller Hintergrund im Forum nicht gewünscht ist. Hatte hier aber eben anders gelesen: https://forum.fhem.de/index.php/topic,60272.msg516360.html#msg516360 :-)
Zitat von: pmayer am 22 August 2018, 20:25:24
Danke für den Beitrag. Allerdings glaube ich, dass du etwas falsch verstehst. Du DARFST in Deutschland keine Elektronik verkaufen ohne das Recycling selbiger beim Verkauf bezahlt zu haben. Das regelt in Deutschland das ElektroG, was für alle "Inverkehrbringer" gilt. Du darfst als Firma also gar keine Elektronik verkaufen, wenn du nicht bei der EAR eine WEEE-Registrierung machst.
Gleiches gilt für die Verpackung dieser Elektronik, das regelt das VerpackG vormals VerpackV...
Siehe:
- https://www.buzer.de/gesetz/11738/a194993.htm
- https://verpackungsgesetz-info.de/
Was man privat macht und was "auffällt" steht natürlich auf einem anderen Blatt. Dazu https://www.elektrogesetz.de/hintergruende/faq/ -> Rollen -> "Das wird doch sicher alle nicht so heiß gegessen, wie es gekocht wird. Ich ignoriere das Elektrogesetz erst einmal und registriere mich ggf. später."
Das mag alles sein, aber solange hier keine kommerziellen Anbieter am Werk sind, spielt es keine Rolle. Und niemand muss sich bei seinen Preisen damit rechtfertigen. Natürlich nur, solange es in einem gewissen Rahmen bleibt.
Zitat von: pmayer am 22 August 2018, 20:25:24
Es ist natürlich völlig ok, wenn ein kommerzieller Hintergrund im Forum nicht gewünscht ist. Hatte hier aber eben anders gelesen: https://forum.fhem.de/index.php/topic,60272.msg516360.html#msg516360 :-)
Genau ;) :
ZitatInsbesondere ist es Forenteilnehmern nicht erlaubt, eigene kommerzielle Produkte und Dienstleistungen im Forum anzupreisen oder anzubieten, oder solche kommerziellen Produkte und Dienstleistungen im Auftrag Dritter anzupreisen oder anzubieten. Unentgeltliche Hilfestellungen und Diskussionen zu kommerziellen Produkten und Dienstleistungen sind zulässig, soweit diese im Zusammenhang mit FHEM stehen.
Das verdreht zwar völlig meine Absicht aber dann werde ich nicht drauf hinweisen, dass man eine Platine, die eventuell entwickelt wird, bei uns kaufen kann, ok?
ZitatDas mag alles sein, aber solange hier keine kommerziellen Anbieter am Werk sind, spielt es keine Rolle. Und niemand muss sich bei seinen Preisen damit rechtfertigen. Natürlich nur, solange es in einem gewissen Rahmen bleibt.
Das sehe ich nicht so. Das ElektroG spricht explizit von jedem "Inverkehrbringer", das gilt auch für Privatpersonen. Ob das entsprechend verfolgt und/oder geprüft wird, kann ich natürlich nicht beurteilen.
Siehe: https://www.stiftung-ear.de/#q122
ZitatGibt es eine Ausnahme von der Registrierungspflicht für Hersteller, die nur geringe Mengen in Verkehr bringen?
Nein, wenn Sie als Hersteller Elektro- und Elektronikgeräten in Verkehr bringen, müssen Sie sich registrieren lassen. Ausführliche Informationen zum Hersteller und zur Registrierung: https://www.stiftung-ear.de/de/herstellerbevollmaechtigte/registrierung
weiter:
ZitatWas bedeutet Inverkehrbringen im Sinne des ElektroG?
Das Inverkehrbringen ist der späteste Zeitpunkt, zu dem ein Hersteller registriert sein muss. Sie bringen Elektrogeräte dann in Verkehr, wenn Sie sie erstmalig entgeltlich oder unentgeltlich zum Vertrieb, Verbrauch oder zur Verwendung im Rahmen einer Geschäftstätigkeit in Deutschland abgeben.
Ok, ich nehme alles Zurück. Hier steht explizit "Geschäftstätigkeit" - du hast also anscheinend Recht was den "privaten Vertrieb" angeht. Sorry für den Wirbel dann, da habe ich dann zu sehr durch meine "geschäftliche" Brille geguckt. Kann gerade nicht abschätzen ab wann es im privaten Bereich dann "geschäftlich" wird.
Zitat von: pmayer am 22 August 2018, 19:28:41
Wie meinst du das?
Das wird jetzt hier OT, aber ich meine das "politisch". Wir betreiben hier gemeinsam ein Bastelhobby, wo der Spaß im Vordergrund steht und nicht spaßfreies Steuerngenerieren.
Zitat von: pmayer am 22 August 2018, 15:19:58
Hey Tom,
das hier wäre nichts wo ich "das große Geld" mit verdienen will. Die Platinen muss ich in den Stückzahlen die zu erwarten sind sowieso in Handbestückung machen. Damit habe ich mit dem SPI-Adapter bis jetzt gute Erfahrungen gemacht - das ist ja quasi genau so ein Projekt.
Ein Nutzen und entsprechende Richtkosten beim Bestücker würden Preis einfach zu sehr in die Höhe treiben. Man könnte das natürlich angehen, würde aber erst ab ca. 100 Stück Sinn machen.
Die Platine würde ich günstig über Aisler produzieren lassen und dann eben + Bauteile + Bestückungsaufwand.
ATMega328 + CC1101 + Max1724 + passive Bauteile sollten bei ca 8-10€ EK liegen, Platine denke ich bei 3-5€.
Meine Vorstellung wäre um 23-26€ netto, also grob ~28-32€ brutto. Ich bitte zu bedenken, dass wir WEEE registriert sind und auch die Versanverpackung gemäß VerE lizensieren. Wir dürfen also "offiziell" in DE Elektronik verkaufen und müssen da auch eine monatliche Mengenmeldung machen. Was da alles dazu gehört habe ich mal für unsere DMX-Bridge zusammengeschrieben: https://allgeek.de/2018/07/22/professionelle-ethernet-dmx-bridge-udp/
Die CC1101 Module importiere ich zum Beispiel offiziell mit EORI-Nummer und Einfuhrumsatzsteuer aus China.
Der Preis bedingt natürlich, dass wir wirklich nur die verlötete/bestückte (Open-Source-) Hardware anbieten und nicht anfangen können Support für die Software zu machen - die kommt ja eh hier aus dem Forum.
Wir können unsere Designs auch gerne zusammenschmeißen, bzw zusammen dran weiter arbeiten :-)
Ich glaube das Hauptproblem für die Leute ist: Wo bekomme ich einen CC1101 her und wie verlöte ich alles? Zusammenstecken und Software aufspielen sollte man von einem FHEM-Nutzer ja erwarten können ;-)
Hallo Patrick,
ist schon klar dass du damit nicht das große Geld verdienen willst (und kannst ;) ) und du siehst dass solch ein Thema mit kommerziellen Aspekten in einer open source community streng betrachtet wird und ich musste einfach fragen in welche Bereiche der Preis gehen wird..
Ich verstehe deine Zwänge mit den Vorschriften, Gesetzen usw. in DE und EU sehr gut, habe selbst in ähnlichen Bereichen Erfahrungen damit und kann bestätigen das dies gerade bei kleinen Business keinen Spaß macht.
Wenn ich mal bei deiner Schätzung von den 30€ brutto ausgehe ist das m.E. schon eine preisliche Gratwanderung, letztendlich fehlen ja noch Sensoren, Gehäuse usw. und die Konkurrenz ist einerseits ein fertiges HM Gerät und andererseits Module wie z.B. die panStamp, auch nicht billiger, kann aber mehr. Wie gesagt, ich verstehe das du in DE jede Menge Zusatzkosten hat, aber das interessiert einen Käufer oft nicht.
Besser wäre es das Ding komplett in China fertigen zu lassen, dann wäre wahrscheinlich ein Verkaufspreis um die 10-12€ drin und es wäre ein preislich sehr interessantes Teil. Ohne gute China Kontakte sicherlich schwierig zu machen..
Zur Schaltung, ich würde direkt an Vcc vom cc1101 noch einen Abblock-C von 1uF vorsehen. Ist üblich bei Sendemodulen.
Und den Programmierheader Rx/Tx/Dtr um seriell flashen zu können bzw. für Debugausgaben ans Terminal.
Bat.schaltung wurde schon erwähnt.
Layout so klein wie möglich, AVR auf der einen Seite, cc1101 auf der anderen. Je kleiner die Platine um so mehr Einsatzmöglichkeiten.
Zitat von: Tom Major am 23 August 2018, 01:04:29
Hallo Patrick,
ist schon klar dass du damit nicht das große Geld verdienen willst (und kannst ;) ) und du siehst dass solch ein Thema mit kommerziellen Aspekten in einer open source community streng betrachtet wird und ich musste einfach fragen in welche Bereiche der Preis gehen wird..
Ich verstehe deine Zwänge mit den Vorschriften, Gesetzen usw. in DE und EU sehr gut, habe selbst in ähnlichen Bereichen Erfahrungen damit und kann bestätigen das dies gerade bei kleinen Business keinen Spaß macht.
Wenn ich mal bei deiner Schätzung von den 30€ brutto ausgehe ist das m.E. schon eine preisliche Gratwanderung, letztendlich fehlen ja noch Sensoren, Gehäuse usw. und die Konkurrenz ist einerseits ein fertiges HM Gerät und andererseits Module wie z.B. die panStamp, auch nicht billiger, kann aber mehr. Wie gesagt, ich verstehe das du in DE jede Menge Zusatzkosten hat, aber das interessiert einen Käufer oft nicht.
Danke Tom. Ja... das ist leider, wenn man es alles "richtig" machen will, nicht so einfach.
Zitat von: Tom Major am 23 August 2018, 01:04:29
Besser wäre es das Ding komplett in China fertigen zu lassen, dann wäre wahrscheinlich ein Verkaufspreis um die 10-12€ drin und es wäre ein preislich sehr interessantes Teil. Ohne gute China Kontakte sicherlich schwierig zu machen..
Das Problem ist hier glaube eher die Menge. Für 10-20 machen die das in China auch nicht ;-) Da musst du schon ein paar tausend bestellen.
Zitat von: Tom Major am 23 August 2018, 01:04:29
Zur Schaltung, ich würde direkt an Vcc vom cc1101 noch einen Abblock-C von 1uF vorsehen. Ist üblich bei Sendemodulen.
Und den Programmierheader Rx/Tx/Dtr um seriell flashen zu können bzw. für Debugausgaben ans Terminal.
Bat.schaltung wurde schon erwähnt.
Layout so klein wie möglich, AVR auf der einen Seite, cc1101 auf der anderen. Je kleiner die Platine um so mehr Einsatzmöglichkeiten.
Werde ich einbauen 👍 Plan wäre die Entwicklung auf github zu machen, damit jeder an die Dateien kommt und - wenn er möchte - auch Änderungen einfließen lassen kann. Beideseitig würde ich gerne, ist bei Handbestückung und Löten im Ofen aber nicht so einfach realisierbar. Kümmere ich mich aber noch mal drum, was da geht.
Die Platinen würde ich bei Aisler (oder Oshpark) als Projekt hinterlegen. Dann kann jeder sich einfach drei Stück da bestellen und muss nicht hier im Forum jemanden finden der welche hat.
Die Woche gehts aber erst mal in den Urlaub, setze mich wieder drann wenn ich wieder da bin.
Danke nochmal für deine Worte :-)
Hallo,
sind die ganzen Daten und Fakten im ersten Post noch aktuell oder wurde hier was weiterentwickelt? Das git ist nämlich vier Jahre alt.
Was kostet denn der ganze Sensor so im kompletten?
Danke und Gruß
Zitat von: budda85 am 05 September 2018, 10:26:46
... sind die ganzen Daten und Fakten im ersten Post noch aktuell oder wurde hier was weiterentwickelt?
Im wesentlichen ist das noch aktuell, allerdings hat Tom Major mit Hilfe von papa's ASKIN Library die Software weiterentwickelt und ich habe zwei neue Layouts des Außensensors gemacht. Ich weiß nicht, ob Dirk noch fertige Sensoren anbietet, ich kann es aus Zeitgründen nicht.
Gruß PeMue
So, meine ersten beiden Platinen sind grundlegend bestückt (Antenne z. Bsp. fehlt noch...).
Jetzt stellt sich mir so langsam die Frage, wie programmieren. Laut 'CC1101-Sensor_Firmwareupdate_mit_dem_Raspberry_Pi.jpg' im Wiki sind das die 4 linken Pins der unteren Anschlußleiste, die ich mit dem Programmieradapter verbinden muß (in meinem Bild also jeweils die Linke Anschlußleiste und da die oberen 4 PINs)? Laut 'Schematic-RF.pdf' sind das die PINs 9 bis 12 von JP1; stimmt das? Also GND an GND; TXD und RDX jeweils vertauscht verbinden? Was mache ich mit PIN 10, der bei C1 landet?
Danke Peter
Zitat von: PSI69 am 24 September 2018, 12:49:00
So, meine ersten beiden Platinen sind grundlegend bestückt (Antenne z. Bsp. fehlt noch...).
Jetzt stellt sich mir so langsam die Frage, wie programmieren. Laut 'CC1101-Sensor_Firmwareupdate_mit_dem_Raspberry_Pi.jpg' im Wiki sind das die 4 linken Pins der unteren Anschlußleiste, die ich mit dem Programmieradapter verbinden muß (in meinem Bild also jeweils die Linke Anschlußleiste und da die oberen 4 PINs)? Laut 'Schematic-RF.pdf' sind das die PINs 9 bis 12 von JP1; stimmt das? Also GND an GND; TXD und RDX jeweils vertauscht verbinden? Was mache ich mit PIN 10, der bei C1 landet?
Danke Peter
Hast du denn schon einen Bootloader auf den atmega gebrannt?
Zitat von: gloob am 24 September 2018, 13:34:38
Hast du denn schon einen Bootloader auf den atmega gebrannt?
Nein, weder Fuses noch Bootloader.
Peter
ohne bootloader kannst du nicht über das serielle Interface (PINs 9 bis 12) von JP1 flashen..
Du brauchst erst mal einen bootloader im device, den du über 6 pins (ISP: 3xSPI, Vcc, Gnd, Rst) flashen musst.
Zitat von: Tom Major am 24 September 2018, 16:50:23
ohne bootloader kannst du nicht über das serielle Interface (PINs 9 bis 12) von JP1 flashen..
Du brauchst erst mal einen bootloader im device, den du über 6 pins (ISP: 3xSPI, Vcc, Gnd, Rst) flashen musst.
Den Bootloader bekommt man nur drauf, bevor das Funkmodul aufgelötet wurde, da es an denselben Pins hängt. Zumindest habe ich es bisher immer so gemacht.
Zitat von: Gernott am 24 September 2018, 17:17:47
Den Bootloader bekommt man nur drauf, bevor das Funkmodul aufgelötet wurde, da es an denselben Pins hängt. Zumindest habe ich es bisher immer so gemacht.
Sollte m.E. auch mit dem Funkmodul gehen, ich meine ich hätte das damals so gemacht (ist aber ein paar Jahre her ;)).
Gruß PeMue
Zitat von: Gernott am 24 September 2018, 17:17:47
Den Bootloader bekommt man nur drauf, bevor das Funkmodul aufgelötet wurde, da es an denselben Pins hängt. Zumindest habe ich es bisher immer so gemacht.
Solange das Funkmodul am Chip Select pin (CSN -> Arduino D10) High Pegel hat ist alles save, jeder SPI chip ist dann per Definition passiv. Also z.B. einen 10k von D10 nach +3,3V während des Flashes über ISP, dann ist man auf der sicheren Seite.
p.s. Gute Designs haben einen solchen pull-up Widerstand standardmässig in der Schaltung drin wenn die SPI mehrfach verwendet wird.
Zitat von: Tom Major am 24 September 2018, 17:27:50
Gute Designs haben einen solchen pull-up Widerstand standardmässig in der Schaltung drin wenn die SPI mehrfach verwendet wird.
Auf der abgebildeten Außensensorplatine ist dieser Widerstand nicht vorgesehen (ohne Wertung), muß also temporär angehängt werden.
Danke! Ich versuche mal zusammen zu fassen, was ich mitbekommen habe:
- 10k von D10 nach +3,3V; also JP2/12; während des Flashvorganges
- bootloader über 6 pins (ISP: 3xSPI, Vcc, Gnd, Rst) flashen
OK, laut http://www.holgerschurig.de/de/raspi-atmega/ (http://www.holgerschurig.de/de/raspi-atmega/) muss
- GPIO25 nach RESET - JP2/3?
- GPIO10/SPI0_MOSI nach D11/MOSI - JP2/11?
- GPIO9/SPI0_MISO nach D12/MISO - JP2/10?
- GPIO11/SPI_CLK nach D13/SCK - JP2/9?
- 3,3V an VCC - JP2/4?
- GND an GND - JP2/2?
Laut hier https://www.elektronik-kompendium.de/sites/raspberry-pi/1907101.htm (https://www.elektronik-kompendium.de/sites/raspberry-pi/1907101.htm) bekomme ich die 3,3V von Anschluss 1 bzw. 17 am PI, reichen die 50mA zum flashen?
Passt das und muss ich als 'Ersttäter' noch etwas beachten?
Peter
Zitat von: PSI69 am 24 September 2018, 18:13:04
Danke! Ich versuche mal zusammen zu fassen, was ich mitbekommen habe:
- 10k von D10 nach +3,3V; also JP2/12; während des Flashvorganges
- bootloader über 6 pins (ISP: 3xSPI, Vcc, Gnd, Rst) flashen
Dieser Teil klingt def. ok.
Zum Flashen über RPi kann ich nichts sagen da noch nie gemacht, Schaltung sieht aber ok aus.
Wenn du noch nie einen AVR geflasht hast würde ich eher auf einen der zahlreichen USB Programmer zurückgreifen, USBasp usw.
imho ist das der Standard, Flashen über die SPI eines RPi ein eher etwas unüblicherer Weg..
Ich würde annehmen das 50mA fürs Flashen reichen, finde auf den ersten Blick keine Angabe dazu im datasheet.
P.S. Du kannst auch mit einem Arduino Uno usw. einen anderen AVR flashen, Anleitungen dazu gibt es viele im Netz.
Zitathttps://www.arduino.cc/en/Tutorial/ArduinoToBreadboard
Zitat von: Tom Major am 24 September 2018, 22:31:29
Dieser Teil klingt def. ok.
Zum Flashen über RPi kann ich nichts sagen da noch nie gemacht, Schaltung sieht aber ok aus.
Wenn du noch nie einen AVR geflasht hast würde ich eher auf einen der zahlreichen USB Programmer zurückgreifen, USBasp usw.
imho ist das der Standard, Flashen über die SPI eines RPi ein eher etwas unüblicherer Weg..
Ich würde annehmen das 50mA fürs Flashen reichen, finde auf den ersten Blick keine Angabe dazu im datasheet.
P.S. Du kannst auch mit einem Arduino Uno usw. einen anderen AVR flashen, Anleitungen dazu gibt es viele im Netz.
OK, ein flashen über USB ist mir lieber, ich hatte mir dazu den hier https://www.amazon.de/dp/B0757FQ5CX/ref=pe_3044161_185740101_TE_item (https://www.amazon.de/dp/B0757FQ5CX/ref=pe_3044161_185740101_TE_item) besorgt, aber nicht beachtet, dass mir dieser Weg (seriell) ohne Bootloader noch nicht offen steht. Ich habe mir für den Bootloader nun noch einen USBasp Programmer bestellt - so lange hat das jetzt halt noch Zeit.
Peter
Zitat von: kadettilac89 am 21 August 2018, 16:21:10
Ich habe die hier ....
https://de.aliexpress.com/item/Free-shipping-SHT31-Temperature-SHT31-D-Humidity-Sensor-module-Breakout-Weather-for-Arduino/32700738393.html?spm=a2g0x.search0104.3.56.48257689BoE62H&ws_ab_test=searchweb0_0,searchweb201602_2_10320_10152_10065_10151_10344_10068_10342_10547_10343_10340_10341_10548_10696_10084_10083_10618_10304_5725020_10307_10820_10821_10302_5724920_5724120_10843_5724020_10059_100031_10319_5724320_10103_10624_10623_10622_10621_10620_5724220,searchweb201603_51,ppcSwitch_5&algo_expid=220102d5-24ca-48b7-a770-6ea5f32d07c4-8&algo_pvid=220102d5-24ca-48b7-a770-6ea5f32d07c4&transAbTest=ae803_1&priceBeautifyAB=0
Laufen schon über 1 Jahr in mehreren Sensoren. Mit BME280 hatte ich vermutlich mehrfach Pech. Temperautr immer zu hoch. Habe da 2 im Einsatz, jedoch als Temp-Sensor mit DS18B20. BME nur Humid + Press.
Löten bei SHT31 only, ohne Board wird schwer sein wenn du das Equipment nciht hast.
Mal dazu eine Frage: Läuft der SHT31 auf der Universalsensorplatine auch mit der Standard-Firmware von Dirk, in der ja original der SHT10 eingesetzt ist?
Gruß
G.
Zitat von: Gernott am 03 Oktober 2018, 14:36:04
Mal dazu eine Frage: Läuft der SHT31 auf der Universalsensorplatine auch mit der Standard-Firmware von Dirk, in der ja original der SHT10 eingesetzt ist?
Gruß
G.
Nein. SHT31 "spricht" I2C nativ. Die SHT1x haben ein eigenes Protokoll, wenn ich mich recht erinnere.
Ich habe eine geforkte sensirion-Library gefunden, die wohl auch den SHT31 anspricht:
https://github.com/HydroSense/sensirion/blob/master/sensirion.h
Kann man die als direkten Ersatz verwenden und welche Modifikationen am Code wären dann noch notwendig?
Danke & Gruß
G.
Zitat von: Gernott am 03 Oktober 2018, 15:34:26
Ich habe eine geforkte sensirion-Library gefunden, die wohl auch den SHT31 anspricht:
https://github.com/HydroSense/sensirion/blob/master/sensirion.h
Kann man die als direkten Ersatz verwenden und welche Modifikationen am Code wären dann noch notwendig?
Danke & Gruß
G.
In meinem UniSensor Beispiel ist die Einbindung diverser Sensoren demonstriert
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1)
Dort habe ich gerade letztens den SHT10 für kpwg eingebunden.
Du könntest dort einen "einfachen" I2C Sensor wie Sensors/BME280 hernehmen und den versuchen auf SHT31 umzuschreiben.
Bei deinem link der geforkte sensirion-Lib wundert mich nur dass dort "Bit-Banging" statt der Arduino Wire Lib für die I2C Kommunikation verwendet wird, erscheint mir merkwürdig, habe aber nur ganz kurz einen Blick reingeworfen..
Die funktioniert auf jeden Fall, ich habe diese schon in anderen Projekten verwendet.
https://github.com/adafruit/Adafruit_SHT31
Die sieht auch besser aus, benutzt Arduino Wire Lib für I2C.
Hallo Dirk, mein Universalsensor hat nach 4 Jahren den Geist aufgegeben. Hast du zufällig noch einen vorrätig?
Danke und Gruß
Patrick
Was heißt den Geist aufgegeben ?
Zitat von: cactus-online am 21 Oktober 2018, 17:11:48
Was heißt den Geist aufgegeben ?
Der Temperatur Sensor liefert keine Daten mehr. Ist immer bei 0.
Zitat von: P.A.Trick am 21 Oktober 2018, 17:15:17
Der Temperatur Sensor liefert keine Daten mehr. Ist immer bei 0.
Batterie leer?
Zitat von: gloob am 21 Oktober 2018, 18:00:03
Batterie leer?
Nein die habe ich eben gewechselt. Wie gesagt alles geht, außer Temp. Ich denke die Korrosion hat ihm zugesetzt.
Das erinnert stark an den KS200/KS300. Auch da setzt die Korrosion dem Sensor bzw. dem I²C Bus dorthin erheblich zu. Eventuell reicht es, den SHT10 zu wechseln. Mittlerweile sind die für unter drei Euro vom Chinamann erhältlich.
Zitat von: P.A.Trick am 21 Oktober 2018, 18:01:27
Nein die habe ich eben gewechselt. Wie gesagt alles geht, außer Temp. Ich denke die Korrosion hat ihm zugesetzt.
Du hast dort einen SHT10 drauf, der noch Luftfeuchtigkeits-Werte liefert aber keine Temperatur?
Oder um welche Sensoren handelt es sich?
Genau das selbe Problem habe ich seit kurzem ebenfalls:
rssi_at_HM1 cnt:25362 min:-105 max:-77 avg:-92.15 lst:-81
rssi_at_HM2 cnt:25171 min:-80 max:-68 avg:-73.01 lst:-68
READINGS:
2018-10-31 12:24:36 Activity alive
2018-10-31 12:24:36 D-firmware 0.14
2018-10-31 12:24:36 D-serialNr UWS2764646
2018-10-31 12:26:50 batVoltage 3.20
2018-10-31 12:26:50 battery ok
2018-10-31 12:26:50 luminosity 321
2018-10-31 12:26:50 state T: 0.0 L: 321
2018-10-31 12:26:50 temperature 0.0
Hab soeben noch frische Batterien reingegeben.....Selbes verhalten.
lg, Stefan
Ich habe Anfang Oktober Dirks Sensor einem kleinem Redesign unterzogen und bei JLCPCB bestellt.
Mittlerweile sind die Boards da und ich habe das erste erfolgreich aufgebaut.
Hier eine kurze Vorstellung des Projekts:
Features
- Bestückung mit Arduino Pro Mini oder alternativ mit ATmega328P
- RC- oder Quarzoszillator möglich
- Sensoren für Temperatur (DS18x20, BME280), Luftdruck/Luftfeuchte (BME280), Helligkeit (MAX44009) bestückbar
- diese Sensoren können als SMD mit Reflow oder Heisßluft gelötet oder auf Breakout-Boards an den zwei I2C Stiftleisten angeschlossen werden
- andere I2C Sensoren über Breakout-Boards anschliessbar
- Spannungsversorgung: Batterien 2 Zellen / Batterie 1 Zelle mit MAX1724 / Netzteil
Mein Changelog für Ver 2.01
- MAX44009 hinzugefügt
- BMP180 entfernt (Ersatz durch BME280)
- TSL2561 entfernt (Ersatz durch MAX44009) warum? https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SensorTest_Lux
- Zweite I2C Stiftleiste für zusätzliche Sensoren auf Breakout-Boards
- meine Schaltung für echte Batteriespannungsmessung unter Last hinzugefügt
- 10k pull-up Widerstand am ChipSelect des CC1101 für sicheres ISP-Flashen (Bootloader) mit verbautem CC1101
- Miniatur-Quarz 8MHz optional bestückbar (anstatt int. RC-Osc.)
- alle Abstände der Leiterbahnen gegeneinander auf min. 0,25mm vergrößert
- Layout entflochten und verbessert
- Lötpads für BME280 und MAX44009 nach außen verlängert falls man versuchen will diese ohne Reflow oder Heisßluft zu löten
Software
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1)
Schaltung
https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT/Files/SensorPLHT_v201.pdf (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT/Files/SensorPLHT_v201.pdf)
An dieser Stelle Danke :)
an papa für seine geniale AskSinPP Lib,
an jp112sdl für Austausch und Teilhaben an seinem großen Inside-HomeMatic Know-How,
an PeMue für Austausch und Anregungen zum Layout und Projekt,
und an kpwg für die FHEM Tests und die zur Verfügung gestellte HW.
- Jeder von Euch vier kann gern 2 Platinen aus meiner ersten Charge haben wenn ihr das wollt und mir eine PM sendet. -
Eine Sammelbestellung kann ich momentan aus Zeitgründen nicht organisieren, würde aber natürlich mit Infos unterstützen falls das jemand machen will und Fragen aufkommen.
Der Wahnsinn, ich habe mit diesem Projekt meine erste JLCPCB Bestellung gemacht, 10 Platinen für knapp 8 Euro, wobei die Platinen selbst nur 2 Euro kosten.
Hat von Bestellung bis Lieferung 17 Tage gedauert. Qualität ist gut, es gibt nichts zu meckern.
Habe die letzten Jahre einige Platinen pro Jahr beruflich und privat immer in DE bestellt, unter 35-45 Euro für kleinste Abmessungen kam man da nie, für etwas größere Boards auch gerne mal 80-100 Euro.
Insofern passen die JLCPCB Platinen preislich sehr gut zu den restlichen Bauteilen von Ali ;)
Grüße Tom
Hallo Tom,
Sieht sehr gut aus, Kompliment
Würdest Du evtl die Dateien zur Verfügung stellen, um die Platinen in China zu bestellen?
Hast Du sogar evtl einen direkten Link von JLCPCB?
Früher gabs sowas, man konnte direkt Deine Bestellung nochmal anfordern, Dir wurde dann was gut geschrieben
Viele Grüße
Klaus
Zitat von: Klaus0815 am 03 November 2018, 16:25:07
Würdest Du evtl die Dateien zur Verfügung stellen, um die Platinen in China zu bestellen?
Hallo Klaus,
hat er doch: https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT/Gerber (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT/Gerber)
Nur noch zippen und beim Platinenhersteller wieder hochladen.
EDIT: Ich würde da sogar noch einen Schritt weiter gehen und einen Nutzen erstellen.
Zitat
Hast Du sogar evtl einen direkten Link von JLCPCB?
Früher gabs sowas, man konnte direkt Deine Bestellung nochmal anfordern, Dir wurde dann was gut geschrieben
Sowas gab es? Das würde ich auch begrüßen.
Zitat von: Klaus0815 am 03 November 2018, 16:25:07
Hallo Tom,
Sieht sehr gut aus, Kompliment
Würdest Du evtl die Dateien zur Verfügung stellen, um die Platinen in China zu bestellen?
Hast Du sogar evtl einen direkten Link von JLCPCB?
Früher gabs sowas, man konnte direkt Deine Bestellung nochmal anfordern, Dir wurde dann was gut geschrieben
Viele Grüße
Klaus
Genau wie kpwg schreibt, die Gerber Dateien auf github verwenden und hochladen. Es sind genau die die ich bei der Bestellung verwendet habe.
Schaue morgen noch mal ob es bei JLCPCB einen direkten link gibt.
Hallo Tom,
Zitat von: Tom Major am 03 November 2018, 12:48:53
- Lötpads für BME280 und MAX44009 nach außen verlängert falls man versuchen will diese ohne Reflow oder Heißluft zu löten
da bin ich mal gespannt, ob das funktioniert.
Zitat von: Tom Major am 03 November 2018, 12:48:53
An dieser Stelle Danke :)
an papa für seine geniale AskSinPP Lib,
an jp112sdl für Austausch und Teilhaben an seinem großen Inside-HomeMatic Know-How,
an PeMue für Austausch und Anregungen zum Layout und Projekt,
und an kpwg für die FHEM Tests und die zur Verfügung gestellte HW.
es war mir ein Vergnügen, obwohl wir im Bezug auf das Layoutprogramm nicht kompatibel sind bzw. vermutlich auch nie sein werden ;). Aber ein Teil Deiner Anregungen sind auch bei mir mit eingeflossen. Das vier Augen Prinzip hilft ;) (oder: nutze die Intelligenz des Teams). Dir auch herzlichen Dank dafür.
Zitat von: Tom Major am 03 November 2018, 12:48:53
Software
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1)
... würde aber natürlich mit Infos unterstützen falls das jemand machen will und Fragen aufkommen.
Bezüglich Software ist bei mir auf jeden Fall Unterstützung nötig, mal sehen wie weit ich selber komme, aber dann melde ich mich.
Gruß Peter
Nabend,
ich würde gerne mal eine Frage hier einstreuen. Ich bin mir nicht ganz sicher, ob dies der richtige Thread ist, da hier hauptsächlich Hardware diskutiert wird, aber vielleicht kann ja dennoch jemand helfen?
Unzwar habe ich das Problem, dass nach dem hinzufügen der .pm in den /opt/fhem/FHEM Ordner ich kein Model HM-Unisensor finde.
Wie muss ich denn genau die Konfiguration vornehmen?
EDIT ab hier:
Ich habe mit dem Verkäufer nun das Problem ausgemacht.
Der FHEM-Log sagt:
2018.11.09 20:18:40 3: additional HM config file loaded: ./FHEM/HMConfig_SenTHPL.pm
2018.11.09 20:18:40 1: Error loading file: ./FHEM/HMConfig_UniSensor1.pm:
Excessively long <> operator at ./FHEM/HMConfig_UniSensor1.pm line 21, <$fh> line 31.
2018.11.09 20:18:56 3: nanoCUL: Unknown code A0FFB8610613D910000000A24D50D0040::-40.5:nanoCUL, help me!
Danach habe ich mir die betreffende .pm angeschaut, konnte aber kein Fehler ausmachen.
Soweit der stand der Dinge. Ansonsten, so der nette Herr, wäre wohl alles vorerst korrekt.
EDIT2:
Auf meiner Hauptinstanz wird nicht mal mehr das Model, welches es auszuwählen gilt, angezeigt.
Auch taucht im FHEM-Log nicht mal mehr der vorige Fehler auf. Ich heillos überfordert.
Liebe Grüße,
Max :)
Hi,
die Unisensor Hardware ist diese hier:
(https://uploads.tapatalk-cdn.com/20181109/7d4320ae2b7eda590288d5dcc1725650.jpg)
Wenn natürlich das FHEM Modul mit den Definitionen der HM Nachrichten nicht richtig geladen wird, dann kann auch keine Nachricht entschlüsselt werden und der Channel 1 mit den Messwerten wird nicht im Device angelegt.
Zeigst Du noch ein list des Devices?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Krass, ich habe Deine Fehlermeldung ,,excessive..." gerade mal gesucht und das hier https://forum.fhem.de/index.php/topic,62570.msg614848.html#msg614848
Demnach sollten wir die HM*.pm Dateien nicht per wget holen :-(
Also probiere mal die Dateien aus der Zipdatei zu nehmen.
https://github.com/TomMajor/AskSinPP_Examples/archive/master.zip
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hmm, normalerweise sollte für FHEM reichen was ich im readme geschrieben habe:
ZitatDie Datei FHEM/HMConfig_UniSensor1.pm nach /opt/fhem/FHEM kopieren, dann FHEM neustarten.
Falls Arnd auf der richtigen Fährte ist, dann wäre mal ein Diff zwischen der Problem HMConfig_UniSensor1.pm im FHEM Ordner und der direkt per Browser runtergeladenen Variante interessant.
Hi,
Probiere doch mal diese Dateien:
https://forum.fhem.de/index.php?action=dlattach;topic=93045.0;attach=108470 die bei gloob funktionieren!
Als Model sollte dann HB-GEN-SENS sein.
Edit: Kann bestätigen, dass die Dateien bei mir auch laufen und ich das Model auswählen kann ;-)
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Moin,
ich habe Neues zu berichten.
Ich habe auf der Hauptinstanz nun es geschafft, über den Befehl im Wiki die SenTHPL.pm einzubinden (über FHEM-Konsole).
Danach habe ich über die Zip, welche ich per wget geholt habe, die UniSensor1.pm in das /opt/fhem/FHEM Verzeichnis verschoben. Per chown es möglich gemacht, FHEM zuzugreifen.
Nun ist alles so wie es soll.
Auch zeigt der FHEM-Log keine Fehler mehr an.
Dies ist die Raw-Config:
defmod HM_444005 CUL_HM 444005
attr HM_444005 DbLogExclude .*
attr HM_444005 IODev nanoCUL
attr HM_444005 IOgrp VCCU:nanoCUL
attr HM_444005 actCycle 000:10
attr HM_444005 actStatus alive
attr HM_444005 autoReadReg 4_reqStatus
attr HM_444005 expert 2_raw
attr HM_444005 firmware 0.2
attr HM_444005 model HB-UW-Sen-THPL-O
attr HM_444005 peerIDs 00000000,
attr HM_444005 room CUL_HM
attr HM_444005 serialNr FHEM444005
attr HM_444005 subType THPLSensor
setstate HM_444005 2018-11-10 14:15:42 .D-devInfo 010000
setstate HM_444005 2018-11-10 14:15:42 .D-stc 41
setstate HM_444005 2018-11-10 14:15:42 .peerListRDate 2018-11-10 14:15:42
setstate HM_444005 2018-11-10 14:15:59 .protLastRcv 2018-11-10 14:15:59
setstate HM_444005 2018-11-10 14:18:14 Activity alive
setstate HM_444005 2018-11-10 13:42:15 CommandAccepted yes
setstate HM_444005 2018-11-10 14:15:42 D-firmware 0.2
setstate HM_444005 2018-11-10 14:15:42 D-serialNr FHEM444005
setstate HM_444005 2018-11-10 14:15:42 PairedTo 0x310597
setstate HM_444005 2018-11-10 13:42:19 R-pairCentral 0x310597
setstate HM_444005 2018-11-10 14:15:42 RegL_00. 0A:31 0B:05 0C:97 00:00
Sprich ich kann nun auch als Model: den Unisensor, den THPL-O oder I auswählen und als subtpe sowohl THPL als auch Unisensor.
Nur die richtigen Werte mag er mir wirklich nicht ausspucken.
Aber ja, ein Fehler war es, die eine .pm per wget zu holen. Danke Arnd für den Tipp.
@RaspiLED Die Zip schaue ich mir sofort an, wenn ich Gelegenheit dazu habe.
Grüße, Max :)
Ich schon wieder,
ich habe die .pm's erfolgreich eingefügt, die aus der .zip von Arnd stammen. Danke dafür!
Alles soweit okay, er wird sogar das Model richtig gesetzt, subtype auf custom. Stimmt der subtype oder sollte der lieber auf THLP-Sensor?
Nun muckt aber nicht mehr der CUL auf, sondern es werden valueFormat's verlangt. Ein kurzer Blick ins wiki half mir jedoch nicht so recht weiter.
Ich werde noch etwas mich umschauen, falls jedoch jemand ein Tipp hat, ich wäre euch sehr dankbar.
2018.11.10 20:05:01 1: Missing attribute valuesformat at HM_444005_Values
2018.11.10 20:05:46 2: CUL_HM Unknown device HM_444003 is now defined
2018.11.10 20:05:46 2: autocreate: define HM_444003 CUL_HM 444003
2018.11.10 20:05:46 2: autocreate: define FileLog_HM_444003 FileLog ./log/HM_444003-%Y.log HM_444003
2018.11.10 20:06:22 1: Missing attribute valuesformat at HM_444003_Values
2018.11.10 20:06:22 0: CUL_HM_assignIO HM_444003 AssignIoPort used
2018.11.10 20:08:15 1: Missing attribute valuesformat at HM_444005_Values
2018.11.10 20:11:29 1: Missing attribute valuesformat at HM_444005_Values
Die HM_444003 spuckte keinen Fehler aus, da der subtype zum testen auf THLP-Sensor gesetzt war. Jedoch gab es hierbei keine Readings, die auf Lufttfeuchtigkeit/temperatur oder Druck hinweisen würden.
Grüße, Max.
Hi,
Hilft das:
attr HM_xxxxxx_Values userattr valuesformat
attr HM_xxxxxx_Values valuesformat 2s:temperature:10 1:humidity 1:batVoltage:10
Quelle:
https://forum.fhem.de/index.php/topic,90300.msg827464.html#msg827464
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Hallo zusammen,
Zitat von: Tom Major am 03 November 2018, 12:48:53
Mein Changelog für Ver 2.01
- MAX44009 hinzugefügt
- BMP180 entfernt (Ersatz durch BME280)
- TSL2561 entfernt (Ersatz durch MAX44009) warum? https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SensorTest_Lux
- zweite I2C Stiftleiste für zusätzliche Sensoren auf Breakout-Boards
- meine Schaltung für echte Batteriespannungsmessung unter Last hinzugefügt
- 10k pull-up Widerstand am ChipSelect des CC1101 für sicheres ISP-Flashen (Bootloader) mit verbautem CC1101
- Miniatur-Quarz 8MHz optional bestückbar (anstatt int. RC-Osc.)
- alle Abstände der Leiterbahnen gegeneinander auf min. 0,25mm vergrößert
- Layout entflochten und verbessert
- Lötpads für BME280 und MAX44009 nach außen verlängert falls man versuchen will diese ohne Reflow oder Heisßluft zu löten
und so sieht das Ganze dann mit verlöteten Bauteilen aus (BME280 per Schablone und Reflow, MAX44009 auf der oberen Platine unter dem Mikroskop per Hand, da die Schablone nicht gepasst hat ???). Das Löten des MAX44009 ist eine ziemliche Fummelei, geht aber schlußendlich dann doch einigermaßen.
Tests folgen, aber Durchmessen mittels Ohmmeter zeigt, dass alle Pins angeschlossen sein sollten und die Sensoren funktionieren sollten.
Gruß PeMue
Gute Arbeit 8), bin gespannt ob beide aufgelötete Sensoren funktionieren.
Zitat von: Tom Major am 23 November 2018, 12:26:31
Gute Arbeit 8), bin gespannt ob beide aufgelötete Sensoren funktionieren.
Ich hab die Sachen auch noch auf meiner Todo Liste, warte derzeit noch auf die Atmegas und schlechteres Wetter ;-)
Zitat von: Tom Major am 23 November 2018, 12:26:31
Gute Arbeit 8), bin gespannt ob beide aufgelötete Sensoren funktionieren.
Und hier kommt die Auflösung:
Sie funktionieren (siehe Bilder im Anhang).Leider gibt es keine vorcompilierte ESPEasy Version, die den MAX44009 bedient, aber ich denke, wenn der Baustein unter der Adresse 0x4A gefunden wird, dann sollte der Rest auch funktionieren.
Gruß PeMue
Das klingt gut, denke auch dass wenn Du die I2C Adresse 4A auf dem Bus siehst alles mit dem Löten geklappt hat 8)
Hallo zusammen,
hier mal eine laienhafte Frage eines Hardwerkers zur Software (wenn es hier nicht passt, verschiebe ich das gerne in die AskSin Ecke):
Ich beziehe mich auf diese Darstellung:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 Option 2 und 3.
Warum ist eine gesonderte Programmierung in der Software notwendig? Die Ansteuerung ist doch identisch.
Ich vermute, das hängt mit der Zeit zwischen den Messungen (immer zusammen mit dem Messwert bei Option 2, nur 2x am Tag bei Option 3 wegen Messung unter Last) zusammen.
Gibt es irgendwo ein Beispiel, wo alle drei Optionen per #include parametrierbar sind?
Zwei habe ich schon gefunden:
#ifdef INTERNAL_VOLTAGE_MEASUREMENT
typedef BatterySensor BatteryType;
#else
typedef BatterySensorUni<5, 6> BatteryType;
#endif
oder auch entsprechend mit der Definition der beiden Pins BAT_SENS_PIN bzw. BAT_EN_PIN.
Als dritten Parameter hätte ich dann noch LOAD_VOLTAGE_MEASUREMENT als false/true genommen.
Danke + Gruß
Peter
Zitat von: PeMue am 25 November 2018, 18:42:29
Ich beziehe mich auf diese Darstellung:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 Option 2 und 3.
Warum ist eine gesonderte Programmierung in der Software notwendig? Die Ansteuerung ist doch identisch.
Gibt es irgendwo ein Beispiel, wo alle drei Optionen per #include parametrierbar sind?
Danke + Gruß
Peter
Hallo Peter,
nein, die Ansteuerung ist bei Option 2) und 3) nicht identisch. Bei 2) wird mit Low an D9 die Messung aktiviert, bei 3) mit High um den N-Kanal Mosfet durchzuschalten. (R4 dort ist ein Safety (Angst-Widerstand) falls durch Fehler irgendeiner Art der Port auf input bleibt, wir wollen dann keinen Laststrom ;) )
Weiterhin möchte ich bei 3) z.B. für 200ms warten bevor ich messe wegen der Belastung, dass ist bei 2) nicht nötig.
Ich kann gerne bei Gelegenheit alle 3 Optionen per #include parametrierbar machen. Vorher stehen noch ein paar Langzeittests mit Option 3) an, danach mache ich das.
Zitat von: Tom Major am 26 November 2018, 00:13:47
Ich kann gerne bei Gelegenheit alle 3 Optionen per #include parametrierbar machen. Vorher stehen noch ein paar Langzeittests mit Option 3) an, danach mache ich das.
Wir können das dann als extra Klasse in die Lib einbauen.
Hallo Tom,
Zitat von: Tom Major am 26 November 2018, 00:13:47
nein, die Ansteuerung ist bei Option 2) und 3) nicht identisch. Bei 2) wird mit Low an D9 die Messung aktiviert, bei 3) mit High um den N-Kanal Mosfet durchzuschalten. (R4 dort ist ein Safety (Angst-Widerstand) falls durch Fehler irgendeiner Art der Port auf input bleibt, wir wollen dann keinen Laststrom ;) )
Weiterhin möchte ich bei 3) z.B. für 200ms warten bevor ich messe wegen der Belastung, dass ist bei 2) nicht nötig.
ups, Denkfehler meinerseits. Der Transistor invertiert die Logik ja. Danke für die Klarstellung.
Zitat von: Tom Major am 26 November 2018, 00:13:47
Ich kann gerne bei Gelegenheit alle 3 Optionen per #include parametrierbar machen. Vorher stehen noch ein paar Langzeittests mit Option 3) an, danach mache ich das.
Das wäre echt klasse. Auf jeden Fall habe ich schon mal Option 1 und 2 in der Software drin und sie wird auch fehlerfrei kompiliert.
Zitat von: papa am 26 November 2018, 06:59:46
Wir können das dann als extra Klasse in die Lib einbauen.
Wenn das dann auch ein Hardwerker versteht, wäre das klasse.
Danke + Gruß
Peter
Zitat von: papa am 26 November 2018, 06:59:46
Wir können das dann als extra Klasse in die Lib einbauen.
ich kann gern einen PR der Batt. Klasse für Option 3 machen, brauche aber noch ein paar Tage bis ich dazu komme und für Tests.
Guten Morgen,
Ich habe die HB-UNI-Sensor1.ino in die Arduino Software geladen (benötigte Libraries ergänzt) und kompiliert. Alles gut soweit. Ich hab dann fürs flashen in Arduino die Binärdatei exportiert, damit ich die FW als hex file zum flashen mit avrdude habe.
Herauskommen sind 2 Files:
HB-UNI-Sensor1.ino.standard.hex
HB-UNI-Sensor1.ino.with_bootloader.standard.hex
Früher war es so, das ich erst mit makeota einen Bootloader gebaut und geflashed habe und dann OTA die FW draufspielen konnte. Oder gleich mit makeota die FW inkl OTA Bootloader geflashed.
Gehe ich richtig in der Annahme, dass die zweite FW den OTA Bootloader schon enthält? Also einfach HB-UNI-Sensor1.ino.with_bootloader.standard.hex flashen und ich bin durch damit? Was ist mit HMID und Serial? Die musste ich ja beim OTA Bootloader erstellen immer angeben.
Lieben Gruß
Kai
Hallo Kai,
Zitat von: Kai-Alfonso am 05 Dezember 2018, 08:36:41
Gehe ich richtig in der Annahme, dass die zweite FW den OTA Bootloader schon enthält? Also einfach HB-UNI-Sensor1.ino.with_bootloader.standard.hex flashen und ich bin durch damit? Was ist mit HMID und Serial?
nein, ich fürchte, da ist nur der Standard Arduino Bootloader dabei. Nimm papa's makeota.html (von ihm verlinkt in Dirk's Ultraschallsensor Thread) und gib HMID, Serial und die Firmware ohne Bootloader an.
Gruß Peter
Zitat von: PeMue am 05 Dezember 2018, 08:49:54
Hallo Kai,
nein, ich fürchte, da ist nur der Standard Arduino Bootloader dabei. Nimm papa's makeota.html (von ihm verlinkt in Dirk's Ultraschallsensor Thread) und gib HMID, Serial und die Firmware ohne Bootloader an.
Gruß Peter
Hallo Peter,
den makeota-auswahl habe ich auch tatsächlich bei den anderen Aussen/Innensensoren benutzt - hatte irgendwie im Kopf, das man da auch die FW anhängen kann - geht aber anscheinend nicht. Also dann erst Bootloader und dann flashota nutzen.... Allerdings kann ich doch auch die normale makeota nutzen (wo man die FW anhängen kann) und die richtige DeviceModel ID einsetzen? Müsste doch F101 für Innen und F102 für Außen sein, oder?
Grüße
Kai
Mit OTA direkt kann ich nicht weiterhelfen, da ich herkömmlich seriell über FTDI flashe.
Wenn es aber um die DeviceID und mein sketch von github gehen sollte, diese ist F103.
Zitat von: Tom Major am 05 Dezember 2018, 11:50:16
Mit OTA direkt kann ich nicht weiterhelfen, da ich herkömmlich seriell über FTDI flashe.
Wenn es aber um die DeviceID und mein sketch von github gehen sollte, diese ist F103.
Hi Tom,
danke - ich bevorzuge eigentlich generell auch eher die serielle Variante - grade beim Initial-Flash. Allerdings, wenn die Geräte verbaut sind, spare ich mir durch das OTA das Ausbauen der Sensoren bei einem FW-Upgrade.
ja stimmt schon, ich hatte gerade bei der Entwicklung auch Situationen wo ich gerne von oben geflasht hätte statt in den Keller zu gehen ;)
Mich würde interessieren ob bei einer Flash Code size wie beim HB-UNI-Sensor1 die Duty 100% erreicht wird bzw. wie lange sich das wegen Duty hinzieht und wann man dann das nächste Device flashen kann.
Falls du es hinbekommst und mir eine kleine Anleitung sendest würde ich es mit auf der Projektseite aufnehmen.
Grüße Tom
Zitat von: Tom Major am 05 Dezember 2018, 12:00:44
Falls du es hinbekommst und mir eine kleine Anleitung sendest würde ich es mit auf der Projektseite aufnehmen.
Grüße Tom
Du meinst das Generieren des Bootloaders inkl FW mit makeota, dann flashen mit AVR Programmer.
Danach testen, ob das flashen per flashota geht und ob ich danach noch einmal flashen kann (duty cycle erreicht oder nicht)
Hallo Kai,
Zitat von: Kai-Alfonso am 05 Dezember 2018, 10:07:12
den makeota-auswahl habe ich auch tatsächlich bei den anderen Aussen/Innensensoren benutzt - hatte irgendwie im Kopf, das man da auch die FW anhängen kann - geht aber anscheinend nicht.
ich probiere gerade diese Version von makeota.html (https://github.com/pa-pa/AskSinPP/blob/master/bootloader/avr/makeota.html). Da kann man die Firmware mit anhängen.
Zitat von: Kai-Alfonso am 05 Dezember 2018, 10:07:12
Müsste doch F101 für Innen und F102 für Außen sein, oder?
Für Dirk's Sensoren bzw. die Firmware ja, Toms Sketch verwendet F103. Der Ultraschall von gloob noch einmal eine andere. Ich sammle die IDs mal und aktualisiere das Wiki.
Gruß Peter
Damit OTA funktioniert, muss die Firmware zwingend mit USE_OTA_BOOTLOADER übersetzt werden. Das sorgt dafür, dass später der Gerätetype, die HMID und Serial aus dem Bootloader gelesen werdem.
Nach dem Übersetzen am besten die [url https://github.com/pa-pa/AskSinPP/blob/master/bootloader/avr/makeota.html]aktuelle makeota.html[/url] nehmen und den Bootloader mit den benötigten Geräte-Werten sowie dem Firmware-Hex versehen. Das erzeugte Hex mit dem ISP flashen.
Die makeota.html Versionen in den Example-Verzeichnissen sind schon auf die Examples angepasst. Dort ist dann ein fester Gerätetype eingestellt und kann nicht verändert werden. Der Fensterkontakt kann auch noch ein paar Parameter im Bootloader ablegen. Das wird sonst bisher nirgendwo verwendet.
Zitat von: Tom Major am 05 Dezember 2018, 12:00:44
Mich würde interessieren ob bei einer Flash Code size wie beim HB-UNI-Sensor1 die Duty 100% erreicht wird bzw. wie lange sich das wegen Duty hinzieht und wann man dann das nächste Device flashen kann.
das ist auch sehr vom io abhängig.
cul kennt duty bei homematic nicht. oder hat sich das geändert?
hmuart kann quasi das doppelte wie hmusb/hmlan funken bis zum overload. da wurde wohl die berechnund geändert. ausserdem gibt es noch das hilfreiche attribut dutyCycle. ;)
bei allen io geht natürlich immer ein reboot. dann gehts wieder bei 0 los.
ein ota update kann nicht häppchenweise gesendet werden.
Hallo 8)
ist mir peinlich, aber ich komm mit meinen beschränkten Kenntnissen nicht mehr weiter. Vielleicht kann mir jemand helfen. Ich habe die Platine v1.4 von Peter und Dirk gelötet und beim überprüfen stelle ich fest, das ich auf der 3.3 Line nur 0,6 V habe. Aus den Batterien kommen 3 V, kurz nach der Drosselspule auch.
Ich hab schon alle Lötstellen mit der Lupe untersucht und hab soweit keine Fehler gefunden. Müssten alle richtig konnektiert sein soweit ich das erkenne.
Jemand eine Idee?
Hallo Kai,
Schaltplan ist hier: https://github.com/pemue-git/pcb/blob/master/homematic/Aussensensor_v1.4_sch.pdf.
Fragen:
- Ist SJ2 offen?
- Ist L1, C8, C9 und C10, MAX1724 bestückt? Ist L1 der richtige Typ (LQH43CN100K03L)?
- Hast Du ggf. beim Flashen über seriell 3,3 V an den Ausgang des MAX1724 gebracht (und der kann das nicht ab, ehrlich gesagt, das weiß ich nicht, wollte das aber auch testen)?
- Wie hast Du die Spannungsmessung (R2, R3, F4, T1 bzw. SJ2) bestückt?
Das ist mal das erste, was mir dazu einfällt. Ich habe am Wochenende ebenfalls einen Außensensor in Betrieb genommen (v1.5, noch nicht veröffentlicht) da ging der StepUp.
Gruß Peter
Zitat von: Kai-Alfonso am 06 Dezember 2018, 15:05:58
Jemand eine Idee?
Polarität der Batterie richtig angeschlossen? Ich löte immer erst die Spannungsversorgung auf und teste das, bevor ich den Prozessor auflöte. Den hast Du auch richtig plaziert?
Gruß
G.
Zitat von: PeMue am 06 Dezember 2018, 15:19:38
Hallo Kai,
Schaltplan ist hier: https://github.com/pemue-git/pcb/blob/master/homematic/Aussensensor_v1.4_sch.pdf.
Den kenn ich und hab es versucht nachzuvollziehen. Allerdings zu mehr scheitert es am Know how ???
Zitat von: PeMue am 06 Dezember 2018, 15:19:38
Fragen:
- Ist SJ2 offen?
- Ist L1, C8, C9 und C10, MAX1724 bestückt? Ist L1 der richtige Typ (LQH43CN100K03L)?
- Hast Du ggf. beim Flashen über seriell 3,3 V an den Ausgang des MAX1724 gebracht (und der kann das nicht ab, ehrlich gesagt, das weiß ich nicht, wollte das aber auch testen)?
- Wie hast Du die Spannungsmessung (R2, R3, F4, T1 bzw. SJ2) bestückt?
Ich hab mich an in diesem Beitrag von Dirk https://forum.fhem.de/index.php/topic,20620.msg853373.html#msg853373 (https://forum.fhem.de/index.php/topic,20620.msg853373.html#msg853373) verlinktem Schaltplan gehalten.
C8, C9 und C10 sind bestückt, ebenso MAX und L1 - als L1 hab ich den LQH43CN100K03L genommen (von Völkner bestellt)
SJ2 ist gebrückt bzw geschlossen, R2 470k, R3 100k, R4 und T nicht bestückt.
Du hattest mir ja auch einen Schaltplan geschickt, allerdings sind da für R2 und R3 andere (?) Werte?
Hab mal ein Foto der Platine angehangen... Bitte nicht zu kritisch sein, so lange löte ich noch nicht :-) Die Pins des Atmegas habe ich soweit es geht auf Durchgang geprüft. Eigentlich sollten alle konnektiert sein.
EDIT: Geflashed habe ich noch nicht, weil ich erstmal gemessen habe und mir der Fehler aufgefallen ist
Hallo Kai,
was mir auffällt: R6 und R7 müssten 4k7 sein (PullUp für I2C), R7 müsste ebenfalls 4k7 sein (ist bei mir im Schaltplan falsch, sorry).
Sollte aber für die Funktion des StepUps nicht relevant sein. Der Prozessor ist richtig positioniert.
Schau bitte noch einmal die Lötung an C10 an, ob die einen Kurzschluß zum MAX1724 macht.
Prüfe bitte auch mal am Prozessor die einzelnen Pins, ob da ggf. ein Kurzschluss ist.
Gruß Peter
Zitat von: Kai-Alfonso am 06 Dezember 2018, 15:05:58
Hallo 8)
ist mir peinlich, aber ich komm mit meinen beschränkten Kenntnissen nicht mehr weiter. Vielleicht kann mir jemand helfen. Ich habe die Platine v1.4 von Peter und Dirk gelötet und beim überprüfen stelle ich fest, das ich auf der 3.3 Line nur 0,6 V habe. Aus den Batterien kommen 3 V, kurz nach der Drosselspule auch.
"Aus den Batterien kommen 3 V", d.h. du verwendest 2 Batterien? Wozu dann der MAX1724?
Zitat von: Tom Major am 06 Dezember 2018, 17:27:33
"Aus den Batterien kommen 3 V", d.h. du verwendest 2 Batterien? Wozu dann der MAX1724?
Normalerweise, da ich Akkus nutzen wollte bzw Billig Batterien - da kommt normalerweise alles raus, nur keine 1.5 V je Batterie ;-) Ich hatte aber meine Lötsachen zur Arbeit mitgenommen und dummerweise natürlich nur die guten Varta hier.
Auf der Wikiseite steht ja
ZitatDie Spannungsversorgung erfolgt über zwei AA bzw. AAA Batterien. Damit eine möglichst gute Ausnutzung der Batteriekapazität erzielt wird und auch Sensoren mit 3,3 V Spannungsversorgung benutzt werden können, kann ein MAX1724 Step-Up-Converter bestückt werden. Dieser stellt eine stabile Spannungsversorgung von 3,3 V zur Verfügung. Als Mindest-Eingangsspannung sind hier dann lediglich 1,2 V notwendig. Somit ist eine Versorgung auch aus nur einer Batteriezelle denkbar.
Ich hab das so verstanden, das ich auch eine AA nutzen kann. - aber natürlich auch 2 - Hauptsache, ich liefere mindest 1,2 V
Zitat von: PeMue am 06 Dezember 2018, 16:00:00
Hallo Kai,
was mir auffällt: R6 und R7 müssten 4k7 sein (PullUp für I2C), R8 müsste ebenfalls 4k7 sein (ist bei mir im Schaltplan falsch, sorry).
Sollte aber für die Funktion des StepUps nicht relevant sein. Der Prozessor ist richtig positioniert.
Schau bitte noch einmal die Lötung an C10 an, ob die einen Kurzschluß zum MAX1724 macht.
Prüfe bitte auch mal am Prozessor die einzelnen Pins, ob da ggf. ein Kurzschluss ist.
Gruß Peter
Moin Peter,
R6 und R7 muss ich noch ändern, das ist kein Problem. C10 macht,sowie ich das gemessen habe, keinen Kurzschluss zum Max und die CPU hat auch kein Kurzschluss. (oder keinen, den ich gefunden hab)
R6,7 zu ändern wird dir bei diesem DC/DC Problem nicht helfen, das schrieb auch Peter.
ZitatIch hab das so verstanden, das ich auch eine AA nutzen kann. - aber natürlich auch 2 - Hauptsache, ich liefere mindest 1,2 V
Der MAX1724 ist ein StepUp und kein kombinierter StepUp/Down, ich denke irgendwo unterhalb der Ausgangsspannung gibt es eine Grenze für Vin (obwohl er bis 5,5V Vin verträgt).
Wenn man sich die Kennlinie "MAXIMUM OUTPUT CURRENT vs. INPUT VOLTAGE" im Datenblatt anschaut sieht man das auch.
Probier das ganze mal nur mit einer Batterie oder Akku als Eingangsspannung, hast du dann die 3,3V bzw. 3,0V am Ausgang?
Zitat von: Tom Major am 07 Dezember 2018, 11:18:18
R6,7 zu ändern wird dir bei diesem DC/DC Problem nicht helfen, das schrieb auch Peter.
Das hab ich auch so verstanden ;-)
Zitat von: Tom Major am 07 Dezember 2018, 11:18:18
Der MAX1724 ist ein StepUp und kein kombinierter StepUp/Down, ich denke irgendwo unterhalb der Ausgangsspannung gibt es eine Grenze für Vin (obwohl er bis 5,5V Vin verträgt).
Wenn man sich die Kennlinie "MAXIMUM OUTPUT CURRENT vs. INPUT VOLTAGE" im Datenblatt anschaut sieht man das auch.
Probier das ganze mal nur mit einer Batterie oder Akku als Eingangsspannung, hast du dann die 3,3V bzw. 3,0V am Ausgang?
Mach ich später, wenn ich zu Hause bin - hab hier wie gesagt nur die Vartas....
Ich hab übrigens das Problem gefunden. Hab SJ1 überbrückt und schwupps hatte ich die gewünschte Spannung. Dann habe ich C9 und C10 entfernt und noch mal sauber verlötet. Nachgemessen, das kein kurzer drin ist und schon gehts.
Ich hab 3.2V am Ausgang jetzt mit den Vartas...
Zitat von: Kai-Alfonso am 07 Dezember 2018, 11:38:34
Mach ich später, wenn ich zu Hause bin - hab hier wie gesagt nur die Vartas....
Ich hab übrigens das Problem gefunden. Hab SJ1 überbrückt und schwupps hatte ich die gewünschte Spannung. Dann habe ich C9 und C10 entfernt und noch mal sauber verlötet. Nachgemessen, das kein kurzer drin ist und schon gehts.
Das überbrückt den MAX1724, du hättest ihn also nicht bestücken müssen für Betrieb mit 2 Zellen.
Nimm halt
eine Varta um zu testen ob der StepUp geht (SJ1 offen).
Zitat von: Kai-Alfonso am 07 Dezember 2018, 11:38:34
Hab SJ1 überbrückt und schwupps hatte ich die gewünschte Spannung.
Tom war schneller: SJ1 geschlossen überbrückt den MAX1724.
Zitat von: Kai-Alfonso am 07 Dezember 2018, 11:38:34
Ich hab 3.2V am Ausgang jetzt mit den Vartas...
Dann sind Deine Batterien mit 1,6 V noch nagelneu ;)
Zitat von: Tom Major am 07 Dezember 2018, 11:18:18
Wenn man sich die Kennlinie "MAXIMUM OUTPUT CURRENT vs. INPUT VOLTAGE" im Datenblatt anschaut sieht man das auch.
Anbei noch der entsprechende Auszug des Datenblatts:
Bei 3,3 V am Ausgang sollte der Eingang knapp unter 3 V bleiben. Also entweder 2x NiMH Akku oder 1xVarta ...
Gruß Peter
Zitat von: PeMue am 07 Dezember 2018, 11:53:37
Tom war schneller: SJ1 geschlossen überbrückt den MAX1724.
Ja, das war mit bekannt - hab ich deswegen gemacht, um sicher zu gehen, das es an den Max Komponenten (L1,C9,C10,MAx) liegt.
Zitat von: PeMue am 07 Dezember 2018, 11:53:37
Bei 3,3 V am Ausgang sollte der Eingang knapp unter 3 V bleiben. Also entweder 2x NiMH Akku oder 1xVarta ...
Gruß Peter
Wie gesagt, wollte die Sensoren mit Akkus betreiben, deswegen der Max - zum testen hab ich hier auf der Arbeit aber nur herkömmliche AA
Der Gegentest mit EINER Varta hat auch geklappt - Stepup funktioniert
Zitat von: PeMue am 06 Dezember 2018, 16:00:00
Hallo Kai,
was mir auffällt: R6 und R7 müssten 4k7 sein (PullUp für I2C), R8 müsste ebenfalls 4k7 sein (ist bei mir im Schaltplan falsch, sorry).
Gruß Peter
Hallo Peter,
müssten es nicht R5,R6 und R8 sein? R7 ist doch der LED Vorwiderstand
Was ist eigentlich mit C12, der Kondensator am Radio. Brauch ich den? Kann ich was anderes nehmen? Hab grad keine 1µ zur Hand
Hallo Kai,
Zitat von: Kai-Alfonso am 07 Dezember 2018, 14:36:39
... müssten es nicht R5,R6 und R8 sein? R7 ist doch der LED Vorwiderstand.
Ja, ich habe es im entsprechenden Post geändert.
Zitat von: Kai-Alfonso am 07 Dezember 2018, 14:36:39
Was ist eigentlich mit C12, der Kondensator am Radio. Brauch ich den? Kann ich was anderes nehmen? Hab grad keine 1µ zur Hand
10 µ gehen auch. 100 nF wären ein bisschen zu wenig (oder blocken nur HF ab). Bei Dirk's Sensor fehlt dieser Kondensator ganz.
Gruß Peter
Zitat von: PeMue am 07 Dezember 2018, 14:51:42
Hallo Kai,
Ja, ich habe es im entsprechenden Post geändert.
10 µ gehen auch. 100 nF wären ein bisschen zu wenig (oder blocken nur HF ab). Bei Dirk's Sensor fehlt dieser Kondensator ganz.
Gruß Peter
Super, 10µ habe ich. Hab übrigens grade 2 von den neuen Sensoren mit OTA-Bootloader und FW geflashed. Später mal zu Hause testen, ob Sie gehen. Jedenfalls blinkt die Led fleissig beim booten - sieht soweit also gut aus.
Achja, erinnerst du dich daran, das ich mal gefragt hab, warum die Drosselspule heiß wird? War ein Kondensator kaputt - hab den ausgetauscht, dann ging es? (neu verlöten half nix, lag wohl am Kondensator)
Hat jemand eine Ahnung, wieso ich kein 0x06 efuse setzen kann? 0xff geht zum Beispiel
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x06:
avrdude: load data efuse data from input file 0x06:
avrdude: input file 0x06 contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0xfe != 0x06
avrdude: verification error; content mismatch
avrdude: safemode: efuse changed! Was 6, and is now fe
Would you like this fuse to be changed back? [y/n] n
Hi,
bin auch schon mehrfach über den Fehler gestolpert, gemäß der Erklärung von hier (http://www.engbedded.com/fusecalc/) ist 06 = fe in diesem Fall, deswegen kannst Du den Fehler getrost ignorieren.
Zitat von: tndx am 08 Dezember 2018, 12:21:22
Hi,
bin auch schon mehrfach über den Fehler gestolpert, gemäß der Erklärung von hier (http://www.engbedded.com/fusecalc/) ist 06 = fe in diesem Fall, deswegen kannst Du den Fehler getrost ignorieren.
Super, 0xfe geht - laut fusecalc müsste es ja das selbe sein.
Ich hab da aber noch ein anderes Problem, vielleicht kann mir jemand helfen.
Ich benutze folgendes Sketch von der Seite
//---------------------------------------------------------
// HB-UNI-Sensor1
// 2018-10-23 Tom Major (Creative Commons)
// https://creativecommons.org/licenses/by-nc-sa/3.0/
// You are free to Share & Adapt under the following terms:
// Give Credit, NonCommercial, ShareAlike
// +++
// AskSin++ 2016-10-31 papa Creative Commons
//---------------------------------------------------------
//---------------------------------------------------------
// !! NDEBUG should be defined when the sensor development and testing ist done
// and the device moves to serious operation mode With BME280 and TSL2561
// activated, this saves 2k Flash and 560 Bytes RAM (especially the RAM savings
// are important for stability / dynamic memory allocation etc.) This will get
// rid of the Arduino warning "Low memory available, stability problems may
// occur."
//
//#define NDEBUG
//---------------------------------------------------------
// define this to read the device id, serial and device type from bootloader section
//
#define USE_OTA_BOOTLOADER
#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>
#include <MultiChannelDevice.h>
#include <Register.h>
//---------------------------------------------------------
// Über diese defines werden die real angeschlossenen Sensoren aktiviert.
// Andernfalls verwendet der Sketch Dummy-Werte als Messwerte (zum Testen der Anbindung an HomeMatic/RaspberryMatic/FHEM)
//
//#define SENSOR_DS18X20
#define SENSOR_BME280
//#define SENSOR_TSL2561
#define SENSOR_MAX44009
//#define SENSOR_SHT10
//#define SENSOR_DIGINPUT
//---------------------------------------------------------
// Schwellwerte für Batteriespannungsmessung
#define BAT_VOLT_LOW 22 // 2.2V
#define BAT_VOLT_CRITICAL 19 // 1.9V
//---------------------------------------------------------
// Optionen für Batteriespannungsmessung, siehe README
//#define BAT_SENSOR BatterySensor // Standard, UBatt = Betriebsspannung AVR
#define BAT_SENSOR BatterySensorUni<14, 9, 3000> // mit StepUp, sense pin A0, activation pin D9, Vcc StepUp 3,0V
//---------------------------------------------------------
// Pin definitions
#define CONFIG_BUTTON_PIN 8
#define LED_PIN 4
// number of available peers per channel
#define PEERS_PER_CHANNEL 6
// all library classes are placed in the namespace 'as'
using namespace as;
#ifdef SENSOR_DS18X20
#include "Sensors/Sens_DS18X20.h" // HB-UNI-Sensor1 custom sensor class
#define ONEWIRE_PIN 3
#endif
#ifdef SENSOR_BME280
#include "Sensors/Sens_BME280.h" // HB-UNI-Sensor1 custom sensor class
#endif
#ifdef SENSOR_TSL2561
#include "Sensors/Sens_TSL2561.h" // HB-UNI-Sensor1 custom sensor class
#endif
#ifdef SENSOR_MAX44009
#include "Sensors/Sens_MAX44009.h" // HB-UNI-Sensor1 custom sensor class
#endif
#ifdef SENSOR_SHT10
#include "Sensors/Sens_SHT10.h" // HB-UNI-Sensor1 custom sensor class
#define SHT10_DATAPIN A4
#define SHT10_CLKPIN A5
#endif
#ifdef SENSOR_DIGINPUT
#include "Sensors/Sens_DIGINPUT.h" // HB-UNI-Sensor1 custom sensor class
#define DIGINPUT_PIN A0
Sens_DIGINPUT digitalInput; // muss wegen Verwendung in loop() global sein (Interrupt event)
#endif
// define all device properties
// Bei mehreren Geräten des gleichen Typs muss Device ID und Device Serial unterschiedlich sein!
const struct DeviceInfo PROGMEM devinfo = {
{ 0x90, 0xDC, 0xE7 }, // Device ID
"ZUC5670545", // Device Serial
{ 0xF1, 0x03 }, // Device Model
// Firmware Version
// die CCU Addon xml Datei ist mit der Zeile <parameter index="9.0" size="1.0" cond_op="E" const_value="0x12" />
// fest an diese Firmware Version gebunden! cond_op: E Equal, GE Greater or Equal
// bei Änderungen von Payload, message layout, Datenpunkt-Typen usw. muss die Version an beiden Stellen hochgezogen werden!
0x12,
as::DeviceType::THSensor, // Device Type
{ 0x01, 0x01 } // Info Bytes
};
// Configure the used hardware
typedef AvrSPI<10, 11, 12, 13> SPIType;
typedef Radio<SPIType, 2> RadioType;
typedef StatusLed<LED_PIN> LedType;
typedef AskSin<LedType, BAT_SENSOR, RadioType> BaseHal;
class Hal : public BaseHal {
public:
void init(const HMID& id)
{
BaseHal::init(id);
// init real time clock - 1 tick per second
// rtc.init();
// measure battery every 12h
battery.init(seconds2ticks(12UL * 60 * 60), sysclock);
battery.low(BAT_VOLT_LOW);
battery.critical(BAT_VOLT_CRITICAL);
}
bool runready() { return sysclock.runready() || BaseHal::runready(); }
} hal;
class WeatherEventMsg : public Message {
public:
void init(uint8_t msgcnt, int16_t temp, uint16_t airPressure, uint8_t humidity, uint32_t brightness, uint8_t digInputState,
uint16_t batteryVoltage, bool batLow)
{
uint8_t t1 = (temp >> 8) & 0x7f;
uint8_t t2 = temp & 0xff;
if (batLow == true) {
t1 |= 0x80; // set bat low bit
}
// als Standard wird BCAST gesendet um Energie zu sparen, siehe Beschreibung unten.
// Bei jeder 20. Nachricht senden wir stattdessen BIDI|WKMEUP, um eventuell anstehende Konfigurationsänderungen auch
// ohne Betätigung des Anlerntaster übernehmen zu können (mit Verzögerung, worst-case 20x Sendeintervall).
uint8_t flags = BCAST;
if ((msgcnt % 20) == 2) {
flags = BIDI | WKMEUP;
}
Message::init(21, msgcnt, 0x70, flags, t1, t2);
// Message Length (first byte param.): 11 + payload
// 1 Byte payload -> length 12
// 10 Byte payload -> length 21
// max. payload: 17 Bytes (https://www.youtube.com/watch?v=uAyzimU60jw)
// BIDI|WKMEUP: erwartet ACK vom Empfänger, ohne ACK wird das Senden wiederholt
// LazyConfig funktioniert, d.h. eine anstehende Conf.Änderung von der CCU wird nach dem nächsten Senden übernommen. Aber erhöhter
// Funkverkehr wegen ACK
//
// BCAST: ohne ACK zu Erwarten, Standard für HM Sensoren.
// LazyConfig funktioniert nicht, d.h. eine anstehende Conf.Änderung von der CCU muss durch den Config Button am Sensor übernommen
// werden!!
// papa:
// BIDI - fordert den Empfänger auf ein Ack zu schicken. Das wird auch zwingend für AES-Handling gebraucht. BCAST - signalisiert
// eine Broadcast-Message. Das wird z.B. verwendet, wenn mehrere Peers vor einen Sensor existieren. Es wird dann an einen Peer
// gesndet und zusätzlich das BCAST-Flag gesetzt. So dass sich alle die Nachrricht ansehen. Ein Ack macht dann natürlich keinen Sinn
// - es ist ja nicht klar, wer das senden soll.
//
// WKMEUP - wird für LazyConfig verwendet. Ist es in einer Message gesetzt, so weiss
// die Zentrale, dass das Geräte noch kurz auf weitere Nachrichten wartet. Die Lib setzt diese Flag für die StatusInfo-Message
// automatisch. Außerdem bleibt nach einer Kommunikation der Empfang grundsätzlich für 500ms angeschalten.
// airPressure
pload[0] = (airPressure >> 8) & 0xff;
pload[1] = airPressure & 0xff;
// humidity
pload[2] = humidity;
// brightness (Lux)
pload[3] = (brightness >> 24) & 0xff;
pload[4] = (brightness >> 16) & 0xff;
pload[5] = (brightness >> 8) & 0xff;
pload[6] = (brightness >> 0) & 0xff;
// digInputState
pload[7] = digInputState;
// batteryVoltage
pload[8] = (batteryVoltage >> 8) & 0xff;
pload[9] = batteryVoltage & 0xff;
}
};
// die "freien" Register 0x20/21 werden hier als 16bit memory für das Update
// Intervall in Sek. benutzt siehe auch hb-uni-sensor1.xml, <parameter
// id="Sendeintervall"> .. ausserdem werden die Register 0x22/0x23 für den
// konf. Parameter Höhe benutzt
DEFREGISTER(Reg0, MASTERID_REGS, DREG_TRANSMITTRYMAX, DREG_LOWBATLIMIT, 0x20, 0x21, 0x22, 0x23)
class SensorList0 : public RegList0<Reg0> {
public:
SensorList0(uint16_t addr)
: RegList0<Reg0>(addr)
{
}
bool updIntervall(uint16_t value) const
{
return this->writeRegister(0x20, (value >> 8) & 0xff) && this->writeRegister(0x21, value & 0xff);
}
uint16_t updIntervall() const { return (this->readRegister(0x20, 0) << 8) + this->readRegister(0x21, 0); }
bool height(uint16_t value) const { return this->writeRegister(0x22, (value >> 8) & 0xff) && this->writeRegister(0x23, value & 0xff); }
uint16_t height() const { return (this->readRegister(0x22, 0) << 8) + this->readRegister(0x23, 0); }
void defaults()
{
clear();
transmitDevTryMax(6);
lowBatLimit(BAT_VOLT_LOW);
updIntervall(600);
height(0);
}
};
class WeatherChannel : public Channel<Hal, List1, EmptyList, List4, PEERS_PER_CHANNEL, SensorList0>, public Alarm {
WeatherEventMsg msg;
int16_t temperature10;
uint16_t airPressure10;
uint8_t humidity;
uint32_t brightness;
uint8_t digInputState;
uint16_t batteryVoltage;
#ifdef SENSOR_DS18X20
Sens_DS18X20 ds18x20;
#endif
#ifdef SENSOR_BME280
Sens_BME280 bme280;
#endif
#ifdef SENSOR_TSL2561
Sens_TSL2561 tsl2561;
#endif
#ifdef SENSOR_MAX44009
Sens_MAX44009 max44009;
#endif
#ifdef SENSOR_SHT10
Sens_SHT10<SHT10_DATAPIN, SHT10_CLKPIN> sht10;
#endif
public:
WeatherChannel()
: Channel()
, Alarm(seconds2ticks(60))
, temperature10(0)
, airPressure10(0)
, humidity(0)
, brightness(0)
, digInputState(0)
, batteryVoltage(0)
{
}
virtual ~WeatherChannel() {}
virtual void trigger(AlarmClock& clock)
{
uint8_t msgcnt = device().nextcount();
measure();
msg.init(msgcnt, temperature10, airPressure10, humidity, brightness, digInputState, batteryVoltage, device().battery().low());
device().sendPeerEvent(msg, *this);
// reactivate for next measure
uint16_t updCycle = this->device().getList0().updIntervall();
set(seconds2ticks(updCycle));
clock.add(*this);
}
void forceSend()
{
sysclock.cancel(*this);
trigger(sysclock);
}
void measure()
{
// Messwerte mit Dummy-Werten vorbelegen falls kein realer Sensor für die Messgröße vorhanden ist
// zum Testen der Anbindung an HomeMatic/RaspberryMatic/FHEM
#if !defined(SENSOR_DS18X20) && !defined(SENSOR_BME280) && !defined(SENSOR_SHT10)
temperature10 = 188; // 18.8C
#endif
#if !defined(SENSOR_BME280) && !defined(SENSOR_SHT10)
humidity = 88; // 88%
#endif
#if !defined(SENSOR_BME280)
airPressure10 = 10880; // 1088 hPa
#endif
#if !defined(SENSOR_TSL2561) && !defined(SENSOR_MAX44009)
brightness = 88000; // 88000 Lux
#endif
#ifdef SENSOR_DS18X20
ds18x20.measure();
temperature10 = ds18x20.temperature();
#endif
// Entweder BME280 oder SHT10 für Feuchtigkeit, ggf. für anderen Bedarf anpassen
#ifdef SENSOR_BME280
uint16_t height = this->device().getList0().height();
bme280.measure(height);
temperature10 = bme280.temperature();
airPressure10 = bme280.pressureNN();
humidity = bme280.humidity();
#elif defined SENSOR_SHT10
sht10.measure();
temperature10 = sht10.temperature();
humidity = sht10.humidity();
#endif
// Entweder TSL2561 oder MAX44009 für Helligkeit, ggf. für anderen Bedarf anpassen
#ifdef SENSOR_TSL2561
tsl2561.measure();
brightness = tsl2561.brightnessLux(); // also available: brightnessVis(),
// brightnessIR(), brightnessFull(), but these
// are dependent on integration time setting
#elif defined SENSOR_MAX44009
max44009.measure();
brightness = max44009.brightnessLux();
#endif
#ifdef SENSOR_DIGINPUT
digInputState = digitalInput.pinState();
#endif
// convert default AskSinPP battery() resolution of 100mV to 1mV, last 2
// digits will be 00 for higher resolution, override battery() with modified
// voltage() calculation see my HB-SEC-WDS-2 for an example with higher
// resolution
batteryVoltage = 100UL * device().battery().current();
}
void initSensors()
{
#ifdef SENSOR_DS18X20
ds18x20.init(ONEWIRE_PIN);
#endif
#ifdef SENSOR_BME280
bme280.init();
#endif
#ifdef SENSOR_TSL2561
tsl2561.init();
#endif
#ifdef SENSOR_MAX44009
max44009.init();
#endif
#ifdef SENSOR_SHT10
#if defined SENSOR_BME280 || defined SENSOR_TSL2561 || defined SENSOR_MAX44009
sht10.i2cEnableSharedAccess(); // falls I2C Sensoren vorhanden dies dem SHT10 mitteilen
#endif
sht10.init();
#endif
#ifdef SENSOR_DIGINPUT
digitalInput.init(DIGINPUT_PIN);
#endif
DPRINTLN("Sensor setup done");
}
void setup(Device<Hal, SensorList0>* dev, uint8_t number, uint16_t addr)
{
Channel::setup(dev, number, addr);
initSensors();
set(seconds2ticks(5)); // first message in 5 sec.
sysclock.add(*this);
}
void configChanged()
{
// DPRINTLN("Config changed: List1");
}
uint8_t status() const { return 0; }
uint8_t flags() const { return 0; }
};
class SensChannelDevice : public MultiChannelDevice<Hal, WeatherChannel, 1, SensorList0> {
public:
typedef MultiChannelDevice<Hal, WeatherChannel, 1, SensorList0> TSDevice;
SensChannelDevice(const DeviceInfo& info, uint16_t addr)
: TSDevice(info, addr)
{
}
virtual ~SensChannelDevice() {}
virtual void configChanged()
{
TSDevice::configChanged();
DPRINTLN("Config Changed: List0");
uint8_t lowBatLimit = this->getList0().lowBatLimit();
DPRINT("lowBatLimit: ");
DDECLN(lowBatLimit);
battery().low(lowBatLimit);
uint8_t txDevTryMax = this->getList0().transmitDevTryMax();
DPRINT("transmitDevTryMax: ");
DDECLN(txDevTryMax);
uint16_t updCycle = this->getList0().updIntervall();
DPRINT("updCycle: ");
DDECLN(updCycle);
uint16_t height = this->getList0().height();
DPRINT("height: ");
DDECLN(height);
}
};
SensChannelDevice sdev(devinfo, 0x20);
ConfigButton<SensChannelDevice> cfgBtn(sdev);
void setup()
{
DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
sdev.init(hal);
buttonISR(cfgBtn, CONFIG_BUTTON_PIN);
sdev.initDone();
}
void loop()
{
bool worked = hal.runready();
bool poll = sdev.pollRadio();
if (worked == false && poll == false) {
#ifdef SENSOR_DIGINPUT
if (digitalInput.notifyEvent()) {
digitalInput.resetEvent();
DPRINTLN(F("DIGINPUT change"));
sdev.channel(1).forceSend();
delay(250); // Entprellen
digitalInput.enableINT();
}
#endif
// deep discharge protection
// if we drop below critical battery level - switch off all and sleep forever
if (hal.battery.critical()) {
// this call will never return
hal.activity.sleepForever(hal);
}
// if nothing to do - go sleep
hal.activity.savePower<Sleep<>>(hal);
}
}
/*
//---------------------------------------------------------
Die Registerklassen (Listen) eines Homematic-Gerätes
Gerätebezogene Register
Gerätebezogene Register existieren für jedes HomeMatic-Gerät nur einmal und
werden in der sogenannten List0 gespeichert.
Kanalbezogene Register
Kanalbezogene Register existieren für jeden Kanal eines Gerätes einmal und
werden in der sogenannten List1 gespeichert.
Verknüpfungsbezogene Register
Diese Register sind am umfangreichsten und werden für jeden Verknüpfungspartner
(peer) einzeln separat angelegt in der List3 (RegL_03.<peer>). Die
grundsätzlichen Funktionen und ihre Zusammenhänge sind auch ausführlich in der
Einsteigerdokumentation erklärt, inklusive Skizzen für die sogenannte state
machine.
https://wiki.fhem.de/wiki/Homematic-Register_von_A-Z_(Namen,_Erkl%C3%A4rung)
https://wiki.fhem.de/wiki/HomeMatic_Register_programmieren
*/Angepasst hatte ich:
#define USE_OTA_BOOTLOADER -> OTA Bootloader nutzen
#define BAT_SENSOR BatterySensorUni<14, 9, 3000> // mit StepUp, sense pin A0, activation pin D9, Vcc StepUp 3,0V
Mein Problem ist, dass das Gerät gar nix tut. Ich habe alle Lötstellen auf Kurzschluss/Konnektivität geprüft. Das Radio scheint nichts zu senden, jedenfalls empfängt mein nanoCul keine Raw Messages. Als C12 hab ich ein 10µ Kondensator genommen (1µ normalerweise laut Schaltplan), weil den grade da hatte.
Vielleicht kann mir jemand helfen beim debuggen?
Zitat von: Kai-Alfonso am 11 Dezember 2018, 13:50:50
Mein Problem ist, dass das Gerät gar nix tut. Ich habe alle Lötstellen auf Kurzschluss/Konnektivität geprüft. Das Radio scheint nichts zu senden, jedenfalls empfängt mein nanoCul keine Raw Messages. Als C12 hab ich ein 10µ Kondensator genommen (1µ normalerweise laut Schaltplan), weil den grade da hatte.
Vielleicht kann mir jemand helfen beim debuggen?
CC1101 defekt, fehlhaft?
https://forum.fhem.de/index.php/topic,91740.0.html
Zitat von: gloob am 11 Dezember 2018, 14:06:50
CC1101 defekt, fehlhaft?
https://forum.fhem.de/index.php/topic,91740.0.html
Hm, kann man nicht ausschließen, allerdings sehen die CC1001 Module so aus, wie ich die auch kenne und erwarte. Allerdings habe ich auch einen zweiten identischen Sensor mit dem C1101 aus der gleichen Lieferung gebaut, selbe Ergebnis.
Kann daran liegen, ich persönlich halte es für wahrscheinlicher, das ich irgendwo einen Fehler gemacht habe, da ich diesen Sensortyp noch nicht gebaut hatte :-)
Nachtrag:
Aber vielleicht hast du recht - selbst der OTA Bootloader (man sieht ja, das er mit 7x blinken startet) erzeugt keinen Funkverkehr :o :o :o :o
Keine Ahnung, ob das das Problem ist, aber sind Deine R5 und R6 nicht falsch rum eingelötet?
Zitat von: tndx am 11 Dezember 2018, 15:35:56
... aber sind Deine R5 und R6 nicht falsch rum eingelötet?
Ja, sind sie (siehe Bild). Vielen Dank.
Gruß Peter
Zitat von: PeMue am 11 Dezember 2018, 15:51:21
Ja, sind sie (siehe Bild). Vielen Dank.
Gruß Peter
habs grad auch gesehen :-( Ich muss als Neuling besser lernen, die Pläne noch genauer zu lesen. Bei den Wettersensoren von Dirk hatte ich die Eagle Files, da ging das besser und war (zu mindest für mich) verständlicher, da ich da die Platine mit Lage der Teile sehen kann und mir auch ein BOM ausdrucken konnte
Zitat von: Kai-Alfonso am 11 Dezember 2018, 15:54:12
... da ging das besser und war (zu mindest für mich) verständlicher, da ich da die Platine mit Lage der Teile sehen kann und mir auch ein BOM ausdrucken konnte.
Guggsch Du hier :o: https://github.com/pemue-git/pcb/tree/master/homematic/eagle
Gruß Peter
Zitat von: PeMue am 11 Dezember 2018, 15:56:33
Guggsch Du hier :o: https://github.com/pemue-git/pcb/tree/master/homematic/eagle
Gruß Peter
Ups, ich hab nix gesagt :-X :-X :-X :-X 8) 8)
Zitat von: tndx am 11 Dezember 2018, 15:35:56
Keine Ahnung, ob das das Problem ist, aber sind Deine R5 und R6 nicht falsch rum eingelötet?
Sorry, da hatte ich echt Tomaten auf den Augen bzw Opfer meiner eigenen Unerfahrenheit. Daran lag es natürlich und ich bin froh, das es nicht am CC1101 lag - die Widerstände waren schnell gedreht und jetzt seh ich auch Funkverkehr
Hallo Kai,
Zitat von: Kai-Alfonso am 11 Dezember 2018, 13:50:50
Angepasst hatte ich:
#define USE_OTA_BOOTLOADER -> OTA Bootloader nutzen
#define BAT_SENSOR BatterySensorUni<14, 9, 3000> // mit StepUp, sense pin A0, activation pin D9, Vcc StepUp 3,0V
sollte für die Schaltung v1.4 so sein:
#define BAT_SENSOR BatterySensorUni<15, 7, 3300> // mit StepUp, sense pin A1, activation pin D7, Vcc StepUp 3,3VGruß Peter
Jetzt ist doch glatt ein BMP180 defekt. Auf zwei verschiedene Platinen gelötet und funktioniert immer noch nicht. So ein Mist ... >:(
Naja, wozu gibt es breakout boards :P
Gruß PeMue
Hallo,
ich würde gerne den Universalsensor von Tom auf Seite 170 nachbauen, wisst ihr welche Größe die SMD-Bauteile haben? Ich denke 0805, bin mir aber nicht sicher.
Der Taster, da müsste doch der hier passen oder: https://de.aliexpress.com/item/40-teile-los-3-6-2-5-MM-SMD-Tactile-Takt-Push-Button-Micro-Schalter-Momentary/32950968196.html?spm=a2g0s.13010208.99999999.259.30453c00TTbVCV (https://de.aliexpress.com/item/40-teile-los-3-6-2-5-MM-SMD-Tactile-Takt-Push-Button-Micro-Schalter-Momentary/32950968196.html?spm=a2g0s.13010208.99999999.259.30453c00TTbVCV)
Vielen Dank
Gruß
Tobi
Zitat von: tobi90 am 13 Dezember 2018, 20:14:01
Hallo,
ich würde gerne den Universalsensor von Tom auf Seite 170 nachbauen, wisst ihr welche Größe die SMD-Bauteile haben? Ich denke 0805, bin mir aber nicht sicher.
Der Taster, da müsste doch der hier passen oder: https://de.aliexpress.com/item/40-teile-los-3-6-2-5-MM-SMD-Tactile-Takt-Push-Button-Micro-Schalter-Momentary/32950968196.html?spm=a2g0s.13010208.99999999.259.30453c00TTbVCV (https://de.aliexpress.com/item/40-teile-los-3-6-2-5-MM-SMD-Tactile-Takt-Push-Button-Micro-Schalter-Momentary/32950968196.html?spm=a2g0s.13010208.99999999.259.30453c00TTbVCV)
Vielen Dank
Gruß
Tobi
SMD 0805, korrekt.
Tasterabmessungen 3x6x2,5 klingt gut, diese Maße habe ich auch bestellt.
So, ich hab jetzt mal ein paar 1.3er Platinen für Innen (Universalsensor), die ich noch hatte fertig gemacht. Dort ist ja bei mir noch der TSL2561 verbaut. Es ist zwar für Innen egal, weil er wahrscheinlich Innen nicht übersteuert, aber um die Vergleichbarkeit zu haben, würde ich gerne auf den Univeralsensor V1.3 Platinen den MAX44009 wechseln. Letzterer liefert ja (sofern ich das Datenblatt richtig verstehe) echte Luxwerte - der TSL liefert noch einen fiktiven Wert von X bis Y.
Anschließen kann ich Ihn ja als Breakout Board Variante an J3 - als Sketch hatte ich für die Universalsensoren immer der Github Repo genommen, was im Wiki verlinkt ist. Mittlerweile gibt es aber so viele Forks, das ich irgendwie den Überblick verloren habe.
@Tom - wie Aufwändig wäre die Implementation des Sensors in den Universalsensor-Sketch?
Hallo Kai,
Zitat von: Kai-Alfonso am 14 Dezember 2018, 13:29:15
@Tom - wie Aufwändig wäre die Implementation des Sensors in den Universalsensor-Sketch?
in Toms (https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino) Sketch ist doch der TSL2561 und der MAX44009 schon drin. Oder habe ich Dich missverstanden?
Ich bin gerade dabei, den BMP
180 zu integrieren, das ist dauert aber mit meinen bescheidenen Programmierkenntnissen 8)
Gruß Peter
Wenn ihr den Sketch von Tom benutzt, müssen doch nur die richtigen Defines am Anfang gesetzt werden.
//---------------------------------------------------------
// Über diese defines werden die real angeschlossenen Sensoren aktiviert.
// Andernfalls verwendet der Sketch Dummy-Werte als Messwerte (zum Testen der Anbindung an HomeMatic/RaspberryMatic/FHEM)
//
//#define SENSOR_DS18X20
#define SENSOR_BME280
//#define SENSOR_TSL2561
#define SENSOR_MAX44009
//#define SENSOR_SHT10
//#define SENSOR_DIGINPUT
Der BME280 macht auch den BMP280 - halt nur ohne Luftfeuchtigkeit.
Zitat von: papa am 14 Dezember 2018, 13:50:41
Wenn ihr den Sketch von Tom benutzt, müssen doch nur die richtigen Defines am Anfang gesetzt werden.
//---------------------------------------------------------
// Über diese defines werden die real angeschlossenen Sensoren aktiviert.
// Andernfalls verwendet der Sketch Dummy-Werte als Messwerte (zum Testen der Anbindung an HomeMatic/RaspberryMatic/FHEM)
//
//#define SENSOR_DS18X20
#define SENSOR_BME280
//#define SENSOR_TSL2561
#define SENSOR_MAX44009
//#define SENSOR_SHT10
//#define SENSOR_DIGINPUT
Der BME280 macht auch den BMP280 - halt nur ohne Luftfeuchtigkeit.
Es geht um dieses Repo bei Github -> https://github.com/kc-GitHub/Wettersensor
Dieses ist im Universalsensor Wiki verlinkt und die dort erhältliche FW habe ich auf meinen Universalsensoren Platinen 1.3 genutzt. (Bild im Anhang)
Toms Sketch (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1) kann ich für den ja nicht nehmen, oder doch?
Zitat von: PeMue am 14 Dezember 2018, 13:44:36
Ich bin gerade dabei, den BMP180 zu integrieren, das ist dauert aber mit meinen bescheidenen Programmierkenntnissen 8)
Dann nimmst Du die Bmp180 Klasse (sensors/Bmp180.h) aus dem AskSinPP Repository. Alles schon da.
Zitat von: papa am 14 Dezember 2018, 14:36:18
Dann nimmst Du die Bmp180 Klasse (sensors/Bmp180.h) aus dem AskSinPP Repository. Alles schon da.
Habe ich auch genommen, aber auf Toms Sketch "umgeschrieben" ;) Sobald das läuft, werde ich es veröffentlichen.
Zitat von: Kai-Alfonso am 14 Dezember 2018, 14:25:48
Toms Sketch (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1) kann ich für den ja nicht nehmen, oder doch?
Doch, Du musst halt die Sensor ID im Bootloader anpassen und den Sketch entsprechend compilieren.
Du musst aber die Pins für die Spannungsmessung (activation + sense)!
Dann auch das richtige FHEM Modul einspielen. Ich würde Dirks Firmware v0.15 nur nehmen, wo die Hardware-Konfiguration passt.
Gruß Peter
Zitat von: Kai-Alfonso am 14 Dezember 2018, 14:25:48
Toms Sketch (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1) kann ich für den ja nicht nehmen, oder doch?
Soweit ich das sehe - doch. LED und ConfigTaster benutzen die selben Pins. Der I²C und SPI sowieso. CC1101 Interrupt ist auch am selben Pin. Kannst also ohne Probleme nehmen. Falls die Pins doch nciht stimmen, müssen sie eben im Sketch angepasst werden. Sollte auch machbar sein.
Zitat von: papa am 14 Dezember 2018, 14:38:41
Soweit ich das sehe - doch. LED und ConfigTaster benutzen die selben Pins. Der I²C und SPI sowieso. CC1101 Interrupt ist auch am selben Pin. Kannst also ohne Probleme nehmen. Falls die Pins doch nciht stimmen, müssen sie eben im Sketch angepasst werden. Sollte auch machbar sein.
Ach super, das hört sich ja gut an. 8) 8) Step Up Config passt auch? Hab alle Sensoren mit Stepup bestückt
Zitat von: Kai-Alfonso am 14 Dezember 2018, 14:42:59
Ach super, das hört sich ja gut an. 8) 8) Step Up Config passt auch? Hab alle Sensoren mit Stepup bestückt
Nein - leider nicht. So wie ich das sehe hat der "alte" Unisensor D7 und A1 (Aktivierung / Messung) und Toms hat im Sketch stehen D9 & A0. Das muss entsprechend angepasst werden.
Zitat von: PeMue am 14 Dezember 2018, 14:37:25
Habe ich auch genommen, aber auf Toms Sketch "umgeschrieben" ;) Sobald das läuft, werde ich es veröffentlichen.
Hallo Peter,
hättest nur was sagen sollen, ich kann gern eine weitere Option für den BMP180 einbauen, bisher war noch kein Bedarf da, ist aber schnell gemacht.
p.s. Bin leider noch nicht dazu gekommen deine Sensor SMD Bestückung zu testen, da noch kein ATmega drauf ist, ist aber für die nächsten Tage fest eingeplant ;)
Zitat von: Tom Major am 14 Dezember 2018, 14:49:56
Hallo Peter,
hättest nur was sagen sollen, ich kann gern eine weitere Option für den BMP180 einbauen, bisher war noch kein Bedarf da, ist aber schnell gemacht.
Dann warte ich auch noch auf die Änderungen. Hab ja auch den BMP180 auf den alten Universalsensoren verbaut 8)
Hallo Tom,
Zitat von: Tom Major am 14 Dezember 2018, 14:49:56
hättest nur was sagen sollen, ich kann gern eine weitere Option für den BMP180 einbauen, bisher war noch kein Bedarf da, ist aber schnell gemacht.
ich nehm Dich gerne als "reviewer" meiner Änderungen, dann lerne ich noch was dabei ;)
Ich habe gemerkt, dass ich dringend eine Einfürung in objektorientierte Programmierung brauche :-[
Gruß Peter
Achso, evtl irgendwann mal Softwareunterstützung für den BoschBME680 interessant? ;) ;) ;) 8) 8) 8)
https://www.bosch-sensortec.com/bst/products/all_products/bme680
https://www.watterott.com/de/BME680-Breakout
Zitat von: Kai-Alfonso am 14 Dezember 2018, 15:07:20
Achso, evtl irgendwann mal Softwareunterstützung für den BoschBME680 interessant? ;) ;) ;) 8) 8) 8)
Hierfür ist laut Bosch der Atmega328p zu "klein". Siehe auch unsere Diskussionen beim
LaCrosse
Gate
way bzw. nano LGW. Aber ein Sensor mit dem Atmega644 könnte funktionieren.
Gruß Peter
Hatte noch einen BMP180 von früher daliegen und getestet, läuft, ist jetzt über ein neues #define im UniSensor1 sketch aktivierbar.
Der Support für die Berechnung des Drucks auf Meereshöhe / NN folgt noch.
Zitat von: Tom Major am 15 Dezember 2018, 00:03:58
Hatte noch einen BMP180 von früher daliegen und getestet, läuft, ist jetzt über ein neues #define im UniSensor1 sketch aktivierbar.
Der Support für die Berechnung des Drucks auf Meereshöhe / NN folgt noch.
super, vielen Dank Tom :) :) :)
Zitat von: Kai-Alfonso am 17 Dezember 2018, 11:44:25
super, vielen Dank Tom :) :) :)
Gerne.
Berechnung des Drucks auf Meereshöhe ist jetzt für den BMP180 auch drin.
Zitat von: papa am 14 Dezember 2018, 14:49:13
Nein - leider nicht. So wie ich das sehe hat der "alte" Unisensor D7 und A1 (Aktivierung / Messung) und Toms hat im Sketch stehen D9 & A0. Das muss entsprechend angepasst werden.
Dazu habe ich mal eine Frage: Wie wird das denn definiert?
Im Ursprungssketch steht ja:
#define BAT_SENSOR BatterySensorUni<14, 9, 3000> // mit StepUp, sense pin A0, activation pin D9, Vcc StepUp 3,0VWie definiere ich denn den Sense Pin? 9,3000 ist mir klar (Pin D9, 3000 mV) - worauf bezieht sich die 14?
Edit: Ok, ich hab mir vom Chip mal den Pin-Out angeschaut. Für D7 und A1 (Aktivierung / Messung) müsste es dann wie folgt heißen?
#define BAT_SENSOR BatterySensorUni<15, 7, 3000>
Hallo Kai,
Zitat von: PeMue am 11 Dezember 2018, 16:16:13
sollte für die Schaltung v1.4 so sein:
#define BAT_SENSOR BatterySensorUni<15, 7, 3300> // mit StepUp, sense pin A1, activation pin D7, Vcc StepUp 3,3V
das stand schon mal da.
M.E. ist auch die Ausgangsspannung des Schaltreglers 3,3 V, daher müsste es 3300 heißen. Aber dazu kann Tom bestimmt softwareseitig auch noch etwas sagen.
Gruß Peter
Zitat von: PeMue am 18 Dezember 2018, 09:17:12
Hallo Kai,
das stand schon mal da.
M.E. ist auch die Ausgangsspannung des Schaltreglers 3,3 V, daher müsste es 3300 heißen. Aber dazu kann Tom bestimmt softwareseitig auch noch etwas sagen.
Gruß Peter
Ach stimm, hattest du ja geschrieben - habe ich ganz übersehen :o 8) 8) Sorry
Es scheint aber irgendein ein Problem noch bei mir zu geben.
Ich hab folgende Sensoren aktiviert
//#define SENSOR_DS18X20
//#define SENSOR_BME280
#define SENSOR_BMP180
#define SENSOR_TSL2561
//#define SENSOR_MAX44009
#define SENSOR_SHT10
//#define SENSOR_DIGINPUT
Nach dem Booten des Bootloaders (7 mal blinken) leuchtet die LED dauerhaft
Hallo zusammen,
wenn ich einen Sensor mit zwei Lichtsensoren bauen will (TSL2561 und MAX44001) müsste ich in
public:
WeatherChannel()
: Channel()
, Alarm(seconds2ticks(60))
, temperature10(0)
, airPressure10(0)
, humidity(0)
, brightness(0)
, digInputState(0)
, batteryVoltage(0)
WeatherEventMsg msg;
int16_t temperature10;
uint16_t airPressure10;
uint8_t humidity;
uint32_t brightness;
uint8_t digInputState;
uint16_t batteryVoltage;
den zweiten Kanal in temperature10 und airpressure10 "verstecken", um denselben Wertebereich zu bekommen und dann per userReading die beiden Werte in FHEM wieder zu einem zusammenzubauen. Oder gibt es noch eine bessere Lösung?
Eine Temperatur (ohne Faktor 10) würde dann in humidity kommen, falls noch etwas übrig sein sollte, oder? :-\
Danke + Gruß
Peter
Hallo Peter,
vielleicht ist ja der Universelle-Sensor-Sketch etwas für Dich. Da kannst DU selbst bestimmen, was gesendet wird. Auf FHEM Seite muss dazu nur ein Attribute angelegt werden, wleches das gesendete Format bestimmt.
https://forum.fhem.de/index.php/topic,57486.msg804110.html#msg804110
Zitat von: PeMue am 18 Dezember 2018, 09:17:12
Hallo Kai,
das stand schon mal da.
M.E. ist auch die Ausgangsspannung des Schaltreglers 3,3 V, daher müsste es 3300 heißen. Aber dazu kann Tom bestimmt softwareseitig auch noch etwas sagen.
Gruß Peter
Ich habe MAX1724 mit 3,0V Ausgangsspannung im Einsatz, deswegen die 3000, aber klar bei 3,3V Ausgangsspannung natürlich dann 3300.
Zitat von: Kai-Alfonso am 18 Dezember 2018, 12:29:16
Es scheint aber irgendein ein Problem noch bei mir zu geben.
Ich hab folgende Sensoren aktiviert
//#define SENSOR_DS18X20
//#define SENSOR_BME280
#define SENSOR_BMP180
#define SENSOR_TSL2561
//#define SENSOR_MAX44009
#define SENSOR_SHT10
//#define SENSOR_DIGINPUT
Nach dem Booten des Bootloaders (7 mal blinken) leuchtet die LED dauerhaft
Ich würde in solchen Fällen immer erst mal auf die serielle Debugausgabe über FTDI im Arduino Serial Monitor schauen. Kommen die Init Meldungen der AskSinPP? Werden alle Sensoren erkannt und kommen Messwerte?
Zitat von: PeMue am 18 Dezember 2018, 18:10:58
den zweiten Kanal in temperature10 und airpressure10 "verstecken", um denselben Wertebereich zu bekommen und dann per userReading die beiden Werte in FHEM wieder zu einem zusammenzubauen. Oder gibt es noch eine bessere Lösung?
Eine Temperatur (ohne Faktor 10) würde dann in humidity kommen, falls noch etwas übrig sein sollte, oder? :-\
Danke + Gruß
Peter
ich verstehe die Frage mit dem "verstecken" nicht wirklich. In gewissen Grenzen bist du ja frei die payload selber zu bestimmen solange du auf der anderen Seite (FHEM, CCU) für die korrekte Dekodierung sorgst.
Du könntest z.B. den zweiten Helligkeitswert in der Payload anfügen und die Messagelänge entsprechend vergrößern. Oder nicht benutzte Messwerte entfernen. Und dann das Perl Script anpassen dass die Dekodierung zu deinen Änderungen passt.
Zitat von: Tom Major am 19 Dezember 2018, 01:05:11
Ich würde in solchen Fällen immer erst mal auf die serielle Debugausgabe über FTDI im Arduino Serial Monitor schauen. Kommen die Init Meldungen der AskSinPP? Werden alle Sensoren erkannt und kommen Messwerte?
Muss ich dafür NDEBUG aktivieren?
Und noch eine kleine Frage: ist es jetzt Typ F102 oder F103, wenn man den alten Unisensor mit der neuen Software flashed?
Hallo papa,
Zitat von: papa am 18 Dezember 2018, 22:06:30
vielleicht ist ja der Universelle-Sensor-Sketch etwas für Dich. Da kannst DU selbst bestimmen, was gesendet wird. Auf FHEM Seite muss dazu nur ein Attribute angelegt werden, wleches das gesendete Format bestimmt.
https://forum.fhem.de/index.php/topic,57486.msg804110.html#msg804110
danke für die Info, werde ich mir mal anschauen.
Hallo Tom,
Zitat von: Tom Major am 19 Dezember 2018, 01:20:35
Ich verstehe die Frage mit dem "verstecken" nicht wirklich. In gewissen Grenzen bist du ja frei die payload selber zu bestimmen solange du auf der anderen Seite (FHEM, CCU) für die korrekte Dekodierung sorgst.
das war mir in dieser Form nicht klar. Ich dachte, für den Universalsensor ist die PayLoad festgelegt.
Zitat von: Tom Major am 19 Dezember 2018, 01:20:35
Du könntest z.B. den zweiten Helligkeitswert in der Payload anfügen und die Messagelänge entsprechend vergrößern. Oder nicht benutzte Messwerte entfernen. Und dann das Perl Script anpassen dass die Dekodierung zu deinen Änderungen passt.
Im Sketch würde ich das bestimmt hinbekommen, auf FHEM Seite wird das (mangels Perl Kenntnissen) deutlich schwieriger ...
Gruß Peter
Zitat von: Kai-Alfonso am 19 Dezember 2018, 07:51:02
Muss ich dafür NDEBUG aktivieren?
Und noch eine kleine Frage: ist es jetzt Typ F102 oder F103, wenn man den alten Unisensor mit der neuen Software flashed?
NDEBUG muss dafür kommentiert bleiben.
//#define NDEBUGMein Sketch verwendet F103 (Zeile 105)
Zitat von: PeMue am 19 Dezember 2018, 10:29:15
Hallo Tom,
das war mir in dieser Form nicht klar. Ich dachte, für den Universalsensor ist die PayLoad festgelegt.
Im Sketch würde ich das bestimmt hinbekommen, auf FHEM Seite wird das (mangels Perl Kenntnissen) deutlich schwieriger ...
Gruß Peter
Wenn du mir schreibst welche Messwerte du genau in deiner Spezialversion brauchst mache ich ich dir einen Vorschlag für die Payload und für das Decode in FHEM.
Erst mal vielen Dank für die vielen Infos hier. Ich habe HB-UNI-Sensor1 zusammengebaut und funktioniert auf Anhieb. FHEM bekommt regelmäßig plausible Werte - außer von MAX44009 (GY-49). Der funktioniert prima, solange der Sensor auf meinem Schreibtisch liegt. Sobald ich ihn nach draußen stelle, kommen erst ein paar höhere Werte im 2000er Bereich, dann nur noch 0-Werte. Hole ich ihn wieder rein, sofort wieder Werte im 300er Bereich. Das habe ich ein paar mal wiederholt und ist reproduzierbar. Die Außentemperatur kann es eigentlich nicht sein (ca. 3° ), weil 1. die Nullwerte kommen, bevor der richtig ausgekühlt ist und 2. plausible Helligkeitswerte sofort kommen sobald er wieder drin ist. Hat jemand eine Idee ? Wie kann ich das Problem am Besten finden/isolieren?
Habe mir mal das Datenblatt und das GY-49 angeschaut - Der Eingang für die Auswahl der Adresse (A0) war offen. Ich habe ihn mal mit GND verlötet und warte nun dass es draußen wieder hell wird.
Danke
Gregor
Zitat von: gregor am 20 Dezember 2018, 16:34:21
Erst mal vielen Dank für die vielen Infos hier. Ich habe HB-UNI-Sensor1 zusammengebaut und funktioniert auf Anhieb. FHEM bekommt regelmäßig plausible Werte - außer von MAX44009 (GY-49). Der funktioniert prima, solange der Sensor auf meinem Schreibtisch liegt. Sobald ich ihn nach draußen stelle, kommen erst ein paar höhere Werte im 2000er Bereich, dann nur noch 0-Werte. Hole ich ihn wieder rein, sofort wieder Werte im 300er Bereich. Das habe ich ein paar mal wiederholt und ist reproduzierbar. Die Außentemperatur kann es eigentlich nicht sein (ca. 3° ), weil 1. die Nullwerte kommen, bevor der richtig ausgekühlt ist und 2. plausible Helligkeitswerte sofort kommen sobald er wieder drin ist. Hat jemand eine Idee ? Wie kann ich das Problem am Besten finden/isolieren?
Habe mir mal das Datenblatt und das GY-49 angeschaut - Der Eingang für die Auswahl der Adresse (A0) war offen. Ich habe ihn mal mit GND verlötet und warte nun dass es draußen wieder hell wird.
Danke
Gregor
Klingt seltsam mit dem MAX44009. Ich würde in solchen Fällen mit Notebook und FTDI Adapter rausgehen und mir die Debugwerte der MAX44009 Messungen anschauen ob man da was sieht was draußen anders ist. Und notfalls weitere Debug Ausgaben in der MAX44009 Klasse anlegen um das Problem einzugrenzen.
Gelöst: Ursache für die 0-Werte von MAX44009 war der offene A0 Anschluss. Wenn der Anschluss zu high wechselt (vmtl. durch hohe Luftfeuchtigkeit), können die Werte nicht mehr ausgelesen werden. Ich habe ein Bild mit entsprechendem Hinweis angehängt.
Gruß
Gregor
Interessanter Punkt. A0 muss auf jeden Fall definiertes Potential haben da kein interner pull-up/down vorhanden ist.
Bei meinen MAX44009 Modulen war die Brücke bei Lieferung schon gelötet.
https://raw.githubusercontent.com/TomMajor/AskSinPP_Examples/master/HB-UNI-Sensor1/Images/HB-UNI-Sensor1_HW1.jpg (https://raw.githubusercontent.com/TomMajor/AskSinPP_Examples/master/HB-UNI-Sensor1/Images/HB-UNI-Sensor1_HW1.jpg)
Hallo Gregor,
Zitat von: gregor am 21 Dezember 2018, 10:00:05
Gelöst: Ursache für die 0-Werte von MAX44009 war der offene A0 Anschluss.
gut zu wissen. Ich habe ein paar Module gekauft und mal beim ersten geschaut. Da war die Brücke drin. Bevor ich die anderen einsetze, schaue ich mir das an.
Danke + Gruß
Peter
Ich hab einen Universalsensor von Dirk der viele Jahre alt ist (4?) und ich hab das Problem, dass die Batterie häufig gewechselt werden muss. Ich hatte es mir neulich notiert und da hat ein Satz Batterien nur ca. 6 Wochen gehalten. Ist doch nicht normal oder? Im Moment halten sie etwas länger, aber ich glaube ursprünglich war eine Lebensdauer zwischen 2 und 4 Jahren prognostiziert.
Ich verwende 2 AAA Eneloops. Ich weiß, Akkus sind wohl nicht ideal in dem Zusammenhang, aber es wäre für mich auch ok, wenn die Batterien statt 2 Jahren nur 1 Jahr oder so halten würden. Nur halt 6 - 8 Wochen sind mir dann doch zu wenig.
Ich hab die Akkus neulich mit einem Technoline BC700 refresht und kam auf eine Kapazität von >700 mAH. Der Sensor hat nach meinem Verständis einen StepUp-Wandler, der auch für eine bessere Batterieausnutzung sorgt.
Hat da jemand eine Idee, woran das liegen könnte? Danke!
Zitat von: vbs am 27 Dezember 2018, 11:49:56
Hat da jemand eine Idee, woran das liegen könnte? Danke!
Welche Firmware hast Du drauf? Hast Du den Sensor mit irgendwas gepeert? Ggf. könnte die Platine auch feucht geworden sein und Du hast einen Nebenschluß zu den Akkus.
Wenn Du ein Strommessgerät hast, würde ich mal messen (Standby, bzw. Daten verschicken).
Gruß Peter
Zitat von: vbs am 27 Dezember 2018, 11:49:56
Ich hab einen Universalsensor von Dirk der viele Jahre alt ist (4?) und ich hab das Problem, dass die Batterie häufig gewechselt werden muss. Ich hatte es mir neulich notiert und da hat ein Satz Batterien nur ca. 6 Wochen gehalten. Ist doch nicht normal oder? Im Moment halten sie etwas länger, aber ich glaube ursprünglich war eine Lebensdauer zwischen 2 und 4 Jahren prognostiziert.
Ich verwende 2 AAA Eneloops. Ich weiß, Akkus sind wohl nicht ideal in dem Zusammenhang, aber es wäre für mich auch ok, wenn die Batterien statt 2 Jahren nur 1 Jahr oder so halten würden. Nur halt 6 - 8 Wochen sind mir dann doch zu wenig.
Ich hab die Akkus neulich mit einem Technoline BC700 refresht und kam auf eine Kapazität von >700 mAH. Der Sensor hat nach meinem Verständis einen StepUp-Wandler, der auch für eine bessere Batterieausnutzung sorgt.
Hat da jemand eine Idee, woran das liegen könnte? Danke!
Hast du es mal mit normalen Batterien versucht? Ein Step-Up Wandler kann die Akkus schön tiefenentladen, was sie überhaupt nicht mögen.
Zitat von: vbs am 27 Dezember 2018, 11:49:56
Ich hab einen Universalsensor von Dirk der viele Jahre alt ist (4?) und ich hab das Problem, dass die Batterie häufig gewechselt werden muss. Ich hatte es mir neulich notiert und da hat ein Satz Batterien nur ca. 6 Wochen gehalten. Ist doch nicht normal oder? Im Moment halten sie etwas länger, aber ich glaube ursprünglich war eine Lebensdauer zwischen 2 und 4 Jahren prognostiziert.
Ich verwende 2 AAA Eneloops. Ich weiß, Akkus sind wohl nicht ideal in dem Zusammenhang, aber es wäre für mich auch ok, wenn die Batterien statt 2 Jahren nur 1 Jahr oder so halten würden. Nur halt 6 - 8 Wochen sind mir dann doch zu wenig.
Ich hab die Akkus neulich mit einem Technoline BC700 refresht und kam auf eine Kapazität von >700 mAH. Der Sensor hat nach meinem Verständis einen StepUp-Wandler, der auch für eine bessere Batterieausnutzung sorgt.
Hat da jemand eine Idee, woran das liegen könnte? Danke!
6 Wochen klingt definitiv viel zu wenig. Als Erstes den Ruhestrom messen, der müsste mit Step-Up im Bereich ca. 10-20 uA liegen. Die 6 Wochen lassen einen viel höheren Ruhestrom vermuten.
Danke für die vielen Antworten!
Zitat von: PeMue am 27 Dezember 2018, 11:58:46
Welche Firmware hast Du drauf? Hast Du den Sensor mit irgendwas gepeert? Ggf. könnte die Platine auch feucht geworden sein und Du hast einen Nebenschluß zu den Akkus.
Wenn Du ein Strommessgerät hast, würde ich mal messen (Standby, bzw. Daten verschicken).
Firmware ist die 0.15, gepeert ist nichts. Elektrisch sieht es für mich als Laien unverdächtig aus. Hier mal ein List des Devices:
Internals:
DEF <ID>
HMLAN0_MSGCNT 589
HMLAN0_RAWMSG E0B69DC,0000,6A902015,FF,FFBF,01A2700B69DCF1554400CA00279E0000103F09C4
HMLAN0_RSSI -65
HMLAN0_TIME 2018-12-27 13:53:58
IODev sys_culHm
LASTInputDev HMLAN0
MSGCNT 1163
NAME env_thpl
NOTIFYDEV global
NR 215
NTFY_ORDER 50-env_thpl
STATE T: 20.2 L: 41.59 P: 1014.2
TYPE CUL_HM
lastMsg No:01 - t:70 s:0B69DC d:F15544 00CA00279E0000103F09C4
protLastRcv 2018-12-27 13:53:58
protRcv 576 last_at:2018-12-27 13:53:58
protSnd 588 last_at:2018-12-27 13:53:58
protState CMDs_done
rssi_at_HMLAN0 cnt:589 min:-74 max:-55 avg:-60.22 lst:-65
rssi_at_sys_culHm cnt:574 min:-86 max:-38 avg:-66.31 lst:-38
sys_culHm_MSGCNT 574
sys_culHm_RAWMSG 0501002601A2700B69DCF1554400CA00279E0000103F09C4
sys_culHm_RSSI -38
sys_culHm_TIME 2018-12-27 13:53:58
Helper:
DBLOG:
batVoltage:
benDbLog:
TIME 1545915238.92425
VALUE 2.50
humidity:
benDbLog:
TIME 1545913888.9032
VALUE 73
luminosity:
benDbLog:
TIME 1545915238.92425
VALUE 41.59
pressure:
benDbLog:
TIME 1545915238.92425
VALUE 1014.2
statHumidityDayLast:
benDbLog:
TIME 1545865198.10183
VALUE Min: 78 Avg: 87 Max: 93
statHumidityHourLast:
benDbLog:
TIME 1545911998.07949
VALUE Min: 68 Avg: 70 Max: 71
statLuminosityDayLast:
benDbLog:
TIME 1545865198.10183
VALUE Min: 0.01 Avg: 145.46 Max: 965.00
statLuminosityHourLast:
benDbLog:
TIME 1545911998.07949
VALUE Min: 2201.00 Avg: 2527.11 Max: 2938.00
statPressureDayLast:
benDbLog:
TIME 1545865198.10183
VALUE Min: 1017.3 Avg: 1018.6 Max: 1020.1
statPressureHourLast:
benDbLog:
TIME 1545911998.07949
VALUE Min: 1014.0 Avg: 1014.3 Max: 1014.6
statTemperatureDayLast:
benDbLog:
TIME 1545865198.10183
VALUE Min: 3.7 Avg: 4.7 Max: 5.4
statTemperatureHourLast:
benDbLog:
TIME 1545911998.07949
VALUE Min: 5.5 Avg: 5.6 Max: 5.8
temperature:
benDbLog:
TIME 1545915074.23616
VALUE 20.2
READINGS:
2018-12-26 13:22:32 Activity alive
2016-03-07 18:17:08 CommandAccepted yes
2016-03-08 23:12:03 D-firmware 0.15
2016-03-08 23:23:48 D-serialNr <mySerial>
2016-03-07 18:17:09 PairedTo <HMID>
2016-03-07 18:16:17 R-altitude 0 m
2016-03-07 18:16:17 R-burstRx off
2016-03-07 18:16:17 R-ledMode off
2016-03-07 18:17:09 R-lowBatLimitTHPL 2.1 V
2016-03-07 18:16:17 R-pairCentral 0xF15544
2016-03-07 18:16:17 R-transmDevTryMax 3
2018-12-27 13:53:58 batVoltage 2.50
2018-12-27 13:53:58 battery ok
2016-03-08 23:11:35 fwUpdate fail:notInBootLoader
2018-12-27 13:31:28 humidity 73
2018-12-27 13:53:58 luminosity 41.59
2016-03-08 23:12:03 powerOn 2016-03-08 23:12:03
2018-12-27 13:53:58 pressure 1014.2
2016-03-08 23:12:03 recentStateType info
2018-12-27 13:53:58 statHumidityDay Min: 67 Avg: 86 Max: 93
2018-12-26 23:59:58 statHumidityDayLast Min: 78 Avg: 87 Max: 93
2018-12-27 13:53:58 statHumidityHour Min: 67 Avg: 70 Max: 73
2018-12-27 12:59:58 statHumidityHourLast Min: 68 Avg: 70 Max: 71
2018-12-27 13:53:58 statHumidityMonth Min: 67 Avg: 85 Max: 95
2018-11-30 23:59:58 statHumidityMonthLast Min: 55 Avg: 85 Max: 98
2018-12-27 13:53:58 statHumidityYear Min: 1 Avg: 73 Max: 99
2017-12-31 23:59:58 statHumidityYearLast Min: 28 Avg: 77 Max: 100
2018-12-27 13:53:58 statLuminosityDay Min: 0.00 Avg: 691.32 Max: 3494.00
2018-12-26 23:59:58 statLuminosityDayLast Min: 0.01 Avg: 145.46 Max: 965.00
2018-12-27 13:53:58 statLuminosityHour Min: 27.84 Avg: 1367.98 Max: 2753.00
2018-12-27 12:59:58 statLuminosityHourLast Min: 2201.00 Avg: 2527.11 Max: 2938.00
2018-12-27 13:53:58 statLuminosityMonth Min: 0.00 Avg: 414.94 Max: 4219.00
2018-11-30 23:59:58 statLuminosityMonthLast Min: 0.00 Avg: 647.00 Max: 5183.00
2018-12-27 13:53:58 statLuminosityYear Min: 0.00 Avg: 1673.92 Max: 65535.00
2017-12-31 23:59:58 statLuminosityYearLast Min: 0.00 Avg: 1829.12 Max: 65535.00
2018-12-27 13:53:58 statPressureDay Min: 1013.8 Avg: 1015.7 Max: 1017.6
2018-12-26 23:59:58 statPressureDayLast Min: 1017.3 Avg: 1018.6 Max: 1020.1
2018-12-27 13:53:58 statPressureHour Min: 1013.8 Avg: 1014.0 Max: 1014.2
2018-12-27 12:59:58 statPressureHourLast Min: 1014.0 Avg: 1014.3 Max: 1014.6
2018-12-27 13:53:58 statPressureMonth Min: 978.3 Avg: 1004.4 Max: 1022.0
2018-11-30 23:59:58 statPressureMonthLast Min: 995.2 Avg: 1007.7 Max: 1025.1
2018-12-27 13:53:58 statPressureYear Min: 970.0 Avg: 1004.8 Max: 1238.7
2017-12-31 23:59:58 statPressureYearLast Min: 964.7 Avg: 1005.6 Max: 1032.2
2018-12-27 13:53:58 statTemperatureDay Min: 2.7 Avg: 5.0 Max: 20.2
2018-12-26 23:59:58 statTemperatureDayLast Min: 3.7 Avg: 4.7 Max: 5.4
2018-12-27 13:53:58 statTemperatureHour Min: 5.5 Avg: 10.9 Max: 20.2
2018-12-27 12:59:58 statTemperatureHourLast Min: 5.5 Avg: 5.6 Max: 5.8
2018-12-27 13:53:58 statTemperatureMonth Min: -2.8 Avg: 5.6 Max: 20.2
2018-11-30 23:59:58 statTemperatureMonthLast Min: -3.6 Avg: 6.5 Max: 17.0
2018-12-27 13:53:58 statTemperatureYear Min: -10.7 Avg: 12.0 Max: 124.1
2017-12-31 23:59:58 statTemperatureYearLast Min: -8.4 Avg: 11.3 Max: 33.5
2018-12-27 13:53:58 state T: 20.2 L: 41.59 P: 1014.2
2018-12-27 13:53:58 temperature 20.2
helper:
HM_CMDNR 1
PONtest 1
_98_statistics env_stats
mId F102
regLst ,0
rxType 132
supp_Pair_Rep 0
ack:
bm:
CUL_HM_Attr:
cnt 2
dmx -1000
dtot 0
dtotcnt 0
mTS 27.12. 13:27:23
max 0.0909099578857422
tot 0.0909450054168701
mAr:
set
env_thpl
event-on-change-reading
luminosity,humidity,pressure,temperature,battery
CUL_HM_Get:
cnt 5
dmx -1000
dtot 0
dtotcnt 0
mTS 27.12. 11:11:44
max 0.0090491771697998
tot 0.0101521015167236
mAr:
HASH(0x55c1ab30eb98)
env_thpl
?
CUL_HM_Set:
cnt 979
dmx -1000
dtot 0
dtotcnt 0
mTS 27.12. 03:07:09
max 0.148144006729126
tot 3.15117120742798
mAr:
HASH(0x55c1ab30eb98)
env_thpl
?
expert:
def 1
det 1
raw 0
tpl 0
io:
newChn +0B69DC,00,00,00
nextSend 1545915239.07361
rxt 0
vccu VCCU
p:
<HMID>
00
00
00
prefIO:
sys_culHm
mRssi:
mNo 01
io:
HMLAN0:
-65
-65
sys_culHm:
-30
-30
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf 00
qReqStat 00
role:
chn 1
dev 1
rpt:
IO sys_culHm
flg A
ts 1545915238.89966
ack:
HASH(0x55c1ab30eb98)
018002F155440B69DC00
rssi:
at_HMLAN0:
avg -60.2292020373514
cnt 589
lst -65
max -55
min -74
at_sys_culHm:
avg -66.3101045296167
cnt 574
lst -38
max -38
min -86
tmpl:
Attributes:
IODev HMLAN0
IOgrp VCCU:sys_culHm
actCycle 000:10
actStatus alive
alias THPL-Sensor
autoReadReg 4_reqStatus
event-on-change-reading luminosity,humidity,pressure,temperature,battery
event-on-update-reading stat.*Last,batVoltage
expert 1_allReg
firmware 0.15
group System
icon temp_outside
model HB-UW-Sen-THPL-O
peerIDs 00000000,
room Wetter
serialNr UWS7398093
subType THPLSensorHast du es mal mit normalen Batterien versucht? Ein Step-Up Wandler kann die Akkus schön tiefenentladen, was sie überhaupt nicht mögen.Hatte ich tatsächlich mal versucht, aber war nicht grundlegend anders (evtl. etwas länger). Aber was du sagst ist interessant, da mir aufgefallen ist, dass das BC700 beim Laden der Eneloops die manchmal gar nicht erkennt und ich sie dann mit einem "dummen" Ladegerät ein paar Sekunden vorladen muss, damit sie vom BC700 erkannt werden. Das würde absolut passen zu dem, was zu sagst.
Also schrotte ich die Akkus damit auf Dauer wegen des StepUps? Muss jedoch sagen, dass ich das schon ein paar Jahre so mache und die Eneloops noch bei über 700 mAH sind.
6 Wochen klingt definitiv viel zu wenig. Als Erstes den Ruhestrom messen, der müsste mit Step-Up im Bereich ca. 10-20 uA liegen. Die 6 Wochen lassen einen viel höheren Ruhestrom vermuten.Habe gesehen, dass ich jahrelang brav die Batteriespannugn in die Datenbank geschrieben habe. Anbei mal ein Plot davon. Da kann man die 6 Wochen ganz gut sehen. Also es sind immer so zwischen 4 und 8 Wochen.
Ich hoffe, ich hab nix falsch gemacht: Ich komme beim Messen mit Multimeter auf 1660 uA im Idle :o Musste Skala auf "mA" stellen, mit "uA" hat der Controller nicht gestartet bzw. nicht geblinkt beim Herstellen der Verbindung (sorry, bin Noob). Das kommt von der Größenordnung ganz gut hin, wenn ich eine Batteriekapazität von ca. 1500 mAH annehme. Komme dann ca. 40 Tage raus. Und da ist noch nicht der erhöhte Strom beim Senden drin.
Scheint also wirklich so zu sein, dass er einen sehr hohen Idle-Strom hat. Hat jemand eine Idee wie sowas kommen kann? :-\
Zitat von: vbs am 27 Dezember 2018, 14:13:12
Ich hoffe, ich hab nix falsch gemacht: Ich komme beim Messen mit Multimeter auf 1660 uA im Idle :o Musste Skala auf "mA" stellen, mit "uA" hat der Controller nicht gestartet bzw. nicht geblinkt beim Herstellen der Verbindung (sorry, bin Noob). Das kommt von der Größenordnung ganz gut hin, wenn ich eine Batteriekapazität von ca. 1500 mAH annehme. Komme dann ca. 40 Tage raus. Und da ist noch nicht der erhöhte Strom beim Senden drin.
Scheint also wirklich so zu sein, dass er einen sehr hohen Idle-Strom hat. Hat jemand eine Idee wie sowas kommen kann? :-\
Hmm, das er überhaupt nicht in den sleep geht kann es wahrscheinlich nicht sein, da müssten schon 3mA fließen und nicht 1,6.
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Ruhestrom#%C3%BCberpr%C3%BCfung-des-ruhestroms (https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Ruhestrom#%C3%BCberpr%C3%BCfung-des-ruhestroms)
Irgendwas zieht "Nebenstrom", systematisch I/O pins, Sensoren usw. prüfen so weit möglich.
Edit: Gut wäre auch eine Vergleichsmessung mit einem zweitem Sensor falls vorhanden und eine Messung ohne Step-Up um dort Fehler auszuschließen.
Hm ok danke, da muss ich dann mal tiefer einsteigen. Heißt ja vermutlich, die Sensoren entweder mal ganz ablöten oder so ablöten, dass man dazwischen Strom messen kann? Im Idealfall so, dass ich es hinterher auch wieder zusammen bekomme. ::)
Ich spekulier mal so rum: kann wohl kein Problem mit der Firmware sein? Die Firmware sollte sich ja für alle Benutzer identisch verhalten (bei gleichem Hardwareaufbau, was ich mal voraus setze). Könnte es was mit den Fuses zu tun haben? Die sind ja sozusagen auch Software und wenn ich mich recht erinnere, dann sind die unabhängig von der Firmware.
Zur Hardware: klar, einen Kurzschluss irgendwo könnte ich mir auch als Erklärung vorstellen, aber dann würde der Sensor doch auch zumindest teilweise nicht funktionieren? Ist ein Bauteildefekt denkbar, der zu dem Stromverbrauch führt, aber trotzdem zu keiner Fehlfunktion?
EDIT:
Zweitsensor hab ich leider nicht.
Zum Beispiel: ich hab damals vor Jahren ein bisschen mit dem Board rumdebuggt. Das hab ich damals mit deinem AVR Dragon gemacht. Ich meine über debugWire. Das wiederum muss man ja per Fuse erst aktivieren. Könnte mir vorstellen, dass ich das nie wieder ausgeschaltet habe 8)
debugWIRE und Sleepmode
Bei eingeschaltetem debugWIRE sind die Sleepmodes unwirksam. Es lässt sich zwar das richtige Verhalten, z.B. die Funktion des Timer2 mit einem Uhrenquarz im Power Save, beobachten. Der Stromverbrauch wird jedoch nicht gesenkt! Eine Messung des Stroms führt somit nicht zu praxisgerechten Ergebnissen.
https://www.mikrocontroller.net/articles/DebugWIRE
Blöd, Fuses sehen leider ok aus mMn... DebugWire ist nicht an. Ich fand das so plausibel >:(
Zitat von: vbs am 27 Dezember 2018, 15:56:44
Hm ok danke, da muss ich dann mal tiefer einsteigen. Heißt ja vermutlich, die Sensoren entweder mal ganz ablöten oder so ablöten, dass man dazwischen Strom messen kann? Im Idealfall so, dass ich es hinterher auch wieder zusammen bekomme. ::)
Ich spekulier mal so rum: kann wohl kein Problem mit der Firmware sein? Die Firmware sollte sich ja für alle Benutzer identisch verhalten (bei gleichem Hardwareaufbau, was ich mal voraus setze). Könnte es was mit den Fuses zu tun haben? Die sind ja sozusagen auch Software und wenn ich mich recht erinnere, dann sind die unabhängig von der Firmware.
Zur Hardware: klar, einen Kurzschluss irgendwo könnte ich mir auch als Erklärung vorstellen, aber dann würde der Sensor doch auch zumindest teilweise nicht funktionieren? Ist ein Bauteildefekt denkbar, der zu dem Stromverbrauch führt, aber trotzdem zu keiner Fehlfunktion?
EDIT:
Zweitsensor hab ich leider nicht.
Da du SMD Sensoren hast, würde ich die als Letztes ablöten da nicht so einfach wieder draufzubekommen ;) , glaub auch nicht das es daran liegt.
Ich kenne die Firmware 0.15 nicht, geht die auch sicher in den sleep? Da wäre ein 2. Gerät zum Vergleichen ideal gewesen.
Fuses sehen gut aus.
Ich würde wahrscheinlich als Erstes am Step-Up suchen, den testweise deaktivieren und mit 3V direkt den Strom messen..
Hallo,
habe auch 3 von den Sensoren.
2 mit der Firmware 0.12 und einen mit 0.14.
Bei den beiden mit der 0.12 Firmware sind auch nach 6 Wochen die Batterien leer.
Wenn man den Sensor jedoch vorher kurz stromlos macht, also kurz eine Batterie raus und wieder rein, halten die Batterien mehrere Monate.
Es sieht so aus, als ob der Sensor sich nach ca. 6 Wochen ,,aufhängt".
Habe es bisher auch nicht geschafft die Firmware zu aktualisieren.
Gruß Holger
der fehler wurde aber in fw0.14 behoben, und sollte damit auch in 0.15 nicht vorhanden sein.
ZitatBugfixes:
Fix millis() overflow bug. Now, the sensor stays in sleep mode after 49 days, so battery should not drained anymore
ich habe bei meinem sensor mit fw0.14 aber auch den eindruck, dass der batterieverbrauch gegenüber früher gestiegen ist. allerdings habe ich nur vermutungen, da ich in diesem sensor, wegen dem stepup, immer altbatterien, die in anderen devices bereits low gezeigt haben, noch ziehmlich lange nutzen konnte. das nicht funktionierende reading poweron macht eine analyse auch nicht einfacher.
der aktuelle batteriesatz, neue billigbatterien vom discounter, ist bereits nach 11,5 tagen von 3,3v auf 2,8v gesunken. das ist jedenfalls zu viel.
erste auffälligkeiten habe ich seit oktober wahrgenommen. da der sensor aussen unter einem dachvorsprung hängt, habe ich erst tiefe temperaturen und andauernde hohe luftfeuchtigkeit als ursachen in erwägung gezogen. aber das hätte mir früher dann eigentlich auch schon auffallen müssen. damals waren die batterien aber noch von einem anderen discounter.
beim batteriewechsel ist mir auch keine besondere feuchtigkeit im gehäuse aufgefallen.
ein zweiter sensor ist bereits vor ca. 1,5 jahren an selber position verstorben. bei dem habe ich den stepup im verdacht, habe aber noch keine zeit und lust verspürt das genau zu untersuchen.
scheinbar wird es nun dringend nötig, denn einen 3. sensor habe ich nicht mehr.
edit:
mein sensor ist ein vollbestückter universalsensor für innen.
model: HB-UW-Sen-THPL-I
Mir ist eingefallen, dass ich gelogen hab: ich hab doch einen Zweitsensor ::)
Innensensor der sein Dasein vergessen im Kühlschrank fristet... Ist auch Firmware 0.15. Da halten die Batterien tatsächlich mehrer Jahre (siehe Plot), jedoch zwei AA (anstatt zwei AAA). Und ich hab den Strom gemessen im Idle und messe tatsächlich nur ca. 20 uA (anstatt 1600 uA wie bei meinem Außensensor).
Also einen generellen Firmware-Bug in der 0.15 würde ich damit ausschließen.
Hallo vbs,
Zitat von: Tom Major am 27 Dezember 2018, 23:58:05
Ich würde wahrscheinlich als Erstes am Step-Up suchen, den testweise deaktivieren und mit 3V direkt den Strom messen..
speise doch einfach mal ca. 3 V (zwei Batterien oder vollgeladene Akkus) an dem Ausgangspin von SJ2 (befindet sich oben, wenn der Prozessor nach unten zeigt) ein, und miss mal den Strom. Damit überbrückst Du den Schaltregler, der die Rückwärtsversorgung aushält ohne kaputt zu gehen. Damit kannst Du sehen, ob das Problem vor oder hinter dem Schaltregler liegt.
Gruß Peter
Danke für die Tipps! Klar, probier ich gerne aus.
Eine Frage (bevor was kaputt geht): ein "SJ2" kann ich nicht finden, wohl aber ein "SJ1" (beziehe mich auf https://github.com/kc-GitHub/Wettersensor/blob/master/Schematic/Wetter-Sensor_Atmega328%20Out%201.1.brd).
So wie ich das verstehe, sind das zwei Pads, die nicht bestückt sind und die ich einfach brücken kann (im Bild markiert)?
Zitat von: vbs am 28 Dezember 2018, 11:52:51
Mir ist eingefallen, dass ich gelogen hab: ich hab doch einen Zweitsensor ::)
Innensensor der sein Dasein vergessen im Kühlschrank fristet... Ist auch Firmware 0.15. Da halten die Batterien tatsächlich mehrer Jahre (siehe Plot), jedoch zwei AA (anstatt zwei AAA). Und ich hab den Strom gemessen im Idle und messe tatsächlich nur ca. 20 uA (anstatt 1600 mA wie bei meinem Außensensor).
Also einen generellen Firmware-Bug in der 0.15 würde ich damit ausschließen.
ja, 20 uA klingen wirklich ok, ist zwar nicht das Beste was man erreichen kann ;), aber wahrscheinlich liegt es an den verbauten Sensoren und würde das Batterieproblem für den anderen Sensor lösen.
Zitat von: vbs am 28 Dezember 2018, 12:36:15
Eine Frage (bevor was kaputt geht): ein "SJ2" kann ich nicht finden, wohl aber ein "SJ1" (beziehe mich auf https://github.com/kc-GitHub/Wettersensor/blob/master/Schematic/Wetter-Sensor_Atmega328%20Out%201.1.brd).
So wie ich das verstehe, sind das zwei Pads, die nicht bestückt sind und die ich einfach brücken kann (im Bild markiert)?
Du hast noch die v1.0, dann ist das SJ1. Ich hatte die v1.2 angeschaut, da heißt der Lötjumper SJ2.
Ja, passt.
Gruß Peter
Hm, also ich krieg's nicht hin :-\ Ich hab zwei nagelneue Batterien genommen (messe 3,1 V) und SJ1 gebrückt. Wenn ich die Batterien normal einlege, dann bootet er normal und blinkt. Aber immer wenn ich das Multimeter dazwischen setze zur Strommessung, dann bootet er nicht mehr. Multimeter ist auf "mA" eingestellt und ich messe dann ca. 170 mA.
Hab auch die Gegenprobe gemacht und die Brücke wieder geöffnet. Dann bootet er auch während Strommessung und ich hab wieder meine 1,5 mA. Dann Brücke wieder auf gemacht und bootet wieder nicht mehr mit Multimeter.
Heißt das jetzt irgendwas? Oder liegt's an mir?
Zitat von: vbs am 28 Dezember 2018, 13:06:56
Hm, also ich krieg's nicht hin :-\ Ich hab zwei nagelneue Batterien genommen (messe 3,1 V) und SJ1 gebrückt.
Nicht brücken, sondern den Pluspol der Batterien an den oberen Pol von SJ1 anlöten. Damit hat der DC/DC-Wandler primärseitig keine Spannung und wird sekundärseitig durch die Batterien versorgt (was er abkönnen sollte). Brücken mit eingelöteten DC/DC-Wandler könnte diesen zerstören :o.
Gruß Peter
Nach meinem Verständnis ist der unteren Pol von SJ1 ja sowieso Bat+, aber ich glaube, jetzt weiß ich was du meinst: keine _zusätzliche_ Verbindung von Bat+ zu oberem Pol von SJ1, sondern _anstatt_ der "normalen" Bat+-Verbindung, richtig? Sorry, hätte wahrscheinlich klar sein sollen.
Anyway, wenn ich das mache (also Bat+ _nur_ mit oberem Pol von SJ1 verbinde) dann bootet der Controller korrekt (also blinkt) und ich kann auch Strom messen. Aber ich messe um 990 uA. Also zwar um einiges weniger als vorher (~ 1600 uA), aber wohl immer noch viel zu viel.
Hallo vbs,
schau mal mit einer Lupe, ob Du irgendwo "Schmodder" auf der Leiterplatte (https://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=111496;image) hast. Ggf. ist die Platine mal feucht geworden und es gibt einen Nebenschluss auf der Versorgungsleitung vor dem Controller. Der DC/DC Wandler scheint wohl i.O. zu sein.
Gruß Peter
Habe leider nichts finden können, was so für mich so richtig verdächtig aussah. Hab trotzdem die komplette Platine einmal gereinigt, aber leider bisher keine Besserung :(
Hab mal versucht, ein paar aussagekräftige Bilder zu machen, vielleicht fällt euch ja etwas auf:
https://drive.google.com/drive/folders/1eUTlh_NMhROwt56UXsP6S4Fj1QlaTuJH?usp=sharing
Die Fussel kommen offenbar von den Q-Tips, die ich zum Reinigen benutzt habe. Offenbar nicht die beste Methode.
Rechts neben dem Helligkeitssensor ist es auf den Bildern noch etwas schmierig. Das hab ich dann auch noch entfernt.
Du könntest noch mal per ISP den 20uA und den 1600uA Sensor vergleiche, Fuses und Flash/Programm, ob wirklich alles SW-mäßig identisch ist.
Hallo Tom,
zum Thema Bauelemente und Batteriespannungsmessung Option 3 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT#spezielle-bauelemente):
Ginge auch ein IRLML2402 (https://www.infineon.com/cms/de/product/power/mosfet/20v-300v-n-channel-power-mosfet/20v-30v-n-channel-power-mosfet/irlml2402/) als Schalttransistor für einen NiCD oder NiMH Akku?
Danke + Gruß
Peter
Zitat von: PeMue am 29 Dezember 2018, 17:14:57
Hallo Tom,
zum Thema Bauelemente und Batteriespannungsmessung Option 3 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT#spezielle-bauelemente):
Ginge auch ein IRLML2402 (https://www.infineon.com/cms/de/product/power/mosfet/20v-300v-n-channel-power-mosfet/20v-30v-n-channel-power-mosfet/irlml2402/) als Schalttransistor für einen NiCD oder NiMH Akku?
Danke + Gruß
Peter
Gate Threshold Voltage passt.
Das Einzige wäre der Fehler bei der ADC Messung durch das RDSon von ca. 0,35 Ohm in Bezug auf R2/R3, aber das hatte ich ja geschrieben. In deinem Fall, 1% Fehler durch RDSon ist sicher kein Thema, der ADC Fehler ist eventuell sogar noch größer. Hängt halt von der R2/R3 Dimensionierung und dem gewünschten Messstrom ab.
Hallo vbs,
Zitat von: vbs am 29 Dezember 2018, 12:15:59
Hab mal versucht, ein paar aussagekräftige Bilder zu machen, vielleicht fällt euch ja etwas auf:
https://drive.google.com/drive/folders/1eUTlh_NMhROwt56UXsP6S4Fj1QlaTuJH?usp=sharing
ggf. den Lötspritzer mit einer feinen Pinzette oder einem Skalpell zwischen Pin 22 und 23 entfernen. Ich glaube nicht, dass die hohe Stromaufnahme daher kommt. Ansonsten finde ich Tom's Vorschlag gut. Allerdings erklärt das nicht, dass der Sensor die ganze Zeit mit niedriger Stromaufnahme funktioniert hat :o
Gruß Peter
Hab die Brücke zwischen Pins schon entfernt. Die waren tatsächlich verbunden laut Multimeter. Hat aber hat leider nicht geholfen (wie du auch vermutet hast). Hatte mir da wirklich Hoffnung gemacht :(
Hab auch heute nochmal die komplette Software inkl. Bootloader neu geflasht per ISP und dann per OTA. Aber: keine Änderung :(
Bin langsam etwas frustriert... :-[ keine Ahnung was es noch sein könnte... zwischendurch hat es oben in der Ecke beim StepUp auch schon mal etwas Rauchentwicklung gegeben, aber jetzt funktioniert er komischerweise wieder. Aber ist sicher erstmal auch nicht ideal.
Tja, noch jemand Ideen? Mir fallen sonst nur so komische Sachen ein wie "der Atmel muss wohl 'ne Macke haben"...
Mal ne doofe Frage, so ein Mega328P bei Ali:
https://de.aliexpress.com/item/1-st-cke-ATMEGA328P-AU-QFP32-ATMEGA328P-AU-TQFP32-MCU-8BIT-32KB-FLASH-neue-original-IC/32848187293.html?spm=a2g0x.search0104.3.22.219c2d25b2WdsJ&ws_ab_test=searchweb0_0%2Csearchweb201602_5_10320_10065_10068_10547_319_317_10548_10696_453_10084_454_10083_10618_10304_10307_10820_10821_538_537_10302_536_10843_10059_10884_10887_100031_10319_321_322_10103%2Csearchweb201603_2%2CppcSwitch_0&algo_pvid=f503efaf-ca64-4a96-a1db-a299ef268265&algo_expid=f503efaf-ca64-4a96-a1db-a299ef268265-3
Ist das ein Nachbau? Ohne Atmel-Logo und co.? Ist das legal?
Hallo vbs
Zwei Ideen zur Fehlersuche:
1. Prüfen, ob der Spannungsteiler für die Batteriespannungsmessung abgeschaltet ist und nur für die Messung aktiviert wird.
2. Platinen mal beide nebeneinander mit IR beobachten. Irgendwo muß der Strom ja punktuell in Wärme umgesetzt werden.
Hallo vbs,
Zitat von: vbs am 30 Dezember 2018, 13:02:10
Bin langsam etwas frustriert... :-[ keine Ahnung was es noch sein könnte... zwischendurch hat es oben in der Ecke beim StepUp auch schon mal etwas Rauchentwicklung gegeben, aber jetzt funktioniert er komischerweise wieder. Aber ist sicher erstmal auch nicht ideal.
bekommst Du den MAX1824 zerstörungsfrei runtergelötet? Nicht, dass der eine Macke hat und auch beim "rückwärtsbestromen" Strom zieht. Das wäre ggf. noch eine Möglichkeit.
Aber zuerst würde ich Gernotts Vorschlag umsetzen (Aktivierung Spannungsmess-Pin), ggf. mit IR beobachten (falls machbar).
Zitat von: vbs am 30 Dezember 2018, 13:02:10
Ist das ein Nachbau? Ohne Atmel-Logo und co.? Ist das legal?
Ohne Logo vermutlich nicht, aber da gab es eine Änderung in der Beschriftung (https://forum.fhem.de/index.php/topic,94778.0.html).
Gruß Peter
Hi Ihr,
danke euch für die Tipps. Also eine Wärmebildkamera habe ich leider nicht, aber das wäre in der Tat ne tolle Sache.
Zu dem Spannungsteiler hab ich etwas gegoogelt... ist offenbar der gängige Weg um eine Spannungsmessung zu bauen. So... also R2 und R3 bilden wohl den Spannungsteiler. Gemessen wird an Pin 24 vom Atmel (Signal A1). Damit man nicht ständig Strom verbraucht, wird dann die Spannungsmessung nur kurzzeitig aktiviert. Hm, passiert wohl über Pin 7 11 (Signal D7). Und da ist die Frage, ob evtl. diese Spannungsmessung fälschlicherweise ständig aktiv ist? Bin ich da auf dem richtigen Weg?
Nur wie prüfe ich das... An dem Mess-Pin 24 darf nur eine Spannung anliegen, wenn gerade gemessen wird, sprich, ich messe da mal die Spannung und wenn ich da dauerhaft eine Spannung sehe, dann ist was faul?
Sorry für die Fragen, bin da nicht so der Fitteste... volles Verständnis falls ihr keine Lust mehr habt. :)
Fürs StepUp ablöten und später wieder anlöten (intakt) würde ich mir ein ca. 70%-Chance geben (aufgerundet)... würde ich trotzdem mal probieren wenns sein muss.
Also ich hab mal gemessen:
U-BAT: 2,45 V
A1: 2,34 V
D7: 2,32 V
A1 ist das Signal, welches auch an Pin 24 anliegt und gemessen wird. Die genannten Spannungen messe ich dauerhaft.
Bin mir nicht sicher, was das jetzt aussagt bzw. ob ich jetzt überhaupt was sinnvolles gemacht habe.
Hallo vbs,
Zitat von: vbs am 30 Dezember 2018, 15:35:28
D7: 2,32 V
das passt, denn zur Messung wird D7 auf Masse gelegt, dann müsste an A1 die geteilte Spannung anliegen, sprich:
A1 = Ubat*100/570Insofern alles ok. Ich schau mal, ob wir im Büro eine Wärmebildkamera haben, dauert aber etwas ...
Gruß Peter
Wenn die R2/3 Werte so wie im Schaltplan sind, 470k und 100k, kann die Batt.messung nicht für den hohen Strom verantwortlich sein.
Worst case, A1 und D7 sind auf Masse, dann fließen da ca. 6uA bei 3V, also keine Erklärung für die 1600 uA.
Vorausgesetzt Fuses und Firmware passen, aus meiner Sicht wären Step-Up und Sensoren die nächsten Kandidaten.
Step-Up würde ich testweise rauslöten, das sollte bei einem SOT23-5 machbar sei.
Für die Sensoren findet sich vielleicht eine Leiterbahn, die diese mit 3V versorgt, die man testweise durchtrennen könnte um dann den Strom zu checken und danach wieder zusammenlöten.
Habe mir aber das alte Layout nicht angeschaut, vielleicht findet sich eine solche Stelle.
Hallo,
Zitat von: Tom Major am 19 Dezember 2018, 01:02:27
Ich habe MAX1724 mit 3,0V Ausgangsspannung im Einsatz, deswegen die 3000, aber klar bei 3,3V Ausgangsspannung natürlich dann 3300.
ich habe mir den Quellcode noch einmal angeschaut und versucht zu verstehen ::).
Ist das richtig, dass beim BatterySensor zuerst die Versorgungsspannung gegen die interne Referenz gemessen wird und danach die Batteriespannung? Über den Quotient und den Widerstandsteiler wird dann die Batteriespannung errechnet? Das ist dann der Grund, warum man die Ausgangsspannung als Wert übergibt und nicht die Eingansspannung?
Danke + Gruß
Peter
So, hab den StepUp runter bekommen (ging eigentlich ganz gut). Aber: keine Änderung :( Messe jetzt wieder ~770 uA (wie neulich bei Umgehung des StepUp).
Ist das eigentlich erklärbar, dass der Stromverbrauch ohne StepUp von 1600 uA auf 770 uA sinkt? Ich meine, das sind ja Welten, wenn der erwartete Verbrauch insgesamt bei ca. 20 uA liegt. Dass der StepUp 800 uA saugt, ist doch schon schrecklich, oder?
Jetzt wird die Luft wohl langsam dünn :/ Sensoren oder aber der Atmel an sich? ::)
nach den messungen würde ich tippen, dass die kondensatoren eine macke haben.
c8 ist aus dem spiel, daher die verbesserung auf 770uA.
da c9 der gleiche kondensator ist, vermute ich hier die restlichen 750uA, die noch zuviel sind. vielleicht auch zusammen mit c10.
ich frage mich nur, woran die kaputt gegangen sein könnten.
ich würde als nächstes c9 entfernen und messen.
Hab ich direkt gemacht.... aber... man ahnt es schon... 8)
Also C9 auslöten bringt keine Änderung (weiterhin 770 uA). C10 hab ich nicht, so wie ich das verstehe (beziehe mich auf "Wetter-Sensor_Atmega328 Out 1.1.brd", wobei auf dem Board in Eagle dann 1.2 steht und meinem Board in echt "1.0" steht).
Ich habe auch C8 wieder aktiviert, um zu prüfen, ob er wirklich verantwortlich für die vorherige Stromabsenkungen war. Aber auch da: den GND-Ping von C8 verbunden aber trotzdem weiterhin 770 uA (hätte man jetzt eine Erhöhung wieder auf 1600 uA erwarten können). Scheint also zumindest mit C8 nichts zu tun haben.
schade eigentlich.
ZitatIch habe auch C8 wieder aktiviert, um zu prüfen, ob er wirklich verantwortlich für die vorherige Stromabsenkungen war. Aber auch da: den GND-Ping von C8 verbunden aber trotzdem weiterhin 770 uA (hätte man jetzt eine Erhöhung wieder auf 1600 uA erwarten können). Scheint also zumindest mit C8 nichts zu tun haben.
das verstehe ich noch nicht ganz.
ich schaue in dirks schaltplan pdf, kleine platine ganz am ende, von hier: https://github.com/kc-GitHub/Wettersensor/blob/master/Schematic/Schematic-RF.pdf?raw=true (https://github.com/kc-GitHub/Wettersensor/blob/master/Schematic/Schematic-RF.pdf?raw=true)
ist zwar rev1.1, aber um den stepup sieht es so aus, wie bei deinem photo aus beitrag #2643.
zum testen von c8 hast du also die batterie wieder "normal" eingespeist? und der stepup ist aber noch draussen?
Du hast recht, C10 existiert. Offenbar nicht mehr in 1.2, aber die hab ich ja auch nicht. Also C10 kommt morgen an die Reihe ;)
Ansonsten ist mein Setup so (gewesen):
- StepUp rausgenommen
- C9 rausgenommen
-> Strom 770 uA
In dem Zustand hab ich dann den rechten Pin von C8 nach links mit dem unteren Batterie-Pin (GND) verbunden. Mein Ziel war, dass er damit wieder in Betrieb war und evtl. dann wieder die erhöhte Stromaufnahme hätte erzeugen sollen.
Ich lasse mich da aber gerne korrigieren.
Wünsche erstmal einen guten Rutsch!
Also C10 nun auch raus, aber keine Änderung. Weiterhin 770 uA.
Sieht jetzt recht kahl da oben aus...
Zitat von: Tom Major am 19 Dezember 2018, 01:05:11
Ich würde in solchen Fällen immer erst mal auf die serielle Debugausgabe über FTDI im Arduino Serial Monitor schauen. Kommen die Init Meldungen der AskSinPP? Werden alle Sensoren erkannt und kommen Messwerte?
Hallo Tom,
ich bin jetzt erst dazu gekommen, das mal zu überprüfen. Ich habe den selben Sensor einmal mit der alten 0.15 FW geflashed und einmal mit der neuen 1.2 FW.
Mit der 0.15er Firmware bekomme ich alle Sensordaten - Hardware ist also i.O.
List des Devices mit 0.15 FW
Internals:
CFGFN
DEF E2DF18
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 22
NAME HM_E2DF18
NOTIFYDEV global
NR 41
STATE T: 24.1 H: 33 L: 0.97 P: 1024.9
TYPE CUL_HM
lastMsg No:0B - t:70 s:E2DF18 d:F11234 00F1212809000000610DAC
nanoCUL_MSGCNT 22
nanoCUL_RAWMSG A140BA270E2DF18F1123400F1212809000000610DAC::-26.5:nanoCUL
nanoCUL_RSSI -26.5
nanoCUL_TIME 2019-01-03 09:21:08
protLastRcv 2019-01-03 09:21:08
protRcv 22 last_at:2019-01-03 09:21:08
protSnd 27 last_at:2019-01-03 09:21:08
protState CMDs_done
rssi_at_nanoCUL cnt:22 min:-32.5 max:-26.5 avg:-28.86 lst:-26.5
READINGS:
2019-01-03 08:58:37 Activity alive
2019-01-03 08:58:11 CommandAccepted yes
2019-01-03 08:58:37 D-firmware 0.15
2019-01-03 08:58:37 D-serialNr CCV7907987
2019-01-03 08:58:38 PairedTo 0xF11234
2019-01-03 08:58:34 R-burstRx off
2019-01-03 08:58:34 R-pairCentral 0xF11234
2019-01-03 08:58:38 RegL_00. 00:00 01:00 05:64 0A:F1 0B:12 0C:34 12:10 14:03 24:00 25:00
2019-01-03 09:21:08 batVoltage 3.50
2019-01-03 09:21:08 battery ok
2019-01-03 09:21:08 humidity 33
2019-01-03 09:21:08 luminosity 0.97
2019-01-03 08:58:33 powerOn 2019-01-03 08:58:33
2019-01-03 09:21:08 pressure 1024.9
2019-01-03 08:58:37 recentStateType info
2019-01-03 09:21:08 state T: 24.1 H: 33 L: 0.97 P: 1024.9
2019-01-03 09:21:08 temperature 24.1
helper:
HM_CMDNR 11
PONtest 0
cSnd 01F11234E2DF1800040000000000,01F11234E2DF180103
mId F102
peerIDsRaw ,00000000
regLst ,0
rxType 156
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +E2DF18,00,00,00
nextSend 1546503668.23117
prefIO
rxt 2
vccu
p:
E2DF18
00
00
00
mRssi:
mNo 0B
io:
nanoCUL:
-18.5
-18.5
prt:
bErr 0
sProc 0
sleeping 1
try 1
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rpt:
IO nanoCUL
flg A
ts 1546503668.13194
ack:
HASH(0x5587674bdd20)
0B8002F11234E2DF1800
rssi:
at_nanoCUL:
avg -28.8636363636364
cnt 22
lst -26.5
max -26.5
min -32.5
shadowReg:
Attributes:
IODev nanoCUL
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 0.15
model HB-UW-Sen-THPL-O
peerIDs 00000000,
room CUL_HM
serialNr CCV7907987
subType THPLSensorDen selben Sensor habe ich dann mit folgenden defines kompiliert und geflashed
//#define SENSOR_DS18X20
//#define SENSOR_BME280
#define SENSOR_BMP180
#define SENSOR_TSL2561
//#define SENSOR_MAX44009
#define SENSOR_SHT10
//#define SENSOR_DIGINPUTDas Gerät lies sich einwandfrei anlernen und die Sensordaten kommen alle auch - nur nicht die des TSL2561
List des Devices mit 1.2 FW
Internals:
CFGFN
DEF 3CE50C
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 33
NAME HM_3CE50C
NOTIFYDEV global
NR 78
STATE T: 24.3 P: 1024.8 H: 33 B: 0 I: 0
TYPE CUL_HM
lastMsg No:05 - t:70 s:3CE50C d:F11234 00F328082100000000000C80
nanoCUL_MSGCNT 33
nanoCUL_RAWMSG A150584703CE50CF1123400F328082100000000000C80::-36:nanoCUL
nanoCUL_RSSI -36
nanoCUL_TIME 2019-01-03 09:41:01
protLastRcv 2019-01-03 09:41:01
protRcv 33 last_at:2019-01-03 09:41:01
protResnd 4 last_at:2019-01-03 09:27:36
protSnd 23 last_at:2019-01-03 09:37:39
protState CMDs_done
rssi_at_nanoCUL cnt:33 min:-42 max:-23 avg:-26.63 lst:-36
rssi_nanoCUL cnt:2 min:-120 max:-119 avg:-119.5 lst:-119
READINGS:
2019-01-03 09:32:29 Activity alive
2019-01-03 09:26:41 CommandAccepted yes
2019-01-03 09:32:29 D-firmware 1.2
2019-01-03 09:32:29 D-serialNr UXA8507754
2019-01-03 09:29:45 PairedTo 0xF11234
2019-01-03 09:26:12 R-pairCentral 0xF11234
2019-01-03 09:29:44 RegL_00. 00:00 05:40 0A:F1 0B:12 0C:34 12:15 14:06 20:00 21:3C 22:00 23:00
2019-01-03 09:41:01 batVoltage 3.20
2019-01-03 09:41:01 battery ok
2019-01-03 09:41:01 brightness 0
2019-01-03 09:41:01 digitalInput 0
2019-01-03 09:41:01 humidity 33
2019-01-03 09:26:12 powerOn 2019-01-03 09:26:12
2019-01-03 09:41:01 pressure 1024.8
2019-01-03 09:27:32 recentStateType info
2019-01-03 09:41:01 state T: 24.3 P: 1024.8 H: 33 B: 0 I: 0
2019-01-03 09:41:01 temperature 24.3
helper:
HM_CMDNR 5
PONtest 1
cSnd 01F112343CE50C00040000000000,01F112343CE50C0103
mId F103
peerIDsRaw ,00000000
regLst ,0
rxType 156
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +3CE50C,00,00,00
nextSend 1546504861.54269
prefIO
rxt 2
vccu
p:
3CE50C
00
00
00
mRssi:
mNo 05
io:
nanoCUL:
-28
-28
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rssi:
at_nanoCUL:
avg -26.6363636363636
cnt 33
lst -36
max -23
min -42
nanoCUL:
avg -119.5
cnt 2
lst -119
max -119
min -120
shadowReg:
Attributes:
IODev nanoCUL
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.2
model HB-UNI-Sensor1
peerIDs 00000000,
room CUL_HM
serialNr UXA8507754
subType UniSensor1Ich wollte das dann über die Serielle Konsole debuggen, bekomme aber nur Zeichensalat, egal wie viel Baud ich angebe.
Zitat von: vbs am 01 Januar 2019, 12:00:10
Also C10 nun auch raus, aber keine Änderung. Weiterhin 770 uA.
Sieht jetzt recht kahl da oben aus...
Was du noch versuchen könntest bevor du weiter ablötest oder trennst:
Mit einem Multimeter alle Pegel der 32 AVR pins beim 20uA device und beim 1600 uA device vergleichen. Dann bei Auffälligkeiten die pins näher untersuchen die Abweichungen zeigen. Keine Garantie dass es was bringt, könnte aber. Macht nur Sinn wenn du 100% sicher bist die gleiche SW auf beiden Geräten zu haben.
Danach wie gesagt meinen Vorschlag mit dem Abtrennen der Sensoren über Leiterbahn falls möglich.
Zitat von: Kai-Alfonso am 03 Januar 2019, 09:46:41
Hallo Tom,
ich bin jetzt erst dazu gekommen, das mal zu überprüfen. Ich habe den selben Sensor einmal mit der alten 0.15 FW geflashed und einmal mit der neuen 1.2 FW.
Ich wollte das dann über die Serielle Konsole debuggen, bekomme aber nur Zeichensalat, egal wie viel Baud ich angebe.
Hast du 57600 Baud versucht? Und hast du RC-Osz. oder Quarz als Haupttaktgeber?
Wenn serieller Debug gehen würde würdest du direkt die Meldung "TSL2561 found" bzw. "Error: TSL2561 not found" sehen.
Außerdem ist bei mir
#define TSL2561_ADDR TSL2561_ADDR_FLOAT
definiert, auf welchem Pegel liegt der Adress-Eingang des TSL2561 bei dir?
Zitat von: Tom Major am 03 Januar 2019, 12:03:19
Hast du 57600 Baud versucht? Und hast du RC-Osz. oder Quarz als Haupttaktgeber?
Wenn serieller Debug gehen würde würdest du direkt die Meldung "TSL2561 found" bzw. "Error: TSL2561 not found" sehen.
Außerdem ist bei mir
#define TSL2561_ADDR TSL2561_ADDR_FLOAT
definiert, auf welchem Pegel liegt der Adress-Eingang des TSL2561 bei dir?
Hi Tom,
Wenn ich das richtig sehe, dann ich der Adress Pin mit GND verbunden - laut Datasheet müsste das dann Adresse 0101001 sein, sofern ich das richtig verstanden habe, wie die Adressen im Sensor selektiert werden.
define TSL2561_ADDR TSL2561_ADDR_FLOAT ist bei mir im Sketch nicht drin, füge ich dann per Hand ein. Kommt dann als TSL2561_ADDR_FLOAT dann die richtige Adresse, also 0101001?
ZitatHast du 57600 Baud versucht? Und hast du RC-Osz. oder Quarz als Haupttaktgeber?
Wenn serieller Debug gehen würde würdest du direkt die Meldung "TSL2561 found" bzw. "Error: TSL2561 not found" sehen.
57600 Baud ist immer das erste, was ich versuche. Ich nutzen keinen externen Quarz, nur den internen
Ausgabe Serielle Konsole
⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
Zitat von: Tom Major am 03 Januar 2019, 11:58:36
Was du noch versuchen könntest bevor du weiter ablötest oder trennst:
Mit einem Multimeter alle Pegel der 32 AVR pins beim 20uA device und beim 1600 uA device vergleichen. Dann bei Auffälligkeiten die pins näher untersuchen die Abweichungen zeigen.
Werde ich gerne mal probieren, danke für den Tipp!
Du meinst im Betrieb die Spannung an den Pins zu vergleichen richtig?
Ich hatte vor ein paar Tagen etwas ähnliches gesehen:
https://www.youtube.com/watch?v=pRpyHF2dfq0
Da wird jedoch der Dioden-Modus des Multimeter benutzt mit negativer Polarität. Offenbar aber im stromlosen Zustand.
Klingt so als sei das zumindest im iPhone-Business eine verbreitete Debugging-Methode. Wäre das hier auch sinnvoll bzw. was ist davon zu halten?
Zitat von: Tom Major am 03 Januar 2019, 11:58:36
Macht nur Sinn wenn du 100% sicher bist die gleiche SW auf beiden Geräten zu haben.
Hatte neulich ja die 0.15 frisch per OTA auf den Problem-Sensor geflasht. Werde gerne das gleiche auch nochmal bei dem guten Sensor machen, um wirklich sicher zu gehen.
Nochmal eine Frage, die mich einfach interessiert aus der Ecke:
Ich hab neulich im Atmel-Studio per ISP (Dragon) den kompletten Atmel "gebackupt", in dem ich unter "Device Programming" sowohl den Flash als auch das EEPROM ausgelesen und als Datei gespeichert habe. Nachdem ich dann später im gleichen Fenster das Backup zurück gespielt habe, hat der Atmel aber nicht mehr gebootet. Der OTA-Bootloader hat dann einen CRC-Checksummen-Fehler angemeckert.
Warum klappt das nicht? Ich dachte, man kann dort Flash + EEPROM mit Haut und Haaren auslesen und später zurück schreiben.
Hi,
bei mir geht der TSL2561 jetzt - hab es selber gefunden. Der Addr Pin war an GND angeschlossen. Also musste ich in der Datei Sens_TSL2561.h die Zeile
#define TSL2561_ADDR TSL2561_ADDR_FLOAT
in
#define TSL2561_ADDR TSL2561_ADDR_LOW
ändern.
Neu geflashed und schon geht es ;D ;D
Für mich ist vieles Neuland und manches halt auch Try and Error. Sorry, falls ich manchmal einen Schubs brauche 8)
Zitat von: Kai-Alfonso am 03 Januar 2019, 15:57:42
Hi,
bei mir geht der TSL2561 jetzt - hab es selber gefunden. Der Addr Pin war an GND angeschlossen. Also musste ich in der Datei Sens_TSL2561.h die Zeile
#define TSL2561_ADDR TSL2561_ADDR_FLOAT
in
#define TSL2561_ADDR TSL2561_ADDR_LOW
ändern.
Neu geflashed und schon geht es ;D ;D
Für mich ist vieles Neuland und manches halt auch Try and Error. Sorry, falls ich manchmal einen Schubs brauche 8)
Hallo Kai-Alfonso,
genau diese Addr Def. meinte ich in meiner letzten Nachricht, sorry für die Kürze, hatte nicht so viel Zeit.
Du hast schon Recht, vieles ist nicht gleich offensichtlich und oft muss man bei Problemen tiefer einsteigen.
Ich werde auf jeden Fall die Addr Def. des TSL2561 mit in den sketch selbst verlagern und einen Kommentar dort machen so dass dies in Zukunft vielleicht etwas besser selbsterklärend ist. ;)
Zitat von: vbs am 03 Januar 2019, 13:12:56
Werde ich gerne mal probieren, danke für den Tipp!
Du meinst im Betrieb die Spannung an den Pins zu vergleichen richtig?
Ich hatte vor ein paar Tagen etwas ähnliches gesehen:
https://www.youtube.com/watch?v=pRpyHF2dfq0
Da wird jedoch der Dioden-Modus des Multimeter benutzt mit negativer Polarität. Offenbar aber im stromlosen Zustand.
Klingt so als sei das zumindest im iPhone-Business eine verbreitete Debugging-Methode. Wäre das hier auch sinnvoll bzw. was ist davon zu halten?
Hatte neulich ja die 0.15 frisch per OTA auf den Problem-Sensor geflasht. Werde gerne das gleiche auch nochmal bei dem guten Sensor machen, um wirklich sicher zu gehen.
Nochmal eine Frage, die mich einfach interessiert aus der Ecke:
Ich hab neulich im Atmel-Studio per ISP (Dragon) den kompletten Atmel "gebackupt", in dem ich unter "Device Programming" sowohl den Flash als auch das EEPROM ausgelesen und als Datei gespeichert habe. Nachdem ich dann später im gleichen Fenster das Backup zurück gespielt habe, hat der Atmel aber nicht mehr gebootet. Der OTA-Bootloader hat dann einen CRC-Checksummen-Fehler angemeckert.
Warum klappt das nicht? Ich dachte, man kann dort Flash + EEPROM mit Haut und Haaren auslesen und später zurück schreiben.
Ich meine die Spannung im Betrieb zu vergleichen um Stromabflüsse, offene inputs ohne pull-up usw. eventuell so finden zu können bzw. sich die pins genauer ansehen die Abweichungen zeigen. Das Ganze natürlich wenn beide Devices im sleep sind. Also wenn sie gerade senden macht das keinen Sinn ;)
Zu der iPhone Methode kann ich nichts sagen.
AVR Backup: Ich bin der Meinung, wenn man Flash, EEPROM und Fuses backuped und auf einem gleichem Modelltyp wieder aufspielt sollte sich dieser auch gleich verhalten. Außer diesen 3 gibt es nichts was sich unterscheidet, zumindest fällt mir gerade nichts ein, eine unique serial z.B. hat der AVR meines Wissens nicht (zumindest die man auf Application SW Ebene auslesen könnte).
Zitat von: Tom Major am 03 Januar 2019, 23:20:20
Hallo Kai-Alfonso,
genau diese Addr Def. meinte ich in meiner letzten Nachricht, sorry für die Kürze, hatte nicht so viel Zeit.
Das ist überhaupt kein Problem - du investierst ja so schon genug Zeit in diverse Projekte, da kann man schon rein logistisch nicht auf jede N00b Frage 8) 8) so ausführlich antworten und ich bin ja selber drauf gekommen aufgrund Deiner Antwort
Zitat von: Tom Major am 03 Januar 2019, 23:20:20
Du hast schon Recht, vieles ist nicht gleich offensichtlich und oft muss man bei Problemen tiefer einsteigen.
Ich werde auf jeden Fall die Addr Def. des TSL2561 mit in den sketch selbst verlagern und einen Kommentar dort machen so dass dies in Zukunft vielleicht etwas besser selbsterklärend ist. ;)
Ich hatte tatsächlich erst im Sketch geschaut und nix gefunden und dann blieb einfach nur noch die Sens_TSL2561.h Datei. Irgendwo musste ja auch die ganze Logic versteckt sein.
Ich habe aber noch eine andere Frage, die ich nicht verstehe bzw. die mir immer noch nicht ganz klar ist als Laie. Aber die kann bestimmt auch ein anderer beantworten:
Thema StepUp - als Laie war es mir nicht genau klar, was das ist und ob ich das überhaut brauche. So wie ich das verstehe, brauchen die Sensoren, der Atmega etc alle 3.3 Volt - wenn ich jetzt das Teil nur mit einer Batterie betreiben will (die ja bekanntlich nur 1.5V liefert) brauch ich einen StepUp, der die Spannung dann von 1.5 auf 3.3 Volt erhöht. Sehe ich das richtig. Welchen Vorteile und Nachteile habe ich denn, wenn ich nur eine AA Batterie nutzen will? Oder geht es um die Nutzung von Akkus, die ja nur 1.2 Volt liefern (Wieso können die eigentlich keine 1.5?) Wie ihr seht, so richtig verstehe ich das nicht ;-) Ich vermute einfach, das ich bei ein paar Sensoren den Stepup unnütz eingebaut habe.
Nachdem das so toll mit der 1.2 FW und dem TSL2561 geklappt habe, wollte ich mal den MAX440009 probieren an dem Sensor:
Also, neue FW mit folgenden Optionen geflashed:
//#define SENSOR_DS18X20
//#define SENSOR_BME280
#define SENSOR_BMP180
//#define SENSOR_TSL2561
#define SENSOR_MAX44009
#define SENSOR_SHT10
//#define SENSOR_DIGINPUT
Angeschlossen habe ich den MAX440009 an den I2C Port (J3 laut Schema) - GND und 3,3V habe ich mir von J2 geholt.
Leider bekomme ich keine Sensor Daten.
Shared Access sollte ja gehen, wenn ich
#if defined SENSOR_BME280 || defined SENSOR_BMP180 || defined SENSOR_TSL2561 || defined SENSOR_MAX44009
sht10.i2cEnableSharedAccess(); // falls I2C Sensoren vorhanden dies dem SHT10 mitteilen#
richtig verstehe.
Warum geht es trotzdem nicht?
Hallo zusammen!
Nachdem etwas Zeit mit anderen Projekten vergangen und der USBasp auch irgendwann eingetroffen ist, will ich mich nun endlich an das Programmieren der beiden Sensoren wagen - mit etwas Bauchschmerzen, denn schließlich ist das mein erster Versuch damit ;D
Ich habe mir die libusb Treiber und avrdude 6.3 besorgt; Installation selbiger und Anschluß des Programmers an die zu flashende Platine ist mir klar.
Hier wollte ich dann noch einmal vorsichtshalber nachfragen:
Mit makeota.html (https://github.com/pa-pa/AskSinPP/blob/master/bootloader/avr/makeota.html (https://github.com/pa-pa/AskSinPP/blob/master/bootloader/avr/makeota.html)) erstelle ich als ersteres das Firmwarefile incl. Bootloader?
Dabei gebe ich beim Außensensor F102 an, die FW liegt hier (https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release (https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release))? Welches File gebe ich dann bei makeota an? Wahrscheinlich 'HB-UW-Sen-THPL_update_V0_15_000_150303.hex', denn makeota filtert nach *.hex...
Einer der beiden Sensoren soll ein Ultraschallsensor (gloob) werden; die FW liegt hier (https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release (https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release)). Wenn ich hier auch makeota.html verwende - welchen Modeltyp gebe ich an? Weiß das jemand von Euch? Geht das überhaupt (makeota dafür verwenden)? In der 'HB-GEN-SENS-US-BATT.ino' steht unter Device Properties '{0xf2, 0x05}'. Von der 'HB-GEN-SENS-US-BATT.ino' muss ich mit der Arduino IDE erst noch ein Binary (hex) für makeota.html erstellen? Oder wie?
Zum Schluß wird jeweils mit avrdude geschrieben / Fuses gesetzt? Das hier habe ich als Kommando gefunden:
avrdude -p m328p -P usb -c usbasp -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m -e -Uflash:w:Firmware.hex:i
Passt das?
Danke für's drüberlesen!
Peter
Zitat von: PSI69 am 04 Januar 2019, 12:32:35
Von der 'HB-GEN-SENS-US-BATT.ino' muss ich mit der Arduino IDE erst noch ein Binary (hex) für makeota.html erstellen? Oder wie?
Ich habe das mal versucht. Als Board habe ich mangels besserem Wissen 'Arduino/Genuino Uno' belassen. Die 'AskSinPP-master' und 'Enableinterrupt-master' habe ich nach den ersten Fehlermeldungen unter libraries eingebunden.
Jetzt komme ich bis hierhin:
Arduino: 1.8.8 (Windows 10), Board: "Arduino/Genuino Uno"
In file included from C:\Users\PSI\Documents\Arduino\libraries\AskSinPP-master/AskSinPP.h:38:0,
from \\xxxxx\c$\Workfolder\_Temp\HB-GEN-SENS-US-BATT\HB-GEN-SENS-US-BATT.ino:23:
C:\Users\PSI\Documents\Arduino\libraries\AskSinPP-master/Activity.h:14:22: fatal error: LowPower.h: No such file or directory
compilation terminated.
exit status 1
Fehler beim Kompilieren für das Board Arduino/Genuino Uno.
... was fehlt nun noch für die AskSinPP?
Danke Peter
Zitat von: PSI69 am 04 Januar 2019, 12:59:47
Ich habe das mal versucht. Als Board habe ich mangels besserem Wissen 'Arduino/Genuino Uno' belassen. Die 'AskSinPP-master' und 'Enableinterrupt-master' habe ich nach den ersten Fehlermeldungen unter libraries eingebunden.
Jetzt komme ich bis hierhin:
Arduino: 1.8.8 (Windows 10), Board: "Arduino/Genuino Uno"
In file included from C:\Users\PSI\Documents\Arduino\libraries\AskSinPP-master/AskSinPP.h:38:0,
from \\xxxxx\c$\Workfolder\_Temp\HB-GEN-SENS-US-BATT\HB-GEN-SENS-US-BATT.ino:23:
[b]C:\Users\PSI\Documents\Arduino\libraries\AskSinPP-master/Activity.h:14:22: fatal error: LowPower.h: No such file or directory[/b]
compilation terminated.
exit status 1
Fehler beim Kompilieren für das Board Arduino/Genuino Uno.
... was fehlt nun noch für die AskSinPP?
Danke Peter
Du musst noch die LowPower Lib installieren -> https://github.com/rocketscream/Low-Power
Die Firmware für TomMajor's Sensor ist die hier, oder?
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1
Ist die eigentlich auch kompatibel mit Dirk's Originalsensor? Und falls ja, wäre das zu empfehlen (einfach um eine neuere Software zu nutzen)?
Zitat von: vbs am 04 Januar 2019, 13:11:42
Die Firmware für TomMajor's Sensor ist die hier, oder?
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1
Ist die eigentlich auch kompatibel mit Dirk's Originalsensor? Und falls ja, wäre das zu empfehlen (einfach um eine neuere Software zu nutzen)?
ich sag mal vorsichtig ja - ich nutze jetzt auf meinen "alten Sensoren" auch jetzt Dirks neuere FW (Vers. 1.2 wird in Fhem angezeigt) - ist grade auch mit der Anbindung verschiedener Sensoren flexibler wie ich finde - nur den MAX440009 bekomme ich noch nicht am laufen, aber mit TSL2561 geht es.
Zitat von: Kai-Alfonso am 04 Januar 2019, 13:03:18
Du musst noch die LowPower Lib installieren -> https://github.com/rocketscream/Low-Power
Danke, die hatte ich inzwischen auch über die Bibliotheksverwaltung der IDE gefunden und damit läuft der Compiler durch und ich habe die FW eben exportieren können!
Peter
Zitat von: Kai-Alfonso am 04 Januar 2019, 13:14:32
ich sag mal vorsichtig ja - ich nutze jetzt auf meinen "alten Sensoren" auch jetzt Dirks neuere FW (Vers. 1.2 wird in Fhem angezeigt)
Interessant, hast du mal einen Link? Ich kenne nur das hier (0.15): https://github.com/kc-GitHub/Wettersensor
Zitat von: Kai-Alfonso am 04 Januar 2019, 13:14:32
ich sag mal vorsichtig ja - ich nutze jetzt auf meinen "alten Sensoren" auch jetzt Dirks neuere FW (Vers. 1.2 wird in Fhem angezeigt) - ist grade auch mit der Anbindung verschiedener Sensoren flexibler wie ich finde - nur den MAX440009 bekomme ich noch nicht am laufen, aber mit TSL2561 geht es.
Jetzt bin ich total verwirrt mit den vielen Varianten. Welche FW ist nun zu empfehlen für den Außensensor?
https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release (https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release)
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1)
Version 1.2??? Wo?
Danke Peter
Zitat von: vbs am 04 Januar 2019, 13:21:53
Interessant, hast du mal einen Link? Ich kenne nur das hier (0.15): https://github.com/kc-GitHub/Wettersensor
Tom hat wohl ein Fork gemacht und die weiterentwickelt -> https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1
Achso ok, war wohl ein Missverständnis. Das ist ja der Link aus meiner Frage. Hat mich gewundert, da du von "Dirk's neuerer FW" sprachst. Danke dir!
Zitat von: PSI69 am 04 Januar 2019, 13:23:51
Jetzt bin ich total verwirrt mit den vielen Varianten. Welche FW ist nun zu empfehlen für den Außensensor?
https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release (https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release)
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1)
Version 1.2??? Wo?
Danke Peter
Die obere Repo hat als FW die Version 0.15, die untere FW 1.2 - laut Wiki gibt es ja 2 Platinentypen (Innen und Außen) und dort ist auch die Repo von kc verlinkt. Es gibt mittlerweile aber schon andere Platinen und eine geänderte Software (Repo von Tom) - die geänderte Software kann aber auch mit dem alten Platinenlayout (nach kleinen Änderungen) genutzt werden. Ich hoffe, ich hab das verständlich Wiedergegeben. Ist schwierig, bei so vielen Seiten hier immer auf dem aktuellsten Stand zu bleiben-
Zitat von: vbs am 04 Januar 2019, 13:30:30
Achso ok, war wohl ein Missverständnis. Das ist ja der Link aus meiner Frage. Hat mich gewundert, da du von "Dirk's neuerer FW" sprachst. Danke dir!
Mittlerweile komme ich auch total durcheinander - ich meinte natürlich
Toms neuere FW, Dirk hat imho die "alte" gemacht
Ja genau, das war so auch mein Stand, jetzt haben wir's :)
Zitat von: Kai-Alfonso am 04 Januar 2019, 13:31:05
Die obere Repo hat als FW die Version 0.15, die untere FW 1.2 - laut Wiki gibt es ja 2 Platinentypen (Innen und Außen) und dort ist auch die Repo von kc verlinkt. Es gibt mittlerweile aber schon andere Platinen und eine geänderte Software (Repo von Tom) - die geänderte Software kann aber auch mit dem alten Platinenlayout (nach kleinen Änderungen) genutzt werden. Ich hoffe, ich hab das verständlich Wiedergegeben. Ist schwierig, bei so vielen Seiten hier immer auf dem aktuellsten Stand zu bleiben-
Danke - jetzt habe ich es verstanden. Da ich die alten Platinen habe, werde ich es wohl erst einmal mit der 0.15 Versuchen.
Peter
Zitat von: Kai-Alfonso am 04 Januar 2019, 13:33:02
Mittlerweile komme ich auch total durcheinander - ich meinte natürlich Toms neuere FW, Dirk hat imho die "alte" gemacht
Na, wenn ihr schon durcheinander kommt... ;D
Zitat von: Kai-Alfonso am 04 Januar 2019, 11:30:09
Nachdem das so toll mit der 1.2 FW und dem TSL2561 geklappt habe, wollte ich mal den MAX440009 probieren an dem Sensor:
Also, neue FW mit folgenden Optionen geflashed:
//#define SENSOR_DS18X20
//#define SENSOR_BME280
#define SENSOR_BMP180
//#define SENSOR_TSL2561
#define SENSOR_MAX44009
#define SENSOR_SHT10
//#define SENSOR_DIGINPUT
Angeschlossen habe ich den MAX440009 an den I2C Port (J3 laut Schema) - GND und 3,3V habe ich mir von J2 geholt.
Leider bekomme ich keine Sensor Daten.
Shared Access sollte ja gehen, wenn ich
#if defined SENSOR_BME280 || defined SENSOR_BMP180 || defined SENSOR_TSL2561 || defined SENSOR_MAX44009
sht10.i2cEnableSharedAccess(); // falls I2C Sensoren vorhanden dies dem SHT10 mitteilen#
richtig verstehe.
Warum geht es trotzdem nicht?
Der MAX440009 hat genau so wie TSL2561 eine Addr. Def im Sensor sketch, hast du das geprüft ob die für deine HW passt?
Diese Def. werde ich auch in den sketch selber verschieben, so wie für den TSL2561, commit dazu heute abend.
Zitat von: PSI69 am 04 Januar 2019, 13:23:51
Jetzt bin ich total verwirrt mit den vielen Varianten. Welche FW ist nun zu empfehlen für den Außensensor?
https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release (https://github.com/kc-GitHub/Wettersensor/tree/master/Firmware-Release)
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1)
Version 1.2??? Wo?
Danke Peter
Ich habe versucht, auf Basis von papas aktueller und genialer AskSinPP Library mal einen Universalsensor an meine Bedürfnisse anzupassen, das Ganze für andere Sensoren so universell wie möglich zu gestalten und so zu dokumentieren das möglichst wenig Fragen aufkommen, das Resultat ist auf github.
Diese Version kann ich im begrenzten Umfang supporten, bei Problemen und natürlich nur solange der Support Aufwand nicht ausufert ;)
Zitat von: Tom Major am 04 Januar 2019, 13:42:11
Der MAX440009 hat genau so wie TSL2561 eine Addr. Def im Sensor sketch, hast du das geprüft ob die für deine HW passt?
Diese Def. werde ich auch in den sketch selber verschieben, so wie für den TSL2561, commit dazu heute abend.
Hi, ich habe mal im Datasheet des Max440009 geschaut. Dort steht:
ZitatA0 Address Select. Pull high to select address 1001 011x or low to select address 1001 010x.
A0 ist bei mir auf LOW, also müsste die Adresse in der Sensordatei (0x4A = 1001010 Binär) stimmen. Oder sehe ich das falsch?
Zitat von: Kai-Alfonso am 04 Januar 2019, 14:12:17
Hi, ich habe mal im Datasheet des Max440009 geschaut. Dort steht:
A0 ist bei mir auf LOW, also müsste die Adresse in der Sensordatei (0x4A = 1001010 Binär) stimmen. Oder sehe ich das falsch?
Also, ich hab den Fehler gefunden - der Sensor war kaputt, mit einem anderen geht es.
So, ich habe mich einmal daran versucht...
C:\Users\User\Documents\avrdude-6.3-mingw32>avrdude -p m328p -P usb -c usbasp -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m -e -Uflash:w:HB-UW-Sen-THPL_update_V0_15_000_150303.with_bootloader.KGH6476831.hex:i
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.06s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.02s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xD0"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.02s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xD0:
avrdude: load data hfuse data from input file 0xD0:
avrdude: input file 0xD0 contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0x06"
avrdude: writing efuse (1 bytes):
Writing | | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.11s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x06:
avrdude: load data efuse data from input file 0x06:
avrdude: input file 0x06 contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.02s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0xfe != 0x06
avrdude: verification error; content mismatch
avrdude: safemode: efuse changed! Was 6, and is now fe
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK (E:06, H:D0, L:E2)
avrdude done. Thank you.
Das ich die Nachfrage nach '0xfe != 0x06' ignorieren kann, habe ich hier im Forum schon gelesen. Ich habe also 'n' gedrückt. Nur - gleich danach war avrdude fertig - das ging mir ziemlich fix. Auch wenn ich den Sensor anschließend wieder über den USBasp mit Spannung versorge (also alle anderen Anschlüsse und den 10K R zum flashen nach D10 entferne) - ich habe noch keine Batterie angeschlossen - passiert nichts. Wenigstens die LED muss doch mal blinkern - spätestens nach Druck auf den Button?!?
Hat das etwas mit dem Fehler am Anfang / Firmware Update zu tun?
Jemand eine Idee?
Peter
Hallo Kai,
Zitat von: Kai-Alfonso am 04 Januar 2019, 07:59:33
Ich habe aber noch eine andere Frage, die ich nicht verstehe bzw. die mir immer noch nicht ganz klar ist als Laie. Aber die kann bestimmt auch ein anderer beantworten:
Thema StepUp - als Laie war es mir nicht genau klar, was das ist und ob ich das überhaut brauche. So wie ich das verstehe, brauchen die Sensoren, der Atmega etc alle 3.3 Volt - wenn ich jetzt das Teil nur mit einer Batterie betreiben will (die ja bekanntlich nur 1.5V liefert) brauch ich einen StepUp, der die Spannung dann von 1.5 auf 3.3 Volt erhöht.
Welchen Vorteile und Nachteile habe ich denn, wenn ich nur eine AA Batterie nutzen will? Oder geht es um die Nutzung von Akkus, die ja nur 1.2 Volt liefern (Wieso können die eigentlich keine 1.5?)
Das kommt darauf an:
Wenn Du nur eine Zelle (egal ob Akku oder Batterie verwendest) brauchst Du einen StepUp, ansonsten ist die Versorgungsspannung zu gering. Die Spannungsdifferenz kommt übrigens durch die Wahl der unterschiedlichen Materialien, diese haben eine unterschiedliche elektrochemische Spannungsreihe.
Wenn Du zwei Batterien verwendest, brauchst Du keinen StepUp, die Entladeschlussspannung ist auf jeden Fall über der Spannung, die der Prozessor braucht. Bei zwei Akkus kann das schon grenzwertig werden.
Wer eine sauber geregelte Spannung will, nimmt StepUps - ich versuche das in allen meinen Sensoren umzusetzen.
Der Vorteil: immer dieselbe Spannung - unabhängig vom Ladezustand. Allerdings muss man da auch die Option 2 oder 3 der Spannungsmessung auswählen.
Gruß Peter
Hallo vbs,
Zitat von: vbs am 04 Januar 2019, 13:11:42
Die Firmware für TomMajor's Sensor ist die hier, oder?
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1
ja.
Zitat von: vbs am 04 Januar 2019, 13:11:42
Ist die eigentlich auch kompatibel mit Dirk's Originalsensor? Und falls ja, wäre das zu empfehlen (einfach um eine neuere Software zu nutzen)?
War sie ursprünglich nicht, da der BMP180 gefehlt hat, ist sie aber jetzt. Details in meinem nächsten Post.
Gruß Peter
Hallo,
Zitat von: Kai-Alfonso am 04 Januar 2019, 13:31:05
Die obere Repo hat als FW die Version 0.15, die untere FW 1.2 - laut Wiki gibt es ja 2 Platinentypen (Innen und Außen) und dort ist auch die Repo von kc verlinkt.
Kc ist der github Account von Dirk. Ich meine, er ist berufshalber nur sehr spärlich hier unterwegs.
Die beiden Platinen (Innen und Außen) sind (meine ich) bezüglich der Sensoren kompatibel, sie haben nur eine andere HM-ID.
Zitat von: Kai-Alfonso am 04 Januar 2019, 13:31:05
Es gibt mittlerweile aber schon andere Platinen und eine geänderte Software (Repo von Tom) - die geänderte Software kann aber auch mit dem alten Platinenlayout (nach kleinen Änderungen) genutzt werden.
Ich habe mal folgende Tabelle angefangen (siehe Bild). Da kommen dann noch die I2C Addressen und die HM-IDs dazu. Fehlt noch was, um das zu verstehen?
Gruß Peter
Edit1: Ich meine, bei Tom's Layout ist der sense Pin A0, muss ich noch nachschauen ...
Edit2: angepasst
Hallo Peter,
Zitat von: PSI69 am 04 Januar 2019, 18:20:36
Auch wenn ich den Sensor anschließend wieder über den USBasp mit Spannung versorge (also alle anderen Anschlüsse und den 10K R zum flashen nach D10 entferne) - ich habe noch keine Batterie angeschlossen - passiert nichts. Wenigstens die LED muss doch mal blinkern - spätestens nach Druck auf den Button?!?
Hat das etwas mit dem Fehler am Anfang / Firmware Update zu tun?
Jemand eine Idee?
Ja, die Fuses wurden, die Firmware wurde nicht geflasht. Flash mal erst die Fuses und in einem extra Befehel die Firmware mit Bootloader. Welchen Bootloader verwendest Du? Den Atmega oder den OTA?
Gruß Peter
Zitat von: Kai-Alfonso am 04 Januar 2019, 14:12:17
Hi, ich habe mal im Datasheet des Max440009 geschaut. Dort steht:
A0 ist bei mir auf LOW, also müsste die Adresse in der Sensordatei (0x4A = 1001010 Binär) stimmen. Oder sehe ich das falsch?
Genau so ist es, beim Max440009 kann man 4A oder 4B haben, ich lese dein erster Sensor war defekt, freut mich das es jetzt geht.
Zitat von: Kai-Alfonso am 04 Januar 2019, 07:59:33
Das ist überhaupt kein Problem - du investierst ja so schon genug Zeit in diverse Projekte, da kann man schon rein logistisch nicht auf jede N00b Frage 8) 8) so ausführlich antworten und ich bin ja selber drauf gekommen aufgrund Deiner Antwort
Ich hatte tatsächlich erst im Sketch geschaut und nix gefunden und dann blieb einfach nur noch die Sens_TSL2561.h Datei. Irgendwo musste ja auch die ganze Logic versteckt sein.
Ok, wie angekündigt habe ich in den commits heute alle defines in den Sketch selber verlagert, damit man bei der Sensorkonfiguration eher darauf stößt.
Also z.B. bei der TSL2561 Aktivierung steht jetzt
//#define SENSOR_TSL2561 // Achtung, TSL2561_ADDR define weiter unten muss zur HW passen!und weiter unten
#ifdef SENSOR_TSL2561
#include "Sensors/Sens_TSL2561.h" // HB-UNI-Sensor1 custom sensor class
#define TSL2561_ADDR TSL2561_ADDR_FLOAT
#endif
Hoffe damit wird es etwas klarer dass man sich mit den realen Adress- und Pindef. seiner HW beschäftigen muss. ;)
Zitat von: PeMue am 04 Januar 2019, 21:15:53
Hallo,
Kc ist der github Account von Dirk. Ich meine, er ist berufshalber nur sehr spärlich hier unterwegs.
Die beiden Platinen (Innen und Außen) sind (meine ich) bezüglich der Sensoren kompatibel, sie haben nur eine andere HM-ID.
Ich habe mal folgende Tabelle angefangen (siehe Bild). Da kommen dann noch die I2C Addressen und die HM-IDs dazu. Fehlt noch was, um das zu verstehen?
Gruß Peter
Edit: Ich meine, bei Tom's Layout ist der sense Pin A0, muss ich noch nachschauen ...
Sensor PLHT v2.01
A0, D9
Zitat von: Tom Major am 05 Januar 2019, 00:19:40
Sensor PLHT v2.01
A0, D9
Hab's oben geändert.
ZitatOption 3: Echte Batteriespannungsmessung unter Last
coming soon
Bin schon gespannt ;)
Gruß Peter
Zitat von: PeMue am 04 Januar 2019, 21:20:33
Hallo Peter,
Ja, die Fuses wurden, die Firmware wurde nicht geflasht. Flash mal erst die Fuses und in einem extra Befehel die Firmware mit Bootloader. Welchen Bootloader verwendest Du? Den Atmega oder den OTA?
Gruß Peter
Hi Peter!
Die Firmware vom USBasp habe ich inzwischen aktualisiert, das ging recht einfach (https://www.rogerclark.net/updating-firmware-on-usbasp-bought-from-ebay/ (https://www.rogerclark.net/updating-firmware-on-usbasp-bought-from-ebay/)). Auch damit war Fuses & FW in einem Step nicht möglich. Dein Tip mit dem separaten Firmware Flashen war dann erfolgreich :)
Jetzt flashe ich noch den zweiten und dann schaue ich mal, dass ich Batterien dran bekomme und die Sensoren in FHEM einbinde.
Ich habe mir beide FW Versionen mit makeota.html erstellt - sollte dann also der OTA Bootloader sein.
Tschau Peter
Zitat von: PSI69 am 05 Januar 2019, 11:04:22
Jetzt flashe ich noch den zweiten und dann schaue ich mal, dass ich Batterien dran bekomme und die Sensoren in FHEM einbinde.
Wäre ja auch zu schön gewesen - der zweite zuckt nicht:
C:\Users\User\Documents\avrdude-6.3-mingw32>avrdude -c usbasp -P usb -p m328p -v -F
avrdude: Version 6.3, compiled on Feb 17 2016 at 09:25:53
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Users\User\Documents\avrdude-6.3-mingw32\avrdude.conf"
Using Port : usb
Using Programmer : usbasp
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : usbasp
Description : USBasp, http://www.fischl.de/usbasp/
avrdude: auto set sck period (because given equals null)
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATmega328P is 1E 95 0F
avrdude done. Thank you.Ich habe alle Anschlüsse vom 328'er überprüft - alle Lötstellen haben Kontakt zu den Leiterbahnen und keinen Schluss untereinander. Meine Anschlusskabel, die ich zum flashen benutze, haben auch Kontakt zum jeweiligem PIN am IC.
Ist der IC tot? Passiert das oft bei China-Ware?
Danke Peter
Warnung vor dem Flashen von 3,3V Geräten mit USBasp Klones
Es gab Ende Dez. einen kleinen Austausch im HM forum zum Thema 3,3V bei USBasp Klones, ich habe es heute in meine Dokumentation aufgenommen, Details siehe hier:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT#3-warnung-vor-dem-flashen-von-33v-ger%C3%A4ten-mit-usbasp-klones (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT#3-warnung-vor-dem-flashen-von-33v-ger%C3%A4ten-mit-usbasp-klones)
Zitat von: Tom Major am 05 Januar 2019, 18:36:15
Warnung vor dem Flashen von 3,3V Geräten mit USBasp Klones
Es gab Ende Dez. einen kleinen Austausch im HM forum zum Thema 3,3V bei USBasp Klones, ich habe es heute in meine Dokumentation aufgenommen, Details siehe hier:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT#3-warnung-vor-dem-flashen-von-33v-ger%C3%A4ten-mit-usbasp-klones (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT#3-warnung-vor-dem-flashen-von-33v-ger%C3%A4ten-mit-usbasp-klones)
Danke für den Hinweis, also habe ich den mit Pech selbst gegrillt?!? Was ist als Original zu empfehlen? Der von Fischl verlinkte (https://www.ebay.de/itm/323615620212 (https://www.ebay.de/itm/323615620212))?
Peter
Zitat von: PSI69 am 05 Januar 2019, 19:44:35
Danke für den Hinweis, also habe ich den mit Pech selbst gegrillt?!? Was ist als Original zu empfehlen? Der von Fischl verlinkte (https://www.ebay.de/itm/323615620212 (https://www.ebay.de/itm/323615620212))?
Peter
Hallo Peter,
ob du selbst Pech hattest kann ich aus der Ferne nicht beurteilen. Bei einigen Leuten geht es gut, muss jeder selbst entscheiden ob er das Risiko eingeht.
Die Tatsache dass außerhalb der Spec. gearbeitet wird ist im Netz kaum zu finden, deswegen wollte ich die Warnung anbringen ;)
Der Jumper suggeriert das alles gut ist, wenn man ihn auf 3,3V stellt, was aber nicht stimmt.
Das Original von Fischl hat die 3,3V Option gar nicht, ich vermute der 3,3V Jumper ist ein nachträglicher quick & dirty Hack/Addon der China Klones.
Mal kurz zu den USBASP bzw Klones - ich hatte selber immer Probleme damit und bin dann auf einen anderen Programmer umgestiegen.Und zwar auf den von Pololu:
https://www.pololu.com/product/3172
Der ist auch mit einer Software konfigurierbar was Ausgangsspannung betrifft (Auto, Off, 3v, 5V) und kann auch als TTL Adapter Dienen, falls man mal Debuggen muss.
Zitat von: PeMue am 04 Januar 2019, 21:07:58
Hallo Kai,Das kommt darauf an:
Wenn Du nur eine Zelle (egal ob Akku oder Batterie verwendest) brauchst Du einen StepUp, ansonsten ist die Versorgungsspannung zu gering. Die Spannungsdifferenz kommt übrigens durch die Wahl der unterschiedlichen Materialien, diese haben eine unterschiedliche elektrochemische Spannungsreihe.
Wenn Du zwei Batterien verwendest, brauchst Du keinen StepUp, die Entladeschlussspannung ist auf jeden Fall über der Spannung, die der Prozessor braucht. Bei zwei Akkus kann das schon grenzwertig werden.
Wer eine sauber geregelte Spannung will, nimmt StepUps - ich versuche das in allen meinen Sensoren umzusetzen.
Der Vorteil: immer dieselbe Spannung - unabhängig vom Ladezustand. Allerdings muss man da auch die Option 2 oder 3 der Spannungsmessung auswählen.
Gruß Peter
Hallo Peter,
vielen Dank für die Erklärung - jetzt habe ich das verstanden :) :)
Moin,
ich hab mal eine andere Frage: ich habe die alten Sensoren mit der neuen FW auf einer Testumgebung angelernt, um Sie zu testen. Danach habe ich die zu Hause an meiner Produktivumgebung angelernt - das funktionierte so weit, nur habe ich einen Unterschied.
Wenn ich get $DEVICE regList mache, dann fehlen in der Produktivumgebung die Einträge updateIntervall und altitude. Das Fhem Modul aus der Repo habe ich natürlich in der Produktivumgebung installiert.
Außerdem zeigt mit der TSL2561 einen brightness Wert von 99999, wenn es dunkel ist.
Zitat von: Kai-Alfonso am 07 Januar 2019, 09:59:32
Moin,
ich hab mal eine andere Frage: ich habe die alten Sensoren mit der neuen FW auf einer Testumgebung angelernt, um Sie zu testen. Danach habe ich die zu Hause an meiner Produktivumgebung angelernt - das funktionierte so weit, nur habe ich einen Unterschied.
Wenn ich get $DEVICE regList mache, dann fehlen in der Produktivumgebung die Einträge updateIntervall und altitude. Das Fhem Modul aus der Repo habe ich natürlich in der Produktivumgebung installiert.
Außerdem zeigt mit der TSL2561 einen brightness Wert von 99999, wenn es dunkel ist.
die Perl Datei ist bei beiden Systemen ganz sicher die gleiche? Und hast du die Sensoren durch langes Drücken des Config Tasters neu initialisiert, vor dem erneuten Anlernen?
Zitat von: Tom Major am 08 Januar 2019, 00:59:48
die Perl Datei ist bei beiden Systemen ganz sicher die gleiche? Und hast du die Sensoren durch langes Drücken des Config Tasters neu initialisiert, vor dem erneuten Anlernen?
Ich hab jetzt noch mal ein Diff der Perl Datei gemacht - die waren tatsächlich Unterschiedlich. Keine Ahnung, was da passiert ist. :o :o :oHab Sie noch mal neu eingebunden, und jetzt geht es 8)
Hallo zusammen,
ich hab das vom TomMajor nachgebaut.
An dieser Stelle vielen Dank für die erbrachte Leistung.
Ich habe einen BMP280 angeschlossen, soweit funktioniert das auch alles.
Einzig auf Temperaturänderungen reagiert BMP280 am Universalsensor viel zu träge.
Ich habe heute morgen mal mit Hilfe der Gefriertruhe einen Temperatursturz von 35° simuliert.
Als Referenz habe ich mit einem BME280 an einem ESP8266 das gleiche gemacht.
Im Anhang kann man sehen dass der Universalsensor weit über eine Stunde braucht um wieder die gleiche Temperatur wie der ESP anzuzeigen.
Ist da in der Software noch ein Filter (Dämpfungsglied) eingebaut? Oder wo kann das herkommen.
Hat Jemand ähnliche Erfahrung gemacht?
Danke schonmal
Chriskl
Zitat von: chriskl am 11 Januar 2019, 18:13:54
Hallo zusammen,
ich hab das vom TomMajor nachgebaut.
An dieser Stelle vielen Dank für die erbrachte Leistung.
Ich habe einen BMP280 angeschlossen, soweit funktioniert das auch alles.
Einzig auf Temperaturänderungen reagiert BMP280 am Universalsensor viel zu träge.
Ich habe heute morgen mal mit Hilfe der Gefriertruhe einen Temperatursturz von 35° simuliert.
Als Referenz habe ich mit einem BME280 an einem ESP8266 das gleiche gemacht.
Im Anhang kann man sehen dass der Universalsensor weit über eine Stunde braucht um wieder die gleiche Temperatur wie der ESP anzuzeigen.
Ist da in der Software noch ein Filter (Dämpfungsglied) eingebaut? Oder wo kann das herkommen.
Hat Jemand ähnliche Erfahrung gemacht?
Danke schonmal
Chriskl
Hmm, die BME280 library wird mit Filter_Off initialisiert, und sonst weiß ich von keinem Filter der irgendwo aktiv wäre.
Ohne den genauen Aufbau und die HW zu kennen würde ich spontan sagen, die thermische Trägheit der beiden Teile unterscheidet sich..
Hallo an die Kollegen von der Software,
wäre es denkbar, eine Testsoftware mit der Spannungsmessung Option 2 bzw. 3 zu machen, damit man ggf. die Entladekurven z.B. der ingesetzten CR2032 Batterien ermitteln kann?
Hintergrund meiner Frage: Mein Ultraschallsensor (1x LadyN) hat bei 1,2 V (Optionm 2) schlapp gemacht und ich habe es nicht gemerkt. Und 1,2 V ist ja die Nominalspannung - also irgendwas passt da nicht.
Danke + Gruß
Peter
Edit:
Zitat von: PeMue am 15 Januar 2019, 08:29:36
... eine Testsoftware mit der Spannungsmessung Option 2 bzw. 3 zu machen, damit man ggf. die Entladekurven z.B. der ingesetzten CR2032 Batterien ermitteln kann?
Das ist ziemlicher Blödsinn, was ich da geschrieben habe, da sich die Widerstände der beiden Messungen unterscheiden ::).
Schlussfolgerung für mich: eine Batteriespannung unter Last ist notwendig.
Zitat von: PeMue am 15 Januar 2019, 08:29:36
Hallo an die Kollegen von der Software,
wäre es denkbar, eine Testsoftware mit der Spannungsmessung Option 2 bzw. 3 zu machen, damit man ggf. die Entladekurven z.B. der ingesetzten CR2032 Batterien ermitteln kann?
Hintergrund meiner Frage: Mein Ultraschallsensor (1x LadyN) hat bei 1,2 V (Optionm 2) schlapp gemacht und ich habe es nicht gemerkt. Und 1,2 V ist ja die Nominalspannung - also irgendwas passt da nicht.
Danke + Gruß
Peter
Ich hatte gestern auch was komisches. Ein Sensor, der schon mit der selben Batterie ein Jahr lang läuft, fing auf einmal an, immer wieder 7 mal zu blinken. Ich vermute, er hatte sich neu gestartet und kam dann nicht über den Bootloader hinaus. Batterie rein und raus brachte kein neues Ergebnis - erst mit einer neuen Batterie ging es dann wieder. Hab leider versäumt zu messen, wie voll noch die alte Batterie war.
Mal eine kurze Nebenfrage: nach welchen Kriterien pollt denn der Actiondetector die Devices und markiert sie als Dead? Manchmal markiert er Sensoren als dead, die sich kurz vorher (2-3 Minuten) vorher noch gemeldet haben, andere (so wie der beschriebene Sensor im Bootloop) wurde gar nicht als dead erkannt
ZitatMal eine kurze Nebenfrage: nach welchen Kriterien pollt denn der Actiondetector die Devices und markiert sie als Dead? Manchmal markiert er Sensoren als dead, die sich kurz vorher (2-3 Minuten) vorher noch gemeldet haben, andere (so wie der beschriebene Sensor im Bootloop) wurde gar nicht als dead erkannt
der ad pollt in der regel nicht. er lauscht auf messages, wenn er am jeweiligen device eingeschaltet wurde (actcycle).
Zitat von: frank am 15 Januar 2019, 09:48:58
der ad pollt in der regel nicht. er lauscht auf messages, wenn er am jeweiligen device eingeschaltet wurde (actcycle).
Ok, das erklärt es - actCycle war auf 10 min und der Sensor selber meldet sich auch alle 10 min - so hat es sich wahrscheinlich immer überschnitten. Hab mal den actCycle erhöht
Ich habe versucht an den 'Digital Input' einen Bewegungssensor anzuschließen (ELV PIR13). Das klappt prinzipiell auch, aber wenn eine zeitgesteuerte Sendung startet wird der Sensor und damit der Interrupt immer ausgelöst. Ich bekomme also nie eine 1 beim Lesen des Digital Input. Auch ein Radarsensor (RCWL-0516) - dafür habe ich in Sens_DIGINPUT.h von 'pinMode(_pin, INPUT_PULLUP);' auf 'pinMode(_pin, INPUT);' geändert - löst auch bei der zeitgesteuerten Sendung aus. Damit lese ich dann nie eine 0.
Ich vermute das HF-Signal triggert die Sensoren oder eventuell ein Peak auf der Versorgungsspannung - hier nutze ich ein USB-Netzteil 5V und 3.3V Regler für Versorgung der HB_UNI_Sensor Platine. Zusätzliche 100nf + 330uf helfen da jedenfalls nicht. Wie könnte man das eventuell programmtechnisch lösen.
Danke
Gregor
Da du 'Sens_DIGINPUT.h' erwähnst vermute ich mal du hast den HB-UNI-Sensor1 im Einsatz.
Auch wenn ich die Frage nicht komplett verstehe klingt das irgendwie nach einem Anpassungsproblem zwischen PIR und AVR Input. Da muss man drauf schauen was der PIR oder der Radar genau für Pegel liefert.
Ich weiß das fhemfreund einen PIR AS312 am 'Digital Input' des HB-UNI-Sensor1 im Einsatz hat, er hat einen Transistor dazwischen. Vielleicht kann er hier genaueres schreiben.
Die Pegel sollten OK sein. Der PIR hat einen 'open collector' Ausgang und zieht nach Masse (daher PULLUP an A0 nötig). Der RCWL wird intern mit 3.3V versorgt und liefert ca. 2.8V bei 'Bewegungserkennung' (für 3-4 Sekunden), dann 0V. Dieser Ausgang hat einen 1K in Reihe, daher PULLUP an A0 ausgeschaltet, sonst ist 'low' evtl. unsicher.
Das Problem ist, dass die Sensoren auslösen, wenn der HB-UNI-Sensor1 etwas sendet, immer, auch ohne eine Bewegung im Raum.
@fhemfreund - hattest Du keine 'false trigger'-Probleme ?
Zitat von: gregor am 24 Januar 2019, 09:04:41
Das Problem ist, dass die Sensoren auslösen, wenn der HB-UNI-Sensor1 etwas sendet, immer, auch ohne eine Bewegung im Raum.
Das kenne ich auch von meinen Versuchen mit einem HC-SR501. Irgendwie löst der auch immer aus, wenn das Funkmodul aktiv ist. Besser geht es mit diesem hier (https://de.aliexpress.com/item/Mini-IR-Pyroelectric-Infrared-PIR-Motion-Human-Sensor-Automatic-Detector-Module-high-reliability-12mm-x-25mm/32824467684.html?spm=a2g0x.search0104.3.45.702e785bdRhavY&ws_ab_test=searchweb0_0%2Csearchweb201602_1_10320_10065_10068_10547_319_317_10548_10696_453_10084_454_10083_433_10618_431_10304_10307_10820_10821_537_10302_536_10843_10059_10884_10887_100031_10319_321_322_10103%2Csearchweb201603_59%2CppcSwitch_0&algo_pvid=c6e4a7f0-e170-4c15-86c7-ab9631fb92d1&algo_expid=c6e4a7f0-e170-4c15-86c7-ab9631fb92d1-6). Die laufen auch ordentlich mit 3.3V.
Zitat von: gregor am 24 Januar 2019, 09:04:41
Die Pegel sollten OK sein. Der PIR hat einen 'open collector' Ausgang und zieht nach Masse (daher PULLUP an A0 nötig). Der RCWL wird intern mit 3.3V versorgt und liefert ca. 2.8V bei 'Bewegungserkennung' (für 3-4 Sekunden), dann 0V. Dieser Ausgang hat einen 1K in Reihe, daher PULLUP an A0 ausgeschaltet, sonst ist 'low' evtl. unsicher.
Das Problem ist, dass die Sensoren auslösen, wenn der HB-UNI-Sensor1 etwas sendet, immer, auch ohne eine Bewegung im Raum.
@fhemfreund - hattest Du keine 'false trigger'-Probleme ?
Der AVR hat ca. 35k internen pull-up, deshalb sollte 1k in Reihe auch mit pull-up kein Problem sein.
Der von papa verlinkte ist der AS312/AM312 den auch fhemfreund im Einsatz hat (ich habe auch 2 daliegen aber noch nicht eingesetzt).
Wenn das Senden wirklich den PIR auslöst könnte ich im HB-UNI-Sensor1 während des Sendens den dig.Input Trigger deaktivieren. Dazu bräuchte es nur eine kleine Änderung im header file..
Ich spiele mit dem Gedanken, mir einen von TomMajor's Sensoren zu bauen (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT). Einerseits weil ich gerne einen hätte und andererseits, weil ich neugierig bin, wie man sowas an geht bzw. wie das funktioniert...
Ich hab dazu mal ein paar Fragen, sind sicherlich auch ein paar dumme dabei, also sorry schonmal ;)
- Man braucht ja z.B. einige Widerstände. Die Widerstandswerte sind angegeben. Nun hab ich mir aber angelesen, dass es jetzt sehr viele verschiedene Bauformen gibt (https://de.wikipedia.org/wiki/Chip-Bauform). Also verschiedene Größen für die SMD-Bausteine. Wie bekomme ich raus, welche Größen auf der Platine vorgesehen sind (z.B. 1206 oder 0805)? Wäre sowas im Eagle-Board-Layout (oder vergleichbares) zu finden oder im "BOM"? Hab "nur" Gerber-Files gefunden.
- Wie beschafft ihr euch dieses "Vogelfutter"? Hab ihr Vorräte von den gängisten Größen auf Vorrat oder bestellt ihr, was ihr gerade benötigt? Was ist von solchen Sets zu halten:
https://www.aliexpress.com/item/Free-shipping-0402-SMD-Sample-Book-63values-3300pcs-Resistor-Kit-and-17values-950pcs-Capacitor-Set/32254556322.html?spm=2114.search0104.3.36.38fe6ec0lsfaEA&ws_ab_test=searchweb0_0,searchweb201602_5_10320_10065_10068_10890_10547_319_10546_317_10548_10696_453_10084_454_10083_433_10618_431_10304_10307_10820_537_536_10902_10843_10059_10884_10887_100031_321_322_10103-10890,searchweb201603_54,ppcSwitch_0&algo_expid=bab08b10-3139-4b2e-915d-b64c19b728a8-5&algo_pvid=bab08b10-3139-4b2e-915d-b64c19b728a8
Sieht ja erstmal praktisch aus. Kann natürlich sein, dass die Teile, die man regelmäßig braucht, schnell aufgebraucht sind und man am Ende 3000 Widerstandsgrößen übrig hat, die man eh nie braucht :/
In Github gibt es eine Ideensammlung für die nächste Hardware-Revision. Ist das schon absehbar, so dass man darauf noch warten sollte?
Sollte man dem Sensor nicht einen eigenen Thread spendieren? :)
Danke euch und schönen Freitag.
Zitat von: vbs am 25 Januar 2019, 13:09:27
Wie bekomme ich raus, welche Größen auf der Platine vorgesehen sind
Ich habe 0805 genommen; passt.
Zitat von: vbs am 25 Januar 2019, 13:09:27
Wie beschafft ihr euch dieses "Vogelfutter"? Hab ihr Vorräte von den gängisten Größen auf Vorrat oder bestellt ihr, was ihr gerade benötigt? Was ist von solchen Sets zu halten:
Hatte ich ebenfalls überlegt, habe mich dann allerdings genau für die paar Werte entschieden, die ich wirklich gebraucht habe. Sind dann zwar immer mindestens 100 Stück - aber irgendwan werden die schon alle. Und bei Preisen um die 1€ pro 100 Stück bei Ali...
Peter
Hi,
Widerstände: mach doch einfach eine Suche hier im Marktplatz auf und warte auf (meine!?) Antwort ;-)
Wir haben doch alle die Keller voll *lol*
Die kleineren SMD Teile gehen auch auf die größeren Pads, also 0805, 0603.
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Hallo,
ich habe für mich generell auf 0805 umgestellt und die gängigsten Größen (Widerstände 330, 1k, 4k7, 10k, 100k bzw. Kondensatoren 100 nF, 10 nF) in größerer Menge beschafft. Ansonsten bestelle ich halt die fehlenden bei meinen Bestellungen bei Voelkner mit.
Gruß Peter
Zitat von: vbs am 25 Januar 2019, 13:09:27
Ich spiele mit dem Gedanken, mir einen von TomMajor's Sensoren zu bauen (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT). Einerseits weil ich gerne einen hätte und andererseits, weil ich neugierig bin, wie man sowas an geht bzw. wie das funktioniert...
Ich hab dazu mal ein paar Fragen, sind sicherlich auch ein paar dumme dabei, also sorry schonmal ;)
- Man braucht ja z.B. einige Widerstände. Die Widerstandswerte sind angegeben. Nun hab ich mir aber angelesen, dass es jetzt sehr viele verschiedene Bauformen gibt (https://de.wikipedia.org/wiki/Chip-Bauform). Also verschiedene Größen für die SMD-Bausteine. Wie bekomme ich raus, welche Größen auf der Platine vorgesehen sind (z.B. 1206 oder 0805)? Wäre sowas im Eagle-Board-Layout (oder vergleichbares) zu finden oder im "BOM"? Hab "nur" Gerber-Files gefunden.
- Wie beschafft ihr euch dieses "Vogelfutter"? Hab ihr Vorräte von den gängisten Größen auf Vorrat oder bestellt ihr, was ihr gerade benötigt? Was ist von solchen Sets zu halten:
https://www.aliexpress.com/item/Free-shipping-0402-SMD-Sample-Book-63values-3300pcs-Resistor-Kit-and-17values-950pcs-Capacitor-Set/32254556322.html?spm=2114.search0104.3.36.38fe6ec0lsfaEA&ws_ab_test=searchweb0_0,searchweb201602_5_10320_10065_10068_10890_10547_319_10546_317_10548_10696_453_10084_454_10083_433_10618_431_10304_10307_10820_537_536_10902_10843_10059_10884_10887_100031_321_322_10103-10890,searchweb201603_54,ppcSwitch_0&algo_expid=bab08b10-3139-4b2e-915d-b64c19b728a8-5&algo_pvid=bab08b10-3139-4b2e-915d-b64c19b728a8
Sieht ja erstmal praktisch aus. Kann natürlich sein, dass die Teile, die man regelmäßig braucht, schnell aufgebraucht sind und man am Ende 3000 Widerstandsgrößen übrig hat, die man eh nie braucht :/
In Github gibt es eine Ideensammlung für die nächste Hardware-Revision. Ist das schon absehbar, so dass man darauf noch warten sollte?
Sollte man dem Sensor nicht einen eigenen Thread spendieren? :)
Danke euch und schönen Freitag.
Ja, das R und C Vogelfutter sind alle 0805 (außer den beiden Elkos für optionalen Step-up). Ich schreibe das noch dazu :)
Man könnte sicher einen eigenen Thread machen, die Sache hat sich halt entwickelt als ich letztes Jahr ein paar Sachen an der bestehenden Schaltung und Layout modernisieren wollte. Ich würde das Thema auch in einem neuen Thread supporten wenn sich spezifische Fragen ergeben, falls jemand einen neuen aufmacht ;)
Wegen der nächsten Hardware-Revision, ich hatte letztes Jahr angefangen die Themen zu sammeln als kpwg anfing Verbesserungsvorschläge einzubringen. Ich selbst habe momentan keinen dringenden Bedarf für eine Neubestellung, wenn jemand aber demnächst eine Bestellung machen will könnte ich die Ideen noch vorher im Layout umsetzen.
Will mal versuchen zusammen zu fassen, was ich gemacht habe.
Zunächst habe ich zusammen mit Tom den Ruhestrom Verbrauch seiner UniSensor FW stark reduzieren können, sodass wir z.Z. mit einem AM312 PIR Motion Sensor, einem BME280 (Luftdruck + Temp + Feuchte) und einem MAX44009 (Helligkeit) auf ~13uA Ruhestromverbrauch kommen. Das lässt uns mit einer CR2450 Kopfzelle rein rechnerisch auf weit über ein Jahr Betriebsdauer (bei 3min regulärem Sendeintervall und je nach durch den PIR getriggerten Sendeintervalle pro Tag) kommen. Für weitere Infos schaut einfach auf Tom's Github (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1) vorbei, er hat das sehr gut dokumentiert.
Den AM312 habe ich via BC547 (AM312 Ausgang via 10K an Basis, 20K von VCC an Collector, Collector an DigitalInput vom AVR, Emitter an Masse) angeschaltet. Zusätzlich habe ich einen 10uF Tantal + 100nF MKS Kondensator zur Glättung für den PIR verwendet. Ich habe die UniSensorRTC FW im Einsatz und seit einer Woche hunderte Motion Detections ohne einen Fehltrigger. Auch habe ich beim regulären Senden (der Temperatur etc.) keinen PIR Fehltrigger. Ich habe das Signal invertiert, da ein Low am DigitalInput (=PIR nicht aktiv) einen höheren Ruhestromverbrauch zur Folge hatte. Tom will die 'Schaltung' auch auf Github hochladen.
meine Empfehlung: Für einen HM Sensor mit Bewegungserkennung: Tom's FW, Konfiguration s.o. und Papa's Platine (https://github.com/pa-pa/HMSensor/tree/master/HMSensor-CR2032).
Andreas
Zitat von: PSI69 am 25 Januar 2019, 15:17:03
Ich habe 0805 genommen; passt.
Hatte ich ebenfalls überlegt, habe mich dann allerdings genau für die paar Werte entschieden, die ich wirklich gebraucht habe. Sind dann zwar immer mindestens 100 Stück - aber irgendwan werden die schon alle. Und bei Preisen um die 1€ pro 100 Stück bei Ali...
Zitat von: PeMue am 25 Januar 2019, 17:42:23
ich habe für mich generell auf 0805 umgestellt und die gängigsten Größen (Widerstände 330, 1k, 4k7, 10k, 100k bzw. Kondensatoren 100 nF, 10 nF) in größerer Menge beschafft. Ansonsten bestelle ich halt die fehlenden bei meinen Bestellungen bei Voelkner mit.
Ok, danke euch, werd ich auch mal so in Erwägung ziehen.
Zitat von: RaspiLED am 25 Januar 2019, 15:52:49
Widerstände: mach doch einfach eine Suche hier im Marktplatz auf und warte auf (meine!?) Antwort ;-)
Wir haben doch alle die Keller voll *lol*
Haha danke dir! Irgendwie beschleicht mich aber das Gefühl, dass dein Keller der vollste ist ;D
Ich komme gerne drauf zurück, aber werde versuchen es soweit möglich selbständig hinzubekommen. Einerseits um das hilfsbereite Forum nicht überzustrapazieren und außerdem will ich wissen, wie man sowas selbst macht.
Zitat von: Tom Major am 25 Januar 2019, 18:53:52
Wegen der nächsten Hardware-Revision, ich hatte letztes Jahr angefangen die Themen zu sammeln als kpwg anfing Verbesserungsvorschläge einzubringen. Ich selbst habe momentan keinen dringenden Bedarf für eine Neubestellung, wenn jemand aber demnächst eine Bestellung machen will könnte ich die Ideen noch vorher im Layout umsetzen.
Wenn es deine Zeit erlaubt, dann wär das natürlich toll.
Zitat von: fhemfreund am 26 Januar 2019, 02:20:36
meine Empfehlung: Für einen HM Sensor mit Bewegungserkennung: Tom's FW, Konfiguration s.o. und Papa's Platine (https://github.com/pa-pa/HMSensor/tree/master/HMSensor-CR2032).
Interessant, hab gar nicht gewusst, dass es da noch eine weitere Platinenvariante gäbe. Da ich Bewegungsmelder auch interessant finde: was sind diesbezüglich die Vorteile gegenüber Tom's Platine?
Zitat von: vbs am 28 Januar 2019, 09:43:03
Interessant, hab gar nicht gewusst, dass es da noch eine weitere Platinenvariante gäbe. Da ich Bewegungsmelder auch interessant finde: was sind diesbezüglich die Vorteile gegenüber Tom's Platine?
Das ist pa-pa's Universalplatine (https://forum.fhem.de/index.php/topic,73954.msg656384.html#msg656384), wie sie auch im Nachbau-Fensterkontakt verbaut ist. Dirk's Platine (und alle Derivate) hat den Vorteil, dass man einen (modifizierten) Arduino pro mini 3,3V verbauen kann, ansonsten haben alle Platinen einen ähnlichen Funktionisumfang (sieht man einmal von den bestückbaren Sensoren bei Dirk ab). Und sie passt in ein handelsübliches Gehäuse (mit transparentem Deckel).
Das Einzige, was (meine ich) bei pa-pa noch nicht umgesetzt ist (aber m.E. notwendig ist) ist die Spannungsmessung unter Last.
Gruß Peter
Zitat von: fhemfreund am 26 Januar 2019, 02:20:36
Will mal versuchen zusammen zu fassen, was ich gemacht habe.
Zunächst habe ich zusammen mit Tom den Ruhestrom Verbrauch seiner UniSensor FW stark reduzieren können, sodass wir z.Z. mit einem AM312 PIR Motion Sensor, einem BME280 (Luftdruck + Temp + Feuchte) und einem MAX44009 (Helligkeit) auf ~13uA Ruhestromverbrauch kommen. Das lässt uns mit einer CR2450 Kopfzelle rein rechnerisch auf weit über ein Jahr Betriebsdauer (bei 3min regulärem Sendeintervall und je nach durch den PIR getriggerten Sendeintervalle pro Tag) kommen. Für weitere Infos schaut einfach auf Tom's Github (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1) vorbei, er hat das sehr gut dokumentiert.
Den AM312 habe ich via BC547 (AM312 Ausgang via 10K an Basis, 20K von VCC an Collector, Collector an DigitalInput vom AVR, Emitter an Masse) angeschaltet. Zusätzlich habe ich einen 10uF Tantal + 100nF MKS Kondensator zur Glättung für den PIR verwendet. Ich habe die UniSensorRTC FW im Einsatz und seit einer Woche hunderte Motion Detections ohne einen Fehltrigger. Auch habe ich beim regulären Senden (der Temperatur etc.) keinen PIR Fehltrigger. Ich habe das Signal invertiert, da ein Low am DigitalInput (=PIR nicht aktiv) einen höheren Ruhestromverbrauch zur Folge hatte. Tom will die 'Schaltung' auch auf Github hochladen.
meine Empfehlung: Für einen HM Sensor mit Bewegungserkennung: Tom's FW, Konfiguration s.o. und Papa's Platine (https://github.com/pa-pa/HMSensor/tree/master/HMSensor-CR2032).
Andreas
Schönes Projekt!
Ich bin vor ein paar Tagen über dies hier gestolpert: https://asksinpp.de/Projekte/jan/HM-SEC-MDIR/ (https://asksinpp.de/Projekte/jan/HM-SEC-MDIR/). Nun hatte ich vor das da verlinkte Gehäuse zu nehmen, den verlinkten HM-SEC-MDIR-Sketch und eine Platine vom Innensensor (habe ich noch rumliegen) - wenn sie denn in das Gehäuse passt. Nun habt ihr Toms FW angepaßt - ich denke dieser Teil hier -
#define DIGINPUT_PIN A0
Sens_DIGINPUT digitalInput; // muss wegen Verwendung in loop() global sein (Interrupt event)
#endif - so dass der PIR angeschlossen werden kann?
Ich will den AM312 allein damit betreiben - andere Sensoren benötige ich nicht... Das geht doch? Oder sollte ich in diesem Fall doch das HM-SEC-MDIR Beispiel von Papa nehmen - dann ist das dann ein Sensor mit der original Homematic ID?!?
Was mir wichtig ist, ist die lange Laufzeit; deswegen scheidet für mich auch der CR2032 Betrieb aus. Mit welcher FW / welchem Sketch kommt man bei gleicher Hardware länger durch die Tür? Was sagt ihr?
Auch die erwähnte alternative Anbindung des AM312 über BC547 ist ja in diesem Zusammenhang interessant - das klappt doch sicher nur mit Tom's FW, oder? Über die 'Schaltung' würde ich mich freuen!
Viele Fragen...
Peter
Zitat von: PSI69 am 29 Januar 2019, 07:56:40
Schönes Projekt!
Ich bin vor ein paar Tagen über dies hier gestolpert: https://asksinpp.de/Projekte/jan/HM-SEC-MDIR/ (https://asksinpp.de/Projekte/jan/HM-SEC-MDIR/). Nun hatte ich vor das da verlinkte Gehäuse zu nehmen, den verlinkten HM-SEC-MDIR-Sketch und eine Platine vom Innensensor (habe ich noch rumliegen) - wenn sie denn in das Gehäuse passt. Nun habt ihr Toms FW angepaßt - ich denke dieser Teil hier -
#define DIGINPUT_PIN A0
Sens_DIGINPUT digitalInput; // muss wegen Verwendung in loop() global sein (Interrupt event)
#endif - so dass der PIR angeschlossen werden kann?
Ich will den AM312 allein damit betreiben - andere Sensoren benötige ich nicht... Das geht doch? Oder sollte ich in diesem Fall doch das HM-SEC-MDIR Beispiel von Papa nehmen - dann ist das dann ein Sensor mit der original Homematic ID?!?
Was mir wichtig ist, ist die lange Laufzeit; deswegen scheidet für mich auch der CR2032 Betrieb aus. Mit welcher FW / welchem Sketch kommt man bei gleicher Hardware länger durch die Tür? Was sagt ihr?
Auch die erwähnte alternative Anbindung des AM312 über BC547 ist ja in diesem Zusammenhang interessant - das klappt doch sicher nur mit Tom's FW, oder? Über die 'Schaltung' würde ich mich freuen!
Viele Fragen...
Peter
Meine UniSensor Variante ist ein custom device was den AddOn Script für HomeMatic bzw. das Perl script für FHEM benötigt. Gestartet ursprünglich als Universal-Umweltsensoren Gerät ist der digitale Eingang nachträglich dazugekommen da ich den Bedarf dazu hatte.
Aktuell sind fhemfreund und ich dran, den AM312 korrekt dafür anzupassen, das Thema ist noch in Arbeit, wenn es fertig ist lege ich noch eine Info dazu auf github ab. Irgendwas stimmt noch nicht mit der Strombelastbarkeit des Ausgangspegels des AM312, deswegen auch der Transistor, wie gesagt, work in progress.
Wenn du nur einen PIR brauchst kannst du auch den HM-SEC-MDIR nehmen, ich würde dann nur empfehlen zu schauen dass die Pegel des PIR passen.
Minimaler Ruhestrom mit RTC Option möglich (1uA), im Moment hat fhemfreund eine UniSensor Variante davon, ich plane dass auch noch demnächst per define im HB-UNI-Sensor1 umschaltbar zu machen.
Oder papas HM-SEC-MDIR auf RTC clock umstellen.
Zitat von: Tom Major am 29 Januar 2019, 13:04:56
wie gesagt, work in progress.
OK, danke Dir für die Info. Da ich z.Z. sowieso auf Bauteile warte und bezüglich PIR ganz am Anfang stehe - kein Problem mit etwas Wartezeit auf die AM312 Anpassungen...
Peter
Moin 8) 8)
Ich hab jetzt draußen seit Monaten einen Universalsensor im "alten" Design mit BMP180 für Temperatur/Druck und SHT10 für Luftfeuchtigkeit laufen. Neuerdings habe ich genau daneben einen Universalsensor von Papa mit der Software von Tom Major laufen. Dort ist ein BME 280 verbaut für Temperatur/Druck/Luftfeuchtigkeit.
Beim Ausbringen des neuen Sensors nach Außenb habe ich auch gemerkt, das es recht lange (>1h) gedauert hat, bis die Temperatur sich der realen Temperatur angenähert hatte.
Außerdem habe ich große Differenzen bei der Luftfeuchtigkeit. Der BME scheint die Luftfeuchtigkeit falsch (zu niedrig) zu messen. Wie beeinflusst denn das relativ dichte Gehäuse die Werte?
Zitat von: Kai-Alfonso am 31 Januar 2019, 11:11:53
Außerdem habe ich große Differenzen bei der Luftfeuchtigkeit. Der BME scheint die Luftfeuchtigkeit falsch (zu niedrig) zu messen. Wie beeinflusst denn das relativ dichte Gehäuse die Werte?
Wie soll denn ein Sensor in einem dichten Gehäuse die Luftfeuchtigkeit messen? Das wird einfach nix. Das Gehäuse wird auch die Temperaturänderungen nur sehr langsam an den Sensor weiter geben.
Zitat von: gloob am 31 Januar 2019, 11:20:42
Wie soll denn ein Sensor in einem dichten Gehäuse die Luftfeuchtigkeit messen? Das wird einfach nix. Das Gehäuse wird auch die Temperaturänderungen nur sehr langsam an den Sensor weiter geben.
Das ist mir nach Blick aufs Gehäuse schon klar, allerdings ist da doch irgendwo ein (geringer) Luftaustausch, weil der (alte) Sensor ist im gleichen Gehäuse (GAINTA G201C). Die gemessene Luftfeuchtigkeit und Luftdruck ist jedenfalls recht nahe am Ist-Wert. Beim neuen Sensor stimmen die Werte auch annähernd, nur die Luftfeuchtigkeit ist erheblich zu niedrig.
Irgendwann wollte ich mal ein Loch ins Gehäuse machen und mit einem Stoff abdichten, der nur die Feuchtigkeit abhält
ich würde mal beide gehäuse über einen längeren zeitraum öffnen.
Zitat von: Kai-Alfonso am 31 Januar 2019, 11:56:05
Beim neuen Sensor stimmen die Werte auch annähernd, nur die Luftfeuchtigkeit ist erheblich zu niedrig.
ich hatte mit BME280 schon mehrfach Pech. Meine Erfahrung ist, dass die Temperatur bis zu 2 Grad höher gemessen wird als mehrere andere Sensoren. Bei identischer absoluten Luftfeuchte sinkt die rel. Luftfeuchte bei steigender Temperatur. Ist die Temperatur bei dir identisch zum "alten" Sensor?
Zitat von: kadettilac89 am 31 Januar 2019, 13:58:07
ich hatte mit BME280 schon mehrfach Pech. Meine Erfahrung ist, dass die Temperatur bis zu 2 Grad höher gemessen wird als mehrere andere Sensoren. Bei identischer absoluten Luftfeuchte sinkt die rel. Luftfeuchte bei steigender Temperatur. Ist die Temperatur bei dir identisch zum "alten" Sensor?
in meinem Beitrag ist ein Screenshot mit den Werten beider Sensoren. Die Temperatur hat einen Unterschied von 1.3 Grad
Zitat von: Kai-Alfonso am 31 Januar 2019, 11:11:53
Moin 8) 8)
Ich hab jetzt draußen seit Monaten einen Universalsensor im "alten" Design mit BMP180 für Temperatur/Druck und SHT10 für Luftfeuchtigkeit laufen. Neuerdings habe ich genau daneben einen Universalsensor von Papa mit der Software von Tom Major laufen. Dort ist ein BME 280 verbaut für Temperatur/Druck/Luftfeuchtigkeit.
Beim Ausbringen des neuen Sensors nach Außenb habe ich auch gemerkt, das es recht lange (>1h) gedauert hat, bis die Temperatur sich der realen Temperatur angenähert hatte.
Außerdem habe ich große Differenzen bei der Luftfeuchtigkeit. Der BME scheint die Luftfeuchtigkeit falsch (zu niedrig) zu messen. Wie beeinflusst denn das relativ dichte Gehäuse die Werte?
Die Gainta Gehäuse haben ja noch eine extra Gummidichtung, ohne Öffnung im Gehäuse misst man damit sicher eine Luftfeuchtigkeit/ein Mikroklima was nicht viel mit außen zu tun hat.
Und wenn man die Temperatur sehr genau haben will ist der BME280 nicht die allererste Wahl, dazu gibt es es einige Infos und Vergleichstests im Netz.
Zum Thema Öffnung für Luftfeuchtigkeit muss ich jetzt einfach harvey637 zitieren :) :)
ZitatLuftloch: bei mir einfachst und kostenlos. Hier hat es keinen Beigeschmack, wenn man
seine Freundin nach abgelegten Nylonstrümpfen fragt!
https://github.com/TomMajor/AskSinPP_Examples/issues/10#issuecomment-454321612
Zitat von: Tom Major am 01 Februar 2019, 18:31:52
Die Gainta Gehäuse haben ja noch eine extra Gummidichtung, ohne Öffnung im Gehäuse misst man damit sicher eine Luftfeuchtigkeit/ein Mikroklima was nicht viel mit außen zu tun hat.
Und wenn man die Temperatur sehr genau haben will ist der BME280 nicht die allererste Wahl, dazu gibt es es einige Infos und Vergleichstests im Netz.
Zum Thema Öffnung für Luftfeuchtigkeit muss ich jetzt einfach harvey637 zitieren :) :)
https://github.com/TomMajor/AskSinPP_Examples/issues/10#issuecomment-454321612
Habs jetzt auch so gemacht - eine Nylon Strumpfhose der Frau gefleddert und pro Gehäuse 2 Löcher mit einem 10er Bohrer gemacht. Dann von Innen das Nylon mit Heißkleber fixiert. Jetzt stimmen die Werte (Was auch logisch war, das es vorher Quatsch war - aber nicht genug von mir bedacht)
Ich hoffe nur, das jetzt kein Wasser eindringt - hab jetzt den Sensor so aufgehangen, das die Löcher seitlich sind. Evtl hätte auch nur ein Loch gereicht - vielleicht mache ich noch ein Loch zu und hänge das Loch nach unten
Freut mich dass es jetzt mit den Werten besser aussieht. Ein Foto deiner Lösung wäre sicher für andere Nachbauer interessant..
Ich würde das Loch nach unten hin machen.
Zitat von: Tom Major am 03 Februar 2019, 19:23:29
Freut mich dass es jetzt mit den Werten besser aussieht. Ein Foto deiner Lösung wäre sicher für andere Nachbauer interessant..
Ich würde das Loch nach unten hin machen.
ich habs vorhin schnell quick und dirty gemacht, sollte aber trotzdem reichen 8) 8) 8)
Zitat von: Kai-Alfonso am 03 Februar 2019, 19:43:08
ich habs vorhin schnell quick und dirty gemacht, sollte aber trotzdem reichen 8) 8) 8)
Das mit dem Entgraten solltest Du noch mal üben ;D ;D ;D
Danke für die Bilder.
Gruß Peter
Zitat von: PeMue am 03 Februar 2019, 19:52:25
Das mit dem Entgraten solltest Du noch mal üben ;D ;D ;D
Danke für die Bilder.
Gruß Peter
Die Betonung lag auf
dirty ;D ;D ;D schön kommt später
Danke für die Bilder 8) :)
Hat jemand eine gute Alternative für LQH43CN100K03L? Ich kann den nur bei Conrad finden und dann eben mit den entsprechenden Versandkosten.
Gibt's da nicht was in China? Ist vom Versand her einfach wesentlich günstiger :o ::)
Ich mal wieder mit ein paar Fragezeichen...
Hintergrund:
Bei meinem Universal-Wettersensor mit SHT10/BMP180, der derzeit auf einer Außenplatine HWRevision 1.2 mit der FW 0.15 von KC läuft, wird der TSL2561 nicht erkannt - auch nicht einzeln angeschlossen. Den INT-Anschluss vom TSL2562 habe ich dabei an A0 angeschlossen, also Pin 8 von JP2. Das ist doch richtig, sprich, der darf nicht offen bleiben, oder?
Nun war der nächste Versuch, auf die FW von MajorTom umzusteigen, das kompilieren war kein Problem, die folgenden Einstellungen habe ich für meine Umgebung vorgenommen:
#define USE_OTA_BOOTLOADER
... ID, etc. steht im Bootloader
//#define SENSOR_DS18X20 // Achtung, ONEWIRE_PIN define weiter unten muss zur HW passen!
//#define SENSOR_BME280 // Achtung, finitespace BME280 Library verwendet I2C Addr. 0x76, für 0x77 die Library anpassen!
#define SENSOR_BMP180
#define SENSOR_TSL2561 // Achtung, TSL2561_ADDR define weiter unten muss zur HW passen!
//#define SENSOR_MAX44009 // Achtung, MAX44009_ADDR define weiter unten muss zur HW passen!
#define SENSOR_SHT10 // Achtung, SHT10_DATAPIN/SHT10_CLKPIN define weiter unten muss zur HW passen!
#define SENSOR_DIGINPUT // Achtung, DIGINPUT_PIN define weiter unten muss zur HW passen!
... für meine Sensoren
// 2) für StepUp/StepDown: tmBatteryResDiv, sense pin A0, activation pin D9, Faktor = Rges/Rlow*1000, z.B. 470k/100k, Faktor 570k/100k*1000 = 5700
#define BAT_SENSOR tmBatteryResDiv<A0, 9, 5700>
... für den Spannungsteiler bei Step-Up auf HW Revision 1.2
Das sollte doch korrekt sein, oder?
Nun habe ich mit
./prepota.sh HB-UNI-Sensor1/HB-UNI-Sensor1.ino.eightanaloginputs.hex
unter OSX die Version ohne Bootloader in ein eq3-File gewandelt, dieses auf den Raspi kopiert und wollte OTA aktualisieren, leider passiert dabei reproduzierbar folgendes:
file corrupt. length:59336 expected:59540
Hier noch einmal die Größen der FW - Files:
-rw-r--r--+ 1 peter staff 18165 10 Feb 10:30 HB-UNI-Sensor1.ino
-rw-r--r--+ 1 peter staff 82167 10 Feb 10:54 HB-UNI-Sensor1.ino.eightanaloginputs.hex
-rw-r--r--+ 1 peter staff 59336 10 Feb 10:57 HB-UNI-Sensor1.ino.eightanaloginputs_201902101057.eq3
-rw-r--r--+ 1 peter staff 85688 10 Feb 10:54 HB-UNI-Sensor1.ino.with_bootloader.eightanaloginputs.hex
Wer hat eine Idee, warum prepota keine benutzbare Datei erzeugt? Die selbe prepota.sh habe ich für den Ultraschallsensor benutzt - da hat das konvertieren nach *.eq3 sauber geklappt.
Abschließende Frage:
Die 3 Sensoren sind doch gleichzeitig an einem Sensor möglich???
Danke Peter
Hallo Peter,
wenn ich mal auf die Schaltung schauen soll bräuchte ich den link exakt auf den Schaltplan den du verwendet hast.
Zu OTA kann ich überhaupt nichts sagen, noch nie gemacht/gebraucht.
Es sind so viele Sensoren möglich bis die 32k (minus bootloader) des mega328 voll sind, bitte das in der IDE nach dem build checken.
INT pin des TSL2561 wird bei mir nicht verwendet, kann offen bleiben.
Zur Schaltung passende TSL2561 Adresse eingestellt? 3 versch. sind möglich.
Wenn das immer noch nicht hilft, die Sensor init debug Ausgaben per Seriell checken ob da beim TSL2561 Fehler zu sehen sind.
Hallo Tom Major,
Ich bin eben noch einmal über den Sketch geflogen...
Laut meiner Schaltung (siehe pdf) muss die Spannungsmessung so erfolgen:
// 2) für StepUp/StepDown: tmBatteryResDiv, sense pin A0, activation pin D9, Faktor = Rges/Rlow*1000, z.B. 470k/100k, Faktor 570k/100k*1000 = 5700
//#define BAT_SENSOR tmBatteryResDiv<A0, 9, 5700>
#define BAT_SENSOR tmBatteryResDiv<A1, 7, 5700>
Da ich mitbekommen habe, dass Du die F103 benutzt, habe ich das hier
//#define USE_OTA_BOOTLOADER
auch noch einmal auskommentiert, bei mir steht im Bootloader ja die F102.
Wie komme ich an die richtige TSL2561 Adresse?
Danke Peter
bei dir liegt laut Schaltplan die TSL2561 ADDR an low, also brauchst du TSL2561_ADDR_LOW hier
https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L100 (https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L100)
A1/D7 sieht gut aus für deinen Spannungsteiler.
OK, ich habe das auf TSL2561_ADDR_LOW geändert und, da prepota.sh ja irgendwie streikt, mir eine neue FW mit OTA Bootloader damit erzeugt (makeota.htm, F103 als ID, etc...).
nach einem
avrdude -p m328p -P usb -c usbasp -V -U flash:w:HB-UNI-Sensor1.ino.with_bootloader.VTU4426568.hex
blinkt die LED immer nur in Abständen lang, kurz, kurz - da gibt es noch ein Problem, nur welches?
Nach dem Flashen mit der alten 0.15'er FW lebt der Sensor wieder - nur eben ohne TSL2561.
Iregend etwas muss ich bestimmt noch anpassen...
Peter
Am seriellen Monitor der IDE erfolgt immer die folgende Ausgabe:
AskSin OTA Bootloader V0.7.0
TX bootloader sequence
Wait for CB msg
Timeout
CRC fail, Reboot
Also scheint beim Erzeugen der Firmware irgend etwas fehl zu schlagen, sodass prepota.sh kein sauberes eq3 File für ein OTA Update erzeugt und auch eine mit makeopa.htm erstellte Firmware mit Bootloader nicht sauber geflashed wird.
Wo ist mein Fehler? Muss ich den 328P vor dem Flashen noch einmal komplett löschen?
Danke Peter
Hi,
hattest du Toms Rat berücksichtigt?
Zitat von: Tom Major am 10 Februar 2019, 12:17:55
Es sind so viele Sensoren möglich bis die 32k (minus bootloader) des mega328 voll sind, bitte das in der IDE nach dem build checken.
Kann es sein, dass die FW zu groß ist?
Die IDE macht nach dem compilieren die folgende Ausgabe:
Der Sketch verwendet 29306 Bytes (95%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 1408 Bytes (68%) des dynamischen Speichers, 640 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
Wie groß ist jetzt der OTA Bootloader noch? Bzw. passt das noch zusammen mit diesem?
Peter
Wie gesagt, habe selber noch nichts mit OTA gemacht, aber die sizes kurz mal geprüft:
Der bootloader 'Bootloader-OTA-atmega328.hex' braucht 4K (sieht man im hex file, geht bei 0x7000 los).
Damit darf dein sketch mit OTA maximal 32k -4k = 28672 bytes groß sein.
Ohne OTA Feature würde alles reinpassen.
Du kannst noch versuchen, alle Debug Ausgaben zu deaktivieren, ob es dann mit dem 4K bootloader passt
#define NDEBUG
Zitat von: Tom Major am 10 Februar 2019, 17:01:28
Wie gesagt, habe selber noch nichts mit OTA gemacht, aber die sizes kurz mal geprüft:
Der bootloader 'Bootloader-OTA-atmega328.hex' braucht 4K (sieht man im hex file, geht bei 0x7000 los).
Damit darf dein sketch mit OTA maximal 32k -4k = 28672 bytes groß sein.
Ohne OTA Feature würde alles reinpassen.
Du kannst noch versuchen, alle Debug Ausgaben zu deaktivieren, ob es dann mit dem 4K bootloader passt
#define NDEBUG
Danke! Das (ohne OTA) wollte ich gestern auch noch versuchen, nur leider reagiert der 328P derzeit auf nichts mehr - da habe ich den wohl zerschossen? Ein 'avrdude -e' war wohl das letzte, was er angenommen hat. Danach wollte ich Fuses setzen/prüfen - nada...
Naja - verbuchen als Lehrgeld! Das passiert, wenn man zu ungeduldig ist :( >:(
Mit Pech darf ich den jetzt auslöten; dafür ist erst am WE wieder Zeit.
Danke Peter
Ich habe es auch schon 2x (aus Unachtsamkeit) geschafft, den 328P zu "bricken".
OSC-Fuses falsch gesetzt und schon war ich ausgesperrt.
Es gibt im Netz ein paar Anleitungen, wie man ihn wieder zum Leben erweckt.
Hier zB eine: https://www.avrfreaks.net/forum/ok-ive-bricked-my-chip
Ich hab den Diamex ISP, der liefert schon an Pin3 schon einen 1MHz Takt mit, das hat mir die Reanimation recht einfach gemacht.
Viel Erfolg!
Du meinst den hier: https://www.diamex.de/dxshop/Diamex-ALL-AVR-ISP-Programmer (https://www.diamex.de/dxshop/Diamex-ALL-AVR-ISP-Programmer)?
Peter
Diesen benutze ich: https://www.diamex.de/dxshop/USB-ISP-Programmer-fuer-Atmel-AVR-Rev2
Zitat von: jp112sdl am 11 Februar 2019, 10:55:28
Diesen benutze ich: https://www.diamex.de/dxshop/USB-ISP-Programmer-fuer-Atmel-AVR-Rev2
Danke, das ist dann mein 3. Programmer (und hoffentlich der letzte ;))...
Peter
...wenns halt daran liegt.
Ist nur ein Mutmaßung meinerseits gewesen.
Zitat von: PSI69 am 11 Februar 2019, 08:40:18
Danke! Das (ohne OTA) wollte ich gestern auch noch versuchen, nur leider reagiert der 328P derzeit auf nichts mehr - da habe ich den wohl zerschossen? Ein 'avrdude -e' war wohl das letzte, was er angenommen hat. Danach wollte ich Fuses setzen/prüfen - nada...
Naja - verbuchen als Lehrgeld! Das passiert, wenn man zu ungeduldig ist :( >:(
Mit Pech darf ich den jetzt auslöten; dafür ist erst am WE wieder Zeit.
Danke Peter
Entweder du hast nur die Fuses verstellt, dann kann externen Takt helfen, das wieder zu richten, ohne neuen Programmer, der link von Jerome enthält Infos für einen 1MHz Hilfstakt dafür.
Oder der AVR ist zerstört, hast du zufällig einen USBasp verwendet?
siehe auch
https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT#warnung-vor-dem-flashen-von-33v-ger%C3%A4ten-mit-usbasp-klones (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT#warnung-vor-dem-flashen-von-33v-ger%C3%A4ten-mit-usbasp-klones)
Zitat von: Tom Major am 11 Februar 2019, 12:48:06
Oder der AVR ist zerstört, hast du zufällig einen USBasp verwendet?
Den 328P mit 5V zerstören?
Zitat von: Tom Major am 11 Februar 2019, 12:48:06
Oder der AVR ist zerstört, hast du zufällig einen USBasp verwendet?
siehe auch
https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT#warnung-vor-dem-flashen-von-33v-ger%C3%A4ten-mit-usbasp-klones (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT#warnung-vor-dem-flashen-von-33v-ger%C3%A4ten-mit-usbasp-klones)
USBasp ja, aber keinen Clone mehr, der bei 3.3V Betriebsspanung 5V Pegel ausgibt; das war mein erster Programmer. :D Am Wochenende bin ich schlauer. Da wird ja auch der Diamex eingetroffen sein.
Peter
Zitat von: jp112sdl am 11 Februar 2019, 12:51:51
Den 328P mit 5V zerstören?
Moin Jerome :D.
du kannst dich nicht mehr an den thread im orangen Forum erinnern? AVR und CC1101 hängen an 3V, der USBasp Klone programmiert aber mit 5V Pegel (trotz des 3,3V Jumpers!) -> very bad :'( :'(, außerhalb der Spec beim AVR.
Einige Cortex-M3 Arms wie LPC oder STM32 können das, dort steht dann explizit: 5V tolerant.
Zitat von: Tom Major am 11 Februar 2019, 17:32:18
du kannst dich nicht mehr an den thread im orangen Forum erinnern?
Doch - kann ich.
Und die Schlussfolgerung war m.M.: Ohne CC1101 kann man den 328P ruhig mit 5V flashen!?
Bei den 5V Pro Mini Boards ist ja letztlich nix anders, außer der 16MHz Quarz und natürlich der 5V LDO. Aber der AVR ist ja derselbe...
Nein, hat überhaupt nichts mit LDO usw. zu tun, es geht alleine um die Spannung an den AVR Pins bezogen auf seine VCC die gerade anliegt.
Dass der AVR natürlich prinzipiell 5V kann ist hier nicht das Thema.
32.1. Absolute Maximum Ratings
Voltage on any Pin except RESET
with respect to Ground
-0.5V to V CC +0.5V
Zitat von: Tom Major am 11 Februar 2019, 18:23:25
Dass der AVR natürlich prinzipiell 5V kann ist hier nicht das Thema.
Ok, dann lag hier das Missverständnis..
Wenn man den USBasp halt gänzlich auf 5V belässt (VC), dann sollte doch alles ok sein?
Zitat von: jp112sdl am 11 Februar 2019, 22:00:03
Ok, dann lag hier das Missverständnis..
Wenn man den USBasp halt gänzlich auf 5V belässt (VC), dann sollte doch alles ok sein?
Solange man 5V Geräte mit dem USBasp flasht, kein Problem.
Für ein AskSinPP Gerät mit CC1101 dran leider schwierig da dies der CC1101 nicht verträgt..
Warnung vor dem Flashen
von 3,3V Geräten mit USBasp Klones
https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/Sensor_PLHT#warnung-vor-dem-flashen-von-33v-ger%C3%A4ten-mit-usbasp-klones
Nur mal für mich als Laien:
Also wenn ich 3,3 V Versorgungsspannung am Atmel habe, dann darf ich nicht die IO-Pins mit 5V bedienen, ja? Wenn ich mit 5 V versorge, dann ist es logischerweise ok auch die IO-Pins mit 5 V zu betreiben?
Genau so ist es.
Hallo Tom, - kurze Frage.
Ich habe in meinen HB-UNI-Sensor1 inzwischen einen DS18X20 eingebaut. Der Sensor funktioniert und liefert Temperaturwerte (sichtbar in Serieller Monitor).
Ich glaube aber, dass in FHEM die Temperaturwerte vom BME280 ankommen und nicht die vom DS18X20.
Muss ich in Sketch die Zeile
temperature10 = bme280.temperature();
auskommentieren oder müsste das so gehen ?
Danke
Gregor
Übrigens mein Bewegungssensor funktioniert jetzt mit HB-UNI-Sensor1. Ich habe, wie Du vorgeschlagen hast, den Interrupt während des Sendevorgangs 'disabled'. Jetzt wird kein Signal an A0 erkannt, während gesendet wird.
Eventuell hast du einen älteren Stand vom Unisensor.
Ich habe vor ein paar Wochen die Logik so geändert dass die DS18 Temp. der BME280 Temp. vorgezogen wird, das war eine Anfrage von harvey, siehe "Issues" auf github.
Das Vorziehen passiert hier:
https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L359 (https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L359)
Gilt nur wenn beide vorhanden (definiert) sind. Hilft das?
Im seriellen Monitor kann man auch die Messwerte der Sensoren sehen und somit prüfen welche an die Zentrale übertragen werden. Das hast du ja auch schon gemacht denke ich, nur noch mal als allgemeiner Hinweis.
Hallo Tom,
ja, da war ich also auf der richtigen Spur. Das Tauschen der defines BME280 und DS18X20 ist universeller.
Danke, Gregor
Hallo Tom,
falls Du die Änderung von mir noch einbauen willst. Damit wird ein ungewollter Interrupt durch den Sendevorgang vermieden, falls der Sensor (z.B. PIR oder Radar Sensor RCWL-0516 sehr empfindlich ist.
Änderung HB-UNI-Sensor1.ino
1.
virtual void trigger(AlarmClock& clock)
{
uint8_t msgcnt = device().nextcount();
++ digitalInput.disableINT(); // Interrupt abschalten, könnte durch Senden ausgelöst werden
measure();
msg.init(msgcnt, temperature10, airPressure10, humidity, brightness, digInputState, batteryVoltage, device().battery().low());
device().sendPeerEvent(msg, *this);
// reactivate for next measure
uint16_t updCycle = this->device().getList0().updIntervall();
set(seconds2ticks(updCycle));
clock.add(*this);
++ digitalInput.enableINT(); // Interrupt einschalten
}
2.
#ifdef SENSOR_DIGINPUT
if (digitalInput.notifyEvent()) {
digitalInput.resetEvent();
DPRINTLN(F("DIGINPUT change"));
digitalInput.disableINT();
sdev.channel(1).forceSend();
delay(250); // Entprellen
-- digitalInput.enableINT(); // nicht erforderlich da nach Senden ausgeführt
}
3. in Sens_DIGINPUT.h
void enableINT()
{
if (digitalPinToInterrupt(_pin) == NOT_AN_INTERRUPT) {
enableInterrupt(_pin, isr, FALLING);
DPRINTLN(F("Sens_DIGINPUT enable INT"));
} /*else {
attachInterrupt(digitalPinToInterrupt(_pin), isr, CHANGE);
DPRINTLN(F("Sens_DIGINPUT attach INT"));
}*/
}
++ void disableINT()
++ {
++ disableInterrupt(_pin);
++ DPRINTLN(F("Sens_DIGINPUT disable INT"));
++ }
uint8_t pinState() { return digitalRead(_pin); }
Gruß
Gregor
Zitat von: PSI69 am 11 Februar 2019, 08:40:18
Mit Pech darf ich den jetzt auslöten; dafür ist erst am WE wieder Zeit.
Er lebt wieder! Externen Takt vom Diamex angelegt, Fuses neu gesetzt, geflashed incl. Debug und ohne OTA, läuft...
Nur das hier:
#ifdef SENSOR_TSL2561
#include "Sensors/Sens_TSL2561.h" // HB-UNI-Sensor1 custom sensor class
#define TSL2561_ADDR TSL2561_ADDR_FLOAT
//#define TSL2561_ADDR TSL2561_ADDR_LOW
#endif
... mußte ich wieder auf _FLOAT ändern, damit der TSL2561 erkannt wird.
Schönes Restwochenende!
Peter
Zitat von: gregor am 16 Februar 2019, 20:46:36
Hallo Tom,
falls Du die Änderung von mir noch einbauen willst. Damit wird ein ungewollter Interrupt durch den Sendevorgang vermieden, falls der Sensor (z.B. PIR oder Radar Sensor RCWL-0516 sehr empfindlich ist.
Gruß
Gregor
Hi Gregor,
ja, so in etwa hatte ich mir das auch damals vorgestellt.
Wobei das disableINT/enableINT nicht in die Funktion trigger() gehört sonder unten in den #ifdef SENSOR_DIGINPUT Block, weil sonst der sketch nicht kompiliert wenn SENSOR_DIGINPUT nicht aktiviert ist.
Ich zögere noch etwas mit der Umsetzung da ich gerade mit fhemfreund einigen Austausch bezüglich PIR und HB-UNI-Sensor1 habe, ich habe die aktuellen Erkenntnisse heute hier veröffentlicht:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1#bewegungsmelder-mit-pir-as312-am-digitalen-eingang (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1#bewegungsmelder-mit-pir-as312-am-digitalen-eingang)
Bei ihm treten mit dem Transistor keinerlei Probleme auf.
Außerdem glaube ich dass wegen dem 20k in Reihe am Ausgang des AS312
https://unusualelectronics.co.uk/as312-am312-mini-pir-module-review/ (https://unusualelectronics.co.uk/as312-am312-mini-pir-module-review/)
und aktiviertem pull-up am dig. Eingang der AVR einen verbotenen digitalen Pegel bekommt (bei Low), das könnte auch die Ursache für die Empfindlichkeit/Fehlauslösungen sein.
Edit: was ich über die Stelle für disableINT/enableINT schrieb klappt leider nur für das wake-up bei PIR Aktivität, nicht für das reguläre wake-up über Sendeintervall. Deswegen muss man das disableINT/enableINT wohl in trigger() lassen, braucht aber dann zwei weitere #ifdef SENSOR_DIGINPUT Blöcke.
... es ist tatsächlich so, wie Tom beschreibt. Er hat (wie oben beschrieben) meine Infos (inkl. Bilder etc.) auf seinen Github hochgeladen. Wir haben z.Z. meinen Universalsensor inkl. PIR im Test - ich habe mal einen Counter (digitalInputCount) im Fhem definiert, der die PIR Trigger zählt (siehe Bild im Anhang. Zur Info: die Anzahl der Sendezyklen ist 2x so hoch, da je PIR Trigger der Zustand 2x übertragen wird - nämlich an/aus). Der Sensor läuft seit ca. 9 Tagen mit einer CR2450 Knopfzelle und bis dato sieht es schon mal nicht schlecht aus. Angedacht ist noch, die Anzahl der Sendezyklen zu reduzieren, da der PIR Sensor alle 2 sek. einen Update liefert - daher auch die hohe Anzahl von Sendezyklen in der kurzen Zeit.
Andreas
Mal ne Frage bzgl. Lagerung von Bauteilen:
Spricht etwas dagegen, SMD-Hühnerfutter wie Widerstände und Kondensatoren aus diesen Papp-Bändern rauszunehmen und dann lose in solche Platikdöschen umzufüllen?
aliexpi.com/tfk
Würde das Gleiche auch mit komplexeren Bauteile wie BME280 o.ä. gehen? Ich denke mal, mindestens bei allem was verbiegbare Teile hat, sollte man das aber nicht machen, oder?
Zitat von: vbs am 08 März 2019, 21:31:57
Mal ne Frage bzgl. Lagerung von Bauteilen:
Spricht etwas dagegen, SMD-Hühnerfutter wie Widerstände und Kondensatoren aus diesen Papp-Bändern rauszunehmen und dann lose in solche Platikdöschen umzufüllen?
Link funktioniert bei mir zwar nicht, aber ich mache das ähnlich. Für aktive Bauteile würde ich ESD Dosen verwenden oder sie in den (ESD)-Bändern lassen.
Gruß PeMue
Ah ok danke... Link hab ich irgendwie versemmelt scheinbar... neuer Versuch
100 Widerstände sind echt klein :o Oder meine "Mäuseklos" extrem groß...
Ok, hab jetzt einen Tom-Sensor gebastelt und da lebt etwas :D
Ein aktuelles Problem:
Immer wenn ich ein "getConfig" mache und der Sensor diese Nachrichten verarbeitet, hab ich folgendes im Log:
2019.04.03 23:01:43.251 3 : CUL_HM set HM_A5A502 statusRequest
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 batVoltage: 3.38
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 battery: ok
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 brightness: 88000
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 digitalInput: 0
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 humidity: 88
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 pressure: 1088.0
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 T: 18.8 P: 1088.0 H: 88 B: 88000 I: 0
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 temperature: 18.8
2019.04.03 23:01:43.874 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.874 1 : stacktrace:
2019.04.03 23:01:43.874 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.874 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.875 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.875 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.875 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.875 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.875 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.875 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.875 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.875 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.875 1 : stacktrace:
2019.04.03 23:01:43.875 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.875 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.875 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.875 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.875 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.875 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.875 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.875 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.876 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.876 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.876 1 : stacktrace:
2019.04.03 23:01:43.876 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.876 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.876 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.876 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.876 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.876 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.876 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.876 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.876 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.876 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.876 1 : stacktrace:
2019.04.03 23:01:43.876 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.877 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.877 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.877 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.877 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.877 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.877 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.877 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.877 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.877 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.877 1 : stacktrace:
2019.04.03 23:01:43.877 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.877 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.877 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.877 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.877 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.877 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.877 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.877 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.877 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.877 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.877 1 : stacktrace:
2019.04.03 23:01:43.878 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.878 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.878 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.878 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.878 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.878 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.878 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.878 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.878 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.878 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.878 1 : stacktrace:
2019.04.03 23:01:43.878 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.878 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.878 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.878 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.878 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.878 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.878 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.878 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.878 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.878 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.878 1 : stacktrace:
2019.04.03 23:01:43.879 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.879 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.879 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.879 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.879 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.879 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.879 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.879 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.879 1 : main::CallFn called by fhem.pl (744)
Habt ihr das auch? Ist das ein Problem bei mir, mit der Firmware oder allgemein mit 10_CUL_HM? ???
So sieht mein Device aus:
Historie löschen
Internals:
DEF A5A502
FUUID 5ca3923e-f33f-af31-f00a-6d4e5662fbab03bf
IODev sys_culHm
LASTInputDev sys_culHm
MSGCNT 65
NAME HM_A5A502
NOTIFYDEV global
NR 630
NTFY_ORDER 50-HM_A5A502
STATE T: 18.8 P: 1088.0 H: 88 B: 88000 I: 0
TYPE CUL_HM
chanNo 01
lastMsg No:01 - t:70 s:A5A502 d:<VCCUID> 00BC2A8058000157C0000D36
protCmdDel 3
protLastRcv 2019-04-03 23:02:25
protRcv 55 last_at:2019-04-03 23:02:25
protResnd 12 last_at:2019-04-03 23:01:46
protResndFail 1 last_at:2019-04-03 22:29:47
protSnd 46 last_at:2019-04-03 23:01:44
protState CMDs_pending
rssi_at_sys_culHm cnt:65 min:-68 max:-56 avg:-61.13 lst:-60
rssi_sys_culHm cnt:10 min:-79 max:-72 avg:-76.1 lst:-77
sys_culHm_MSGCNT 65
sys_culHm_RAWMSG 0501003C018470A5A502<VCCUID>00BC2A8058000157C0000D36
sys_culHm_RSSI -60
sys_culHm_TIME 2019-04-03 23:02:25
READINGS:
2019-04-03 22:32:32 Activity alive
2019-04-03 22:31:00 CommandAccepted yes
2019-04-03 22:32:32 D-firmware 1.2
2019-04-03 22:32:32 D-serialNr UNISENS001
2019-04-03 23:01:43 PairedTo <VCCUID>
2019-04-03 22:31:13 R-pairCentral <VCCUID>
2019-04-03 23:01:43 RegL_00. 00:00 05:40 0A:F1 0B:55 0C:44 12:15 14:06 20:02 21:58 22:00 23:00
2019-04-03 23:02:25 batVoltage 3.38
2019-04-03 23:02:25 battery ok
2019-04-03 23:02:25 brightness 88000
2019-04-03 23:02:25 digitalInput 0
2019-04-03 23:02:25 humidity 88
2019-04-03 22:50:17 powerOn 2019-04-03 22:50:17
2019-04-03 23:02:25 pressure 1088.0
2019-04-03 23:01:44 recentStateType info
2019-04-03 23:02:25 state T: 18.8 P: 1088.0 H: 88 B: 88000 I: 0
2019-04-03 23:02:25 temperature 18.8
cmdStack:
helper:
HM_CMDNR 1
PONtest 1
cSnd 01<VCCUID>A5A5020103,01<VCCUID>A5A502010E
mId F103
peerFriend
peerIDsRaw ,00000000
peerOpt p:UniSensor1
regLst 0
rxType 156
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newCh 1
newChn +A5A502,02,00,00
nextSend 1554325345.15859
rxt 2
vccu VCCU
p:
A5A502
00
00
00
prefIO:
sys_culHm
mRssi:
mNo 01
io:
sys_culHm:
-56
-56
prt:
bErr 0
sProc 2
sleeping 0
wuReSent 2
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rssi:
at_sys_culHm:
avg -61.1384615384615
cnt 65
lst -60
max -56
min -68
sys_culHm:
avg -76.1
cnt 10
lst -77
max -72
min -79
shadowReg:
tmpl:
Attributes:
IODev sys_culHm
IOgrp VCCU:sys_culHm
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.2
model HB-UNI-Sensor1
peerIDs 00000000,
room CUL_HM
serialNr UNISENS001
subType UniSensor1
Danke! Und vor allem danke und Hut ab für die tolle Dokumentation des Sensors!
Hm, also dann wirklich ein Problem von CUL_HM? hab es dort mal gepostet:
https://forum.fhem.de/index.php/topic,99333.0.html
Habe nur auf die Schnelle das hier gefunden
https://forum.fhem.de/index.php/topic,59456.30.html (https://forum.fhem.de/index.php/topic,59456.30.html)
da ging es auch um einen Selbstbau-Sensor.
Ich stecke aber zu wenig in den FHEM CUL interna drin, kann nicht sagen woran es liegt.
Hat eigentlich @fhemfreund auch das Problem bei seinem Nachbau?
Zitat von: Tom Major am 04 April 2019, 23:56:48
Hat eigentlich @fhemfreund auch das Problem bei seinem Nachbau?
Hat er eigentlich nicht ;-) Stacktraces habe ich bis jetzt in meinen Logs nicht gefunden. Was ich aber in vbs's log sehe, dass er ein HMUARTLGW hat. Habe meine Sensoren direkt via HM-MOD-RPI-PCB in Verbindung mit einem USB-UART konfiguriert. Meine CUL-HM ist vom '10_CUL_HM.pm 17532 2018-10-14 17:50:45Z martinp876'.
Andreas
Hmm, dann liegt es eventuell gar nicht am Perl script für den UniSensor? Welche 10_CUL_HM.pm Version hat denn @vbs ?
Zitat von: fhemfreund am 05 April 2019, 01:36:35
Hat er eigentlich nicht ;-) Stacktraces habe ich bis jetzt in meinen Logs nicht gefunden. Was ich aber in vbs's log sehe, dass er ein HMUARTLGW hat. Habe meine Sensoren direkt via HM-MOD-RPI-PCB in Verbindung mit einem USB-UART konfiguriert. Meine CUL-HM ist vom '10_CUL_HM.pm 17532 2018-10-14 17:50:45Z martinp876'.
Hm, bist du sicher? Nach meinem Verständnis ist deine Version zwar etwas älter, aber "p" sollte dort schon vorhanden sein. Du kriegst wirklich keine Warning wenn du "getConfig" machst und dann per Tastendruck den Befehl prozessieren lässt?
Wenn du kein HMUARTLGW verwendest: was für ein IO-Modul benutzt du stattdessen? Ich dachte eigentl. HM-MOD-RPI-PCB könne man nur damit ansteuern.
Also vbs benutzt die aktuelle Version:
10_CUL_HM.pm 19069 2019-03-30 06:20:52Z martinp876Erklärung für das Problem ist mMn das hier:
https://forum.fhem.de/index.php/topic,99333.msg927259.html#msg927259
Zitat von: vbs am 05 April 2019, 21:40:36
Hm, bist du sicher?
...
Wenn du kein HMUARTLGW verwendest: was für ein IO-Modul benutzt du stattdessen? Ich dachte eigentl. HM-MOD-RPI-PCB könne man nur damit ansteuern.
...
Kann mich nur wiederholen: Stacktrace-Meldungen habe ich keine. Perl-Warnings (Use of uninitialized value in string eq at) habe ich ein paar. Allerdings fallen die zeitlich nicht in meine getConfig Aktionen (habe sie z.B. auch in Verbindung mit dem HMCCU Modul). Wenn ich einen weiteren Sensor aufbaue (meine 2 bestehenden sind z.Z. in einem Dauertest), kann ich ja nochmal explizit danach schauen ...
Setze auch das HMUARTLGW Modul ein - dachte erst, das wäre ein Hinweis bei dir auf eine WLAN Lösung in Verbindung mit dem HM-MOD-RPI-PCB. Falls nein ist es bei uns gleich (habe es wie gesagt direkt via USB UART Modul angebunden).
Andreas
neue Version (PR von vbs) ist aktiv.
Wenn ich das richtig sehe kam die Änderung die die Warning verursacht mit den 'p' Vergleichen hier rein:
https://github.com/mhop/fhem-mirror/commit/ca89e7b814021fba7e264d530e0a1493ca88262f#diff-ac12dd1cca162f8cf3a75333d9ba427dR7875 (https://github.com/mhop/fhem-mirror/commit/ca89e7b814021fba7e264d530e0a1493ca88262f#diff-ac12dd1cca162f8cf3a75333d9ba427dR7875)
Liegt zeitlich etwas vor fhemfreund's Version, aber vielleicht hat es das commit nicht in die nächste release geschafft, keine Ahnung.
Hallo zusammen,
hat noch jemand von euch eine Platine für mich über?
Werden demnächst wieder welche bestellt?
Wo habt ihr die bestellet?
Danke und viele Grüße
Ja, ich kann dir eine bis zwei schicken, wenn du mir deine Adresse per PM schickst.
Hab ich vor ein paar Wochen bei https://jlcpcb.com machen lassen.
Hm, ich hätte mal ein Problem leider. Vielleicht hat jemand ja einen Tipp...
Und zwar hab ich den Sensor aufgebaut mit zwei Sensoren und das war erstmal alles ok. Nun hab ich noch den Step-Up dazu gebastelt. Soweit ich weiß, macht der ja aus verschiedenen Eingangsspannungen die benötigten 3,3 V.
Das Problem ist nun, dass der Controller sehr früh aussteigt, wenn ich die Spannung absenke. Also wenn ich 3,3 V anlege, dann läuft er stabil. Eben so bei z.B. 2,8 V. Wenn ich jedoch auf 2,5 V runterregele, dann läuft er erst weiterhin (und es werden auch 3,3 V am StepUp ausgegeben), aber sobald dann der Controller senden will, bricht die Spannung offenbar ein (auf 1,0 V glaub ich) und dann scheint der Controller zu stehen.
In dem Moment steigt dann komischerweise auf einmal auch der Stromverbrauch von 0,00 A (also sehr wenig) auf 0,07 A (und mein günstiges regelbares Netzteil fängt an so komische sirrende Geräusche zu machen).
Ich hätte eigentlich erwartet, dass ich die Spannung bis ca. 2,1 V runterregeln kann und der Controller weiter läuft, oder? Zumindest ist 2,1 V ja als LowBatVoltage eingetragen.
Bin da ziemlicher Anfänger. Ist das normal bzw. jemand eine Idee, woran das liegen könnte?
Der MAX muss bis hinunter auf 1V arbeiten, mach mal diesen Test ob er mit 1V Vin immer noch 3,3V am Ausgang hat.
Welche Spule hast du verwendet?
Ja, ich hatte das Datenblatt auch naiv so verstanden, dass der StepUp bis 0,8 V arbeiten müsste.
Wenn ich 1 V rein gebe, dann messe ich 3,26 V am Ausgang. Also müsste ok sein. Netzteil zeigt dabei einen Strom von 10 mA an.
Spule ist "LQH43CN100K03L" von hier:
https://www.conrad.de/de/p/murata-lqh43cn100k03l-induktivitaet-smd-1812-10-h-0-65-a-1-st-537082.html
Übrigens
ZitatBin da ziemlicher Anfänger...
sehe gerade du hast den BME und MAX als Chips und nicht als Breakout Board bestückt, das ist absolut nicht Anfängerhaft ;)
1V Test passt.
Hast du den MAX auch von Conrad?
Irgendwas passt bei deinem StepUp nicht wenn mehr Strom angefordert wird.
- alle Lötstellen bei den StepUp Bauteilen nachlöten
- 2x 10u und 1x22u nachgemessen dass die die Werte haben?
Zitat von: Tom Major am 13 April 2019, 12:34:20
Übrigenssehe gerade du hast den BME und MAX als Chips und nicht als Breakout Board bestückt, das ist absolut nicht Anfängerhaft ;)
Danke für die Blumen. Ich bin zwar lernwillig, aber mache sowas zum ersten Mal (YouTube & AliExpress machen's möglich ;)). Es mangelt noch ziemlich an Verständnis und Erfahrung.
Zitat von: Tom Major am 13 April 2019, 12:34:20
1V Test passt.
Hast du den MAX auch von Conrad?
Nee von Conrad ist nur die Spule. Der Rest ist von Aliexpress. Der StepUp ist der hier:
https://de.aliexpress.com/item/5PCS-MAX1724EZK33-MAX1724EZK-MAX1724EZ-MAX1724E-MAX1724-SOT23-5/32353066414.html?spm=a2g0s.9042311.0.0.27424c4dYj3ZYx
Zitat von: Tom Major am 13 April 2019, 12:34:20
Irgendwas passt bei deinem StepUp nicht wenn mehr Strom angefordert wird.
- alle Lötstellen bei den StepUp Bauteilen nachlöten
- 2x 10u und 1x22u nachgemessen dass die die Werte haben?
Hatte gestern tatsächlich schon mal genau das gemacht: Also Spule, StepUp und Kondensator wieder runtergelötet und Kondensatoren durchgemessen. Dann neu aufgelötet. Leider keine Verbesserung.
Jedoch hatte ich irgendwie Schwierigkeiten beim Messen der Kondensatoren mit meinem Multimeter. Hab jetzt ergoogelt, dass man wohl die Kondensatoren zum Messen erstmal entladen muss etc. Werde das also nochmal machen. Bin aber auch nicht sicher, ob mein Hausfrauen-Multimeter evtl. einfach überfordert ist.
Wie hoch ist die Wahrscheinlichkeit, dass der StepUp einen Schaden hat? Kommt sowas vor bzw. vielleicht hab ich ihn zu heiß gebadet? Ich könnte den mal austauschen...
Danke für die Hilfe auf jeden Fall schon mal. Ich selber weiß das leider momentan nicht so richtig weiter.
Mir ist da etwas aufgefallen:
Die Kondensatoren sind doch alles Keramik-Kondensatoren, oder? Gemäß meinem Halbwissen haben die keine Polung. In dem Schaltplan des Controllers hat jedoch C10 ein anderes Symbol als die anderen und bei ihm ist eine Polung angegeben ist. Muss C10 eine andere Art von Kondensator sein?
Ich habe (auch für C10) diese Kondensatoren:
https://de.aliexpress.com/item/100-st-cke-10PF-47UF-1206-SMD-500-V-X7R-Fehler-10-10-uf-106-K/32880416347.html?spm=a2g0s.9042311.0.0.27424c4dpp13il
C10 ist ein Elko zur Glättung, geht wahrscheinlich auch ohne, Unterschied VOut mit/ohne Elko:
https://github.com/TomMajor/SmartHome/tree/master/HB-SEC-WDS-2#option-1-step-up-konverter-zum-betrieb-mit-1-mignon-aa-batterie-oder-akku (https://github.com/TomMajor/SmartHome/tree/master/HB-SEC-WDS-2#option-1-step-up-konverter-zum-betrieb-mit-1-mignon-aa-batterie-oder-akku)
Kondensatoren mit low ESR sind u.a. entscheidend bei DC/DC (und die Spule aber die passt ja), normalerweise habe MLCC einen low ESR, aber nur von dem Ali link kann man das natürlich nicht beurteilen.
Würde empfehlen denDC/DC erstmal extern aufzubauen und solange C,L,MAX zu variieren bis es geht ;) und das Ganze bei niedriger Vin und Laststrom, z.B. 1V/50mA
Quasi als Bauteilqualifizierung vorab.
Mehr fällt mir leider dazu nicht ein.
Danke dir erstmal!
Ich hab das mal gemacht, also nochmal auf einer neuen Platine nur den StepUp aufgebaut. Verhält sich leider grundsätzlich ähnlich/genau so :-[
Also das Ding erzeugt bis zu einer VIN von 1,0 V die 3,3 V (ohne Last).
Hab getestet mit VIN 2,5V (bei 1,0 V sieht's schlechter aus):
Wenn ich als Last 150 Ohm dran hänge, dann liefert er weiterhin stabil 3,3 V. Mein Netzteil zeigt dann 20 mA an.
Wenn ich jedoch 48 Ohm Last dran hänge, dann geht Spannung auf 2,1 V runter :( Entspräche einem Strom von knapp 70 mA. Sieht aus, als würde das den kleinen Kumpel überfordern?!
So ist Stand der Ding... ich gebe aber noch nicht auf...
siehe auch MAXIMUM OUTPUT CURRENT vs. INPUT VOLTAGE im Datenblatt
Bei 2,5V Vin müssen die 70mA bei 48 Ohm stabil erreichbar sein.
Unter den Annahmen
- MAX1724 ist Original und kein fake
- LQH43CN100K03L ist Original und kein fake
bleiben nur noch die C's.
Lises dir mal den Abschnitt Capacitor Selection durch.
Low ESR ist bei DC/DC Wandlern ziemlich wichtig.
Versuche es mit anderen C oder schalte mal zum Test jeweils 3 Stück parallel, das verringert auch den ESR.
Hm, ich würde auch prinzipiell dem MAX misstrauen wollen... :/
Ich glaube, ich bestelle nochmal Bauteile. Wären die hier ok?
MAX1724
https://de.rs-online.com/web/p/products/7833532/
10uF Kondensator (TDK X7R ist im Datenblatt empfohlen):
https://de.rs-online.com/web/p/keramik-multilayer-kondensatoren/7883017/
22uF
https://de.rs-online.com/web/p/keramik-multilayer-kondensatoren/9159347/
Ist ja eine super simple Schaltung... muss doch eigentlich so gehen... ?!
EDIT:
Ich seh gerade, dass rs-online eine UstId haben möchte beim Bestellen... das wird dann wohl nix werden für mich... grr...
Die Kondensatoren sehen gut aus.
Versuchs halt erst mal wie geschrieben je 3x 10u parallel an Eingang und Ausgang, geht ja einfach als Turm übereinanderzulöten.
Wenn es an den Cs liegt sollte diese Maßnahme eine Verbesserung bringen (ESR).
Ahh, verstehe, ok klar. Hab ich gemacht (siehe Bild)... natürlich wieder keine Änderung :(
Damit sind die Cs aus dem Rennen nehme ich an. Also bleiben für mich zwei Sachen übrig:
- der MAX hat einen Schaden
- ich mache/verstehe irgendwas ganz grundlegendes falsch
Langsam wird's echt eng ideenmäßig... Bleibt wohl nur nochmal irgendwo so einen MAX zu besorgen. Finde leider nur entweder Versender, die nicht an privat liefern (Farnell, Rs-Online) oder Versandkosten von 20€ verlangen (Mouser, Digikey). Werde mal weiter suchen..
Zitat von: vbs am 17 April 2019, 20:37:42
...
Langsam wird's echt eng ideenmäßig... Bleibt wohl nur nochmal irgendwo so einen MAX zu besorgen. Finde leider nur entweder Versender, die nicht an privat liefern (Farnell, Rs-Online) oder Versandkosten von 20€ verlangen (Mouser, Digikey). Werde mal weiter suchen..
...
RS hat einen Privatkunden Shop. Dein Bauteil bekommst du hier:
https://www.rsonline-privat.de/Products/ProductDetail/DC-DC-Wandler-MAX1724EZK33-T-Step-Up-TSOT-5-pin-150mA-7833532
Der Privatkunden Shop findet nicht immer alle Teile über die Suche - daher im regulären Shop suchen und die RS Best.-Nr. im Privat Shop eingeben.
Andreas
Hatte den Shop auch gefunden, aber genau wie du sagst, das Teil nicht gefunden... Dank für den Tipp!
Zitat von: vbs am 17 April 2019, 20:37:42
Ahh, verstehe, ok klar. Hab ich gemacht (siehe Bild)... natürlich wieder keine Änderung :(
Damit sind die Cs aus dem Rennen nehme ich an. Also bleiben für mich zwei Sachen übrig:
- der MAX hat einen Schaden
- ich mache/verstehe irgendwas ganz grundlegendes falsch
Langsam wird's echt eng ideenmäßig... Bleibt wohl nur nochmal irgendwo so einen MAX zu besorgen. Finde leider nur entweder Versender, die nicht an privat liefern (Farnell, Rs-Online) oder Versandkosten von 20€ verlangen (Mouser, Digikey). Werde mal weiter suchen..
Hätte wirklich gedacht dass deine C nicht so für DC/DC geeignet sind und dass eine 3fach Parallelschaltung helfen könnte. Da gehn mir langsam die Ideen aus. Als nächstes ev. die MAX Fake Theorie, k.A. wie wahrscheinlich die ist ...
Du betreibst das Ganze nicht zufällig an einer stark ungeglätten Netzteil-Versorgung nehem ich an? Könntest alternativ auch mal mit einer Batt.zelle testen ob irgendein Unterschied.
Naja, das ist so ein günstiger China-Strom:
https://de.aliexpress.com/item/Pr-zision-Spannung-Regler-KPS305D-30-v-5A-Labor-DC-Netzteil-0-1-v-0-01A/32924039089.html?spm=a2g0s.9042311.0.0.27424c4dYd6ML9
Also vielleicht ist das nicht gut... hatte mir nicht viel Chancen ausgerechnet, aber ich wollte eigentlich schon gestern mal ein anderes Netzteil aus der Firma testen. Hab ich dann aber vergessen. Hole ich jetzt aber nach.
Hallo vbs,
hat Dein Netzteil eine Strombegrenzung? Ich habe einen meiner Regler gerade durchgemessen: falls die Strombegrenzung des Netzteils "zuschlägt" geht die Spannung am Eingang (und am Ausgang) zurück und Du kannst den MAX1724 nur mit Spannug aus/an aus diesem Zustand herausholen. Ich liefere die Werte morgen nach, nur soviel: es fließen bei 1 V mit 50 Ohm Last ca. 250 mA am Eingang, relativ viel für eine Zelle NiMh Akku.
Gruß Peter
Zitat von: vbs am 18 April 2019, 11:59:38
Naja, das ist so ein günstiger China-Strom:
https://de.aliexpress.com/item/Pr-zision-Spannung-Regler-KPS305D-30-v-5A-Labor-DC-Netzteil-0-1-v-0-01A/32924039089.html?spm=a2g0s.9042311.0.0.27424c4dYd6ML9
Also vielleicht ist das nicht gut... hatte mir nicht viel Chancen ausgerechnet, aber ich wollte eigentlich schon gestern mal ein anderes Netzteil aus der Firma testen. Hab ich dann aber vergessen. Hole ich jetzt aber nach.
Einfach mal an einer Batteriezelle mit dem 48 Ohm Last-R testen.
Zitat von: PeMue am 18 April 2019, 13:38:26
hat Dein Netzteil eine Strombegrenzung? Ich habe einen meiner Regler gerade durchgemessen: falls die Strombegrenzung des Netzteils "zuschlägt" geht die Spannung am Eingang (und am Ausgang) zurück und Du kannst den MAX1724 nur mit Spannug aus/an aus diesem Zustand herausholen.
Ja, Strombegrenzung hat es, aber die hab ich schon hoch gedreht. Wenn die zu schlägt, denn bekommt man das auch mit, weil da so eine Modus-LED von grün auf rot geht (Constant Voltage -> Constant Current).
Zitat von: Tom Major am 18 April 2019, 13:55:08
Einfach mal an einer Batteriezelle mit dem 48 Ohm Last-R testen.
Ahh ok, auch ne gute Idee 8)
Hab jetzt ein "Array 3644A" hier. Sieht teuer aus und macht Krach. Leider selbes Verhalten...
Das mit der Batterie muss ich morgen mal in Ruhe probieren. Aber da gibt es dann wohl eigentlich keine Hoffnung mehr, denk ich.
Also dann wird es auf nen neuen MAX hinaus laufen... grummel...
Hallo zusammen,
ich habe meine gestrigen Messungen mit Ausgangswiderständen von 150 und 50 Ohm in ein Excel Sheet gepackt, Bilder anbei.
Fazit:
- Bei 50 Ohm Ausgangslast und 1 V Eingangsspannung geht der Eingangsstrom ziemlich hoch, vermutlich geht da ein (schlechter) Akku in die Knie (es fließt fast der 4-fache Strom am Eingang).
- Bei Betrieb mit einer Zelle (egal ob Batterie oder Akku) ist m.E. zwingend die Messung der Batteriespannung unter Last notwendig.
Gruß Peter
Danke dir, sehr interessant!
Werde mir jetzt MAX bei Rs-Online bestellen und dann bin ich gespannt! Ich werde von mir hören lassen ;)
Zitat von: PeMue am 19 April 2019, 16:47:00
Hallo zusammen,
ich habe meine gestrigen Messungen mit Ausgangswiderständen von 150 und 50 Ohm in ein Excel Sheet gepackt, Bilder anbei.
Fazit:
- Bei 50 Ohm Ausgangslast und 1 V Eingangsspannung geht der Eingangsstrom ziemlich hoch, vermutlich geht da ein (schlechter) Akku in die Knie (es fließt fast der 4-fache Strom am Eingang).
- Bei Betrieb mit einer Zelle (egal ob Batterie oder Akku) ist m.E. zwingend die Messung der Batteriespannung unter Last notwendig.
Gruß Peter
Interessante Messung.
50 Ohm bei 1V Vin ist mehr Ausgangsstrom als der MAX kann, das sieht man im Diagramm MAXIMUM OUTPUT CURRENT vs. INPUT VOLTAGE im Datenblatt und wird durch Peters Messung bestätigt.
Ich würde in etwa 75 Ohm Last (44 mA) für die Messung nehmen, um den Strom eines AskSinPP Gerätes während des Sendens zu simulieren (35mA CC1101 + CPU + Diverse).
Sooooo......
Hab jetzt neue MAX1724 bekommen von rsonline. Und tatsächlich: eingelötet und funktioniert wie es soll. Also irgendwas ist mit den Aliexpress-Dingern faul. Entweder sind das irgendwelche anderen Bauteil, oder sie sind kaputt oder gefälscht...
Also nun geht's endlich weiter! ;)
Danke nochmal an alle für Rat & Tat!
Sehr interessant, da war die Fake Theorie nicht ganz so abwegig.
Wenn du beide Chips nebeneinander mal hochauflösend fotografierst, irgendwelche Unterschiede beim Aufruck?
Hab mal Bilder gemacht. Sieht tatsächlich anders aus. Gehäuse sieht auch leicht anders aus. Ich selbst kann aber nicht einschätzen, ob solche Abweichungen normal sind bzw. ob die einfach mal auftreten (je nachdem in welchem Werk oder so gefertigt wurde?!).
Rechts ist der "gute" von RSOnline und links der faule von Aliexpress:
https://drive.google.com/open?id=1U5VpxnfYme7IWyOtIoKNR6fDgcnvAt3H
Ich dachte ja, dass es nun bei mir voran geht, aber ich hab gleich das nächste Problem:
Ich hab schon den StepUp und alles drum herum runtergelötet, aber ich hab jetzt einen zu hohen Stromverbrauch :( Ich teste mit dem "SleepTest.ino". Vor dieser ganzen StepUp-Geschichte waren die Ruheströme in Ordnung und ca. wie hier beschrieben:
https://github.com/TomMajor/SmartHome/tree/master/Info/Ruhestrom
Nun habe ich beim Senden ca. 7 mA und in der Ruhephase 2,6 mA bei 3,3 V Eingangsspannung ohne StepUp.
Fuses sind wie im Screenshot.
Ich hab momentan keine schlauere Idee als nach und nach Teile runter zu löten bis nur noch der Atmel drauf sitzt und zu gucken, was passiert. Gerade die Sensoren, würde ich jedoch sehr ungern wieder runter löten :/
- SleepTest.ino ist unverändert
- Fuses sind mMn ok
- bleibt nur Hardware? :/
Evtl. hat ja noch jemand eine andere Idee, was ich momentan übersehe...
Controller:
https://drive.google.com/open?id=1Pi1pP5d7z3HuolDdcJ2N2fOBOBu-W4DC
Zunächst musst du die BDC ausschalten. Würde dann nochmal messen. Für die Fuses siehe auch https://github.com/TomMajor/SmartHome/blob/master/Info/Bootloader/mega328/Quarz_Osc/fuses1.png. Dabei aber die Fuse auf internen Osc. lassen ! Damit bekommt man z.B. den Ruhestrom mit 2 Sensoren + PIR auf ca. 17uA. LDOs würde ich auch auslöten solange deine Versorgungsspannung 3.3V nicht überschreitet (die brauchen nämlich auch Strom).
Es gibt auch noch eine RTC 'Version' mit der der Ruhestrom weiter reduziert werden kann. Dafür braucht man aber einen Uhrenquartz noch in der Schaltung.
Andreas
Hmm, habe gerade noch mal meine MAX angeschaut, darunter sind auch welche original von Maxim geliefert. Was mir auffällt ist die Stelle des kleinen +, bei mir und bei den RSOnline ist das zwischen pin 1 & 2, bei den Ali Fakes viel zu weit links außen. Wobei die Ali Fakes auch irgendwie pinkompatible DC/DC Wandler sein müssen (zumindest bei geringen Lasten ist es ja nicht ohne weiteres aufgefallen :o )
Hast du beim Sleeptest den CC1101 dran? dann muss du die auskommentierte powerdown Funktion für diesen im sketch aktivieren)
Zitat von: Tom Major am 27 April 2019, 23:39:38
Hast du beim Sleeptest den CC1101 dran? dann muss du die auskommentierte powerdown Funktion für diesen im sketch aktivieren)
Ahh ok, danke, hab ich auch noch im Code entdeckt. Ich habe etwas rum experimentiert und vor allem mal den CC1101 runter gelötet. Ohne CC1101 sind die Werte plausibel. Was nicht zu passen scheint, ist der Stromverbrauch des CC1101 im PowerDown-Modus. Da liege ich bei ca. 250 uA. Laut Datenblatt und laut deiner Wiki-Seite sollte sich das ja irgendwo im uA-Bereich bewegen. :/
Ich sehe diese 250 uA sowohl im normalen Sensor-Betrieb als auch im SleepTest.ino (mit einkommentiertem cc1101_powerdown).
Hab mal eine Tabelle gemacht mit den Werten, die ich gemessen habe:
https://drive.google.com/open?id=1DbwW_UPtciY2nTFuX4cNa3Am7h8dVkbi_HFQ_nZrzes
Siehst du das auch so, dass der PowerDown-Modus des C1101 nicht passt und hast du evtl. eine Idee? Danke!
Hallo vbs,
nur so als Idee, hast du die Induktivität / Drossel als 400 oder 650 mA Ausführung
bzw. würde das einen Unterschied machen?
MfG
Ich hab den StepUp momentan gar nicht verbaut. Sieht zur Zeit so aus:
https://drive.google.com/open?id=1Pi1pP5d7z3HuolDdcJ2N2fOBOBu-W4DC
EDIT:
Sorry, Link ersetzt...
Meinst du wirklich 250mA :o :o oder 250uA?
Bei 250mA würde ganz massiv was schiefgehen, kein Bauelement in der Schaltung darf diesen Strom ziehen.
Du kannst übrigens auch Leiterbahnen unterbrechen um die Sensoren abzuklemmen, die sind ja nicht so einfach zu löten.
Sorry, ja, meine 250 uA 8)
Die Angaben in der Tabelle sind alle mA. Also 0,25 mA.
Aber der CC1101 sollte doch wenn überhaupt nur wenige uA ziehen, oder? So dass auch 250 uA sind schon ziemlich daneben wären?
Hier nochmal als ASCII. Alle Angaben als mA:
aktiv passiv
SleepTest (CC1101 abgelötet) 4,32 0,005
SleepTest 6,68 2,46
SleepTest cc1101_powerdown 4,41 0,25
HB-UNI-Sensor1.ino 0,25
Ich halte die beiden "0,25" für zu hoch, da ich das im Wiki so verstehe, dass man bei "SleepTest cc1101_powerdown" auch auf ca. 5 uA runter kommen müsste (und mit weiteren Maßnahmen noch tiefer).
Da ich ohne aufgelöteten CC1101 die 5 uA sehe, denke ich, dass der Rest der Schaltung (Sensoren) ok ist und es mit dem CC1101 zusammen hängen muss.
Zitat von: vbs am 28 April 2019, 21:04:58
Hier nochmal als ASCII. Alle Angaben als mA:
aktiv passiv
SleepTest (CC1101 abgelötet) 4,32 0,005
SleepTest 6,68 2,46
SleepTest cc1101_powerdown 4,41 0,25
HB-UNI-Sensor1.ino 0,25
Ich halte die beiden "0,25" für zu hoch, da ich das im Wiki so verstehe, dass man bei "SleepTest cc1101_powerdown" auch auf ca. 5 uA runter kommen müsste (und mit weiteren Maßnahmen noch tiefer).
Da ich ohne aufgelöteten CC1101 die 5 uA sehe, denke ich, dass der Rest der Schaltung (Sensoren) ok ist und es mit dem CC1101 zusammen hängen muss.
Würde ich auch so sehen.
Das SleepTest mit cc1101_powerdown funktioniert sieht man daran das der UniSensor sketch die gleiche Stromaufnahme im sleep hat (nur ist die halt zu hoch). Kann leider aus der Ferne unmöglich sagen woran das liegt. Der Strom ohne CC1101 ist auch plausibel.
Also wäre der CC1101 der nächste Verdächtige.
Ok, erstmal wichtig zu wissen, dass du das auch so siehst. Mein nächster Plan wäre, einmal den CC auszutauschen (hab da aber nicht viel Hoffnung). Danach würde ich eine simple Schaltung mit einem Arduino Pro Mini + CC1101 bauen (wie auf deiner Wiki-Seite) und schauen, ob ich dort zu anderen Ergebnissen komme.
Danke für die Hilfe!
Ein paar neue Erkenntnisse:
- ich hab nochmal neue MAX1724 von Ali (anderer Händler) bekommen (rein interessehalber). Die sehen jedoch genau so aus wie die anderen schlechten und verhalten sich auch genau so falsch. Hab ich direkt entsorgt.
- ich hab den CC1101 getauscht und das hat den hohen Stromverbrauch (fast) gelöst. Lag also tatsächlich an dem CC
Jedoch leider nur fast gelöst:
Im SleepTest mit cc1101_powerdown geht der Strom jetzt sehr weit runter, jedoch schwankt er dann zwischen 1 uA und 22 uA ständig hin und her. Manchmal schwankt es langsam und braucht mehrere Sekunden für ein Intervall und manchmal springt es sehr schnell hin und her. Das Ganze hängt offenbar mit dem StepUp zusammen: wenn ich den MAX1724 entferne und SJ1 schließe, dann messe ich im powerdown konstant ca. 5 uA ohne Schwankungen. Aber sobald der StepUp im Spiel ist, schwankt der Strom. Ist vermutl. nicht normal, oder?
Ich hab schon:
- alle Komponenten (MAX, C8, C9, C10, Spule) ab und wieder drauf gelötet
- die Spule getauscht
- den MAX getauscht
(- den CC nochmal getauscht)
brachte leider keine Veränderung... :(
Hat jemand eine Idee dazu oder ist es am Ende sogar doch normal und eine Eigenschaft der StepUp-Wandlung?
Zitat von: vbs am 02 Mai 2019, 13:25:17
Ein paar neue Erkenntnisse:
- ich hab nochmal neue MAX1724 von Ali (anderer Händler) bekommen (rein interessehalber). Die sehen jedoch genau so aus wie die anderen schlechten und verhalten sich auch genau so falsch. Hab ich direkt entsorgt.
Das mit den MAX1724 Ali fakes ist sehr interessant, eventuell könntest du das kurz in einem eigenen Thread mit den 2 Fotos der guten und schlechten Variante dokumentieren? das Thema wird noch andere Leute treffen und als kurze Info in einem eigenen Thread vielleicht leichter zu finden.
Zu deinen Strommessungen, alles gut jetzt, der MAX arbeitet nicht kontinuierlich, Stichwort " forced discontinuous, current-limited, pulse-frequencymodulation (PFM) control scheme", siehe Datenblatt.
5uA ohne MAX ist gut und wenn du den MAX drin hast kannst du nur mit einem Oszi seriös die schwankende Stromaufnahme messen und daraus einen mittleren Wert berechnen, wie z.B. hier für ein anderes Projekt
https://github.com/TomMajor/SmartHome/tree/master/HB-Dis-EP-42BW#strommessung-und-kalkulation-der-batterielebensdauer (https://github.com/TomMajor/SmartHome/tree/master/HB-Dis-EP-42BW#strommessung-und-kalkulation-der-batterielebensdauer)
Zitat von: Tom Major am 02 Mai 2019, 16:13:12
Das mit den MAX1724 Ali fakes ist sehr interessant, eventuell könntest du das kurz in einem eigenen Thread mit den 2 Fotos der guten und schlechten Variante dokumentieren? das Thema wird noch andere Leute treffen und als kurze Info in einem eigenen Thread vielleicht leichter zu finden.
Klar gern, ist hier zu finden:
https://forum.fhem.de/index.php/topic,100165.0.html
Zitat von: Tom Major am 02 Mai 2019, 16:13:12
Zu deinen Strommessungen, alles gut jetzt, der MAX arbeitet nicht kontinuierlich, Stichwort " forced discontinuous, current-limited, pulse-frequencymodulation (PFM) control scheme", siehe Datenblatt.
Na Gott sei dank :) Ich war schon leicht frustriert. Ich hatte tatsächlich auch schon ins Datenblatt geguckt, um evtl. rauszufinden ob das Verhalten gewollt ist. Aber ich bin da leider nicht hinreichend schlau draus geworden.
Hab jetzt alles soweit am Laufen und damit fast fertig (hab noch die "echte Battriespannugsmessung" in Betrieb genommen)! Ein paar kleine (und hoffentliche letzte Fragen) bitte noch:
- ich hab die Option "Option: 8MHz Quarz statt RC-Osc." verbaut und hatte erst gedacht, dass das das gleiche sei wie wie RTC-Option für noch besseren Ruhestrom. Habe jetzt festgestellt, dass das aber offenbar zwei verschiedene Optionen sind (da man bei RTC ja den internen Quarz benutzen soll). Eine Frage: was ist hier der Vorteil des externen Quarzes? Soweit ich weiß, hat man dadurch einen genaueren Takt, was z.B. für UARTs nützlich ist. Aber hier bei dem Sensor?
Diese RTC-Option klingt ja interessant, das diese ja den Ruhestrom nochmal um mehrere Faktoren reduziert. Ich konnte leider nirgends Informationen finden, wie bzw. mit welchen Bauteilen man die Option baut (hab nur im Quellcode den Schalter gesehen). Oder ist das evtl. gar nicht empfehlenswert für den Normalbetrieb?
- ich wollte eigentlich zwei AA-Akkus verwenden anstelle von AAA, da die einfach länger halten. Meine AA-Batteriehalterung passt jedoch nur mit Gewalt in das 201C-Gehäuse. Ich müsste ein bisschen feilen/dremeln, damit das sauber passt. Macht ihr das auch so? Oder ist aus irgendwelchen Gründer sogar AAA die bessere Wahl?
Mal wieder Dankeschön!
Super Sache dass du das MAX1724 fake Thema im eigenen Thread dokumentiert hast :)
- AA/AAA: Wenn der Platz da ist würde ich immer die größte Kapazität nehmen, sehe außer Platz keinen Grund für AAA. Ich habe als Batt.halter die COMF BH-321-1A von TME, die passen straff ohne Nacharbeiten in das Gehäuse.
https://github.com/TomMajor/SmartHome/tree/master/PCB/Sensor_PLHT#bauelemente (https://github.com/TomMajor/SmartHome/tree/master/PCB/Sensor_PLHT#bauelemente)
Ich muss dazu sagen dass ich mir ein paar AA Batt.halter angeschaut habe und den kürzesten ausgewählt habe ;)
- RTC/Quarz: Wie du schreibst, für UART oder ähnliches ist es manchmal angenehmer eine genauere Betriebsfrequenz zu haben. Nur um ein paar Sensorwerte zu messen reicht der int. RC-Osc.
Der Quarz nur ist eine Option falls man die Platine für andere Anwendungen benutzen möchte.
Die RTC Option wird im AVR Datenblatt beschrieben, bei mir steht dazu nur kurz hier was:
https://github.com/TomMajor/SmartHome/tree/master/Info/Ruhestrom#%C3%BCberpr%C3%BCfung-des-avr-ruhestroms-power-save-mode (https://github.com/TomMajor/SmartHome/tree/master/Info/Ruhestrom#%C3%BCberpr%C3%BCfung-des-avr-ruhestroms-power-save-mode)
ZitatNoch besser bezüglich Ruhestrom wird es schließlich wenn man statt dem Watchdog wake-up ein wake-up über die Timer2/RTC Option mit 32,768kHz Uhrenquarz wählt. Dieser Uhrenquarz wird an den XTAL Pins des AVR angeschlossen, als Haupttaktgeber muss man den internen 8MHz RC-Oszillator über die Fuses einstellen.
Einfach einen Uhrenquarz an die XTAL pins. Und der RC-Osc muss über die Fuses aktiviert werden (bzw. ist default aktiv bei einem neuem chip).
Ok danke, hab ich jetzt etwas eingelesen und begreife langsam. Gut geholfen hat das:
https://www.mikrocontroller.net/articles/Sleep_Mode
Hab mal den "NX3215SA" rausgesucht:
https://www.ndk.com/images/products/catalog/c_NX3215SA-STD-MUA-14_e.pdf
Wäre hoffentlich richtig?
Ich habe diese hier FC-135
https://www.mouser.com/ds/2/137/1699449-465441.pdf
ich nehme zur Zeit diesen
https://de.farnell.com/abracon/ab26t-32-768khz/crystal-32-768khz-12-5pf-cylinder/dp/2467704 (https://de.farnell.com/abracon/ab26t-32-768khz/crystal-32-768khz-12-5pf-cylinder/dp/2467704)
So, nun das Staffelfinale :D
Also ich hab jetzt so einen Uhrenquarz verbaut und erstmal mit dem SleepTestRTC getestet. Da der CC auch drauf sitzt, hab ich die Funktion "cc1101_powerdown" in setup() eingebaut, damit eben der CC dann auch korrekt schlafen gelegt wird. War hoffentlich richtig...
Ich komm nun runter auf 2,0 uA (vorher ohne Quarz 5 uA). Laut Wiki sollte man ja aber auf 0,75 uA runter kommen (https://github.com/TomMajor/SmartHome/tree/master/Info/Ruhestrom). Daher die Frage: Sind meine 2,0 uA erwartungsgemäß oder ist da mal wieder irgendwas faul?
Ist der Grund evtl. dass ich ja einen komplett aufgebauten Sensor teste (jedoch ohne MAX1724) und da eben noch die anderen Bauteile (Sensoren) die Differenz von 1,25 uA ausmachen?
Zitat von: vbs am 08 Mai 2019, 21:32:39
Ich komm nun runter auf 2,0 uA (vorher ohne Quarz 5 uA). Laut Wiki sollte man ja aber auf 0,75 uA runter kommen (https://github.com/TomMajor/SmartHome/tree/master/Info/Ruhestrom). Daher die Frage: Sind meine 2,0 uA erwartungsgemäß oder ist da mal wieder irgendwas faul?
Ist der Grund evtl. dass ich ja einen komplett aufgebauten Sensor teste (jedoch ohne MAX1724) und da eben noch die anderen Bauteile (Sensoren) die Differenz von 1,25 uA ausmachen?
Hast du mal in die Datenblätter deiner Sensoren geschaut was deren Ruhestrom ist, erklärt das die Differenz?
Hm gute Frage, also beim BMP280 ist es recht eindeutig. Der startet im Sleep-Mode und braucht dann 0,1 uA. Beim MAX44009 bin ich nicht ganz sicher. Wenn ich es richtig verstehe, dann braucht er 0,65 uA.
Würde heißen: Ich habe momentan 2,0 uA. Wenn ich 0,1 uA und 0,65 uA abziehe, bin ich bei 1,25 uA. Im Wiki ist von 0,75 uA die Rede. Da bin ich also 0,5 uA drüber. Ich meine aber, dass ich auch ohne den Quarz schon immer 0,5 uA drüber war, da ich IIRC 5,5 uA anstatt 5,0 uA (laut Wiki) hatte. Würde also dazu passen.
Diese 0,5 uA fand ich damals nicht relevant, da es bezogen auf die 5 uA nur 10% drüber war. Bezogen auf die 0,75 uA ist es jetzt natürlich fast eine Verdoppelung. Aber ich glaube, dass ich damit jetzt auch einfach leben kann. Vielleicht liegen solche Schwankungen auch einfach in normalen Toleranzen...
Hi,
ich wollte grade die aktuellste FW kompilieren, Arduino schmeißt aber folgende Fehlermeldung raus
sketch\Sensors/tmBattery.h: In member function 'virtual uint16_t as::tmBatteryResDiv<SENSPIN, ACTIVATIONPIN, FACTOR>::voltage()':
sketch\Sensors/tmBattery.h:177:33: error: 'PIN_A0' was not declared in this scope
ADMUX |= ((m_SensePin - PIN_A0) & 0x0F); // select SensePin as input
^
sketch\Sensors/tmBattery.h: In member function 'virtual uint16_t as::tmBatteryLoad<SENSPIN, ACTIVATIONPIN, FACTOR, LOADTIME>::voltage()':
sketch\Sensors/tmBattery.h:234:33: error: 'PIN_A0' was not declared in this scope
ADMUX |= ((m_SensePin - PIN_A0) & 0x0F); // select SensePin as input
Schuld ist die Datei tmBattery.h und der Fehler kommt nur, wenn man mit der Option BAT_SENSOR tmBatteryLoad kompiliert.
Bei mir steht im Sketch
#define BAT_SENSOR tmBatteryLoad<A0, 7, 4000, 200>
Hast du evtl. falschen Board-Typ gewählt? Sollte Arduino Pro und ATMega328p sein.
[quote author=Kai-Alfonso link=topic=20620.msg938227#msg938227 date=1557400153]
ich wollte grade die aktuellste FW kompilieren, Arduino schmeißt aber folgende Fehlermeldung raus
define BAT_SENSOR tmBatteryLoad<A0, 7, 4000, 200>
[/quote]
Numm mal die "richtige" Pinnummer 14 anstatt dem A0 im Template.
Zitat von: papa am 09 Mai 2019, 13:28:06
Numm mal die "richtige" Pinnummer 14 anstatt dem A0 im Template.
Der Fehler bleibt der selbe - als Board nutze ich bis jetzt (und das hat immer funktioniert) atmega328p_xplained_mini
Kompiliere ich mit (von vbs) vorgeschlagen als Board Arduino Pro mit 328P kommt folgendes:
Arduino: 1.8.9 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328P (3.3V, 8 MHz)"
Build-Optionen wurden verändert, alles wird neu kompiliert
D:\Dropbox\Entwicklung\Arduino\libraries\AskSinPP/Channel.h: In member function 'deletepeer.constprop':
D:\Dropbox\Entwicklung\Arduino\libraries\AskSinPP/Channel.h:157:3: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper.exe: fatal error: D:\Dropbox\Entwicklung\Arduino\hardware\tools\avr/bin/avr-gcc returned 1 exit status
compilation terminated.
d:/dropbox/entwicklung/arduino/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
exit status 1
Fehler beim Kompilieren für das Board Arduino Pro or Pro Mini.
Hatte auch schon mehrmals Probleme mit diesem arm-Crosscompiler :/ Bei mir hat es dann immer irgendwann geklappt nachdem ich die IDE neu gestartet habe und möglichst viel von dem Projekt gecleant habe.
Probier mal ne ältere Arduino IDE Version - z.B. 1.8.1.
Kann den Fehler nicht nachstellen, geht einwandfrei bei mir mit dieser Zeile
#define BAT_SENSOR tmBatteryLoad<A0, 7, 4000, 200>
Sketch uses 23480 bytes (76%) of program storage space. Maximum is 30720 bytes.
Global variables use 1130 bytes (55%) of dynamic memory, leaving 918 bytes for local variables. Maximum is 2048 bytes.
Arduino 1.8.9
Board: Arduino Pro or Pro Mini
ZitatDer Fehler bleibt der selbe - als Board nutze ich bis jetzt (und das hat immer funktioniert) atmega328p_xplained_mini
Übrigens sehe ich gerade dass der Fehler beim 2. Post
nicht identisch zum ersten ist.
Zitatinternal compiler error: Segmentation fault
das hatte ich auch schon mal, dieser interne gcc Fehler geistert seit einigen Jahren durch die Foren.
Was bei
mir dann hilft:
Settings/compiler warnings: alle 4 Optionen einzeln aktivieren und jeweils zu builden versuchen, mit einer der 4 Optionen geht es dann meistens.
Zitat von: Tom Major am 09 Mai 2019, 16:27:03
Übrigens sehe ich gerade dass der Fehler beim 2. Post nicht identisch zum ersten ist.
das hatte ich auch schon mal, dieser interne gcc Fehler geistert seit einigen Jahren durch die Foren.
Was bei mir dann hilft:
Settings/compiler warnings: alle 4 Optionen einzeln aktivieren und jeweils zu builden versuchen, mit einer der 4 Optionen geht es dann meistens.
Ja, ich meinte, ich hatte auch geschrieben, das da ne andere Meldung gibt.
Übrigens - mit 1.8.1 geht es jetzt. :o
Zitat von: vbs am 09 Mai 2019, 09:25:02
Diese 0,5 uA fand ich damals nicht relevant, da es bezogen auf die 5 uA nur 10% drüber war. Bezogen auf die 0,75 uA ist es jetzt natürlich fast eine Verdoppelung. Aber ich glaube, dass ich damit jetzt auch einfach leben kann. Vielleicht liegen solche Schwankungen auch einfach in normalen Toleranzen...
Sehe ich auch so, würde es dabei belassen. Toleranzen im Messgerät, beim Chip usw. 1,25uA ist ein sehr guter Wert. Außerdem ist in diesem uA Bereich wo du jetzt angekommen bist der Einfluss auf die Batt.lebensdauer gering da es ja noch das Senden gibt.
Zitat von: Kai-Alfonso am 09 Mai 2019, 16:28:09
Ja, ich meinte, ich hatte auch geschrieben, das da ne andere Meldung gibt.
Übrigens - mit 1.8.1 geht es jetzt. :o
Probier es mal wie gesagt bei 1.8.9 mit den compiler warnings Optionen wie oben geschrieben falls du nicht dauerhaft mit 1.8.1 leben willst ;)
Wie lang macht ihr eigentlich eine Drahtantenne bei der Sensor_PLHT Platine? Zählt das Stück Leiterbahn mit zur Antenne?
asksinpp.de sagt:
TIP
Anstatt der mitgelieferten Spiralantenne empfiehlt sich ein Draht mit 8,3cm Länge.
Dieser sollte nach Möglichkeit mit Abstand zu den elektronischen Bauteilen verlegt werden.
https://asksinpp.de/Grundlagen/01_hardware.html#funkmodul
Gute Frage mit der Leiterbahn... Wenn ich raten müsste, würde ich sagen, dass die dazu zählt.
Zitat von: vbs am 17 Mai 2019, 21:39:53
asksinpp.de sagt:
TIP
Anstatt der mitgelieferten Spiralantenne empfiehlt sich ein Draht mit 8,3cm Länge.
Dieser sollte nach Möglichkeit mit Abstand zu den elektronischen Bauteilen verlegt werden.
https://asksinpp.de/Grundlagen/01_hardware.html#funkmodul
Gute Frage mit der Leiterbahn... Wenn ich raten müsste, würde ich sagen, dass die dazu zählt.
Okay zumindest mit 83mm Draht sind die RSSI Werte jetzt nicht komplett daneben (-49dBm).
Hm, hab festgestellt, dass der BME280 im Gehäuse bei mir auf dem Balkon die Temperatur saftig zu hoch meldet. Werden so 2-3 °C sein.
Hab mal etwas gegoogelt und ich bin offenbar nicht der einzige mit dem Problem:
https://www.mikrocontroller.net/topic/445474
Ein paar Theorien:
- der Sensor ist nicht gedacht, um die Umgebungstemperatur zu messen (er misst halt eher die Boardtemperatur?)
- bei häufigen Messungen (> 1 Hz) erwärmt er sich und verfälscht die Werte
- der Spannungswandler erwärmt das Board und führt zu zu hoch gemessenen Temperaturen
- das geschlossene Gehäuse führt zu erhöhten Werten (wenn ich den Deckel aufwache, wird es auch sofort etwas besser)
Wie macht ihr das bei euch? Ich hab den Sensor momentan direkt (ohne Breakout-Board) auf die Platine gelötet. Überlege jetzt, den runter zu löten und als Break-Out-Variante per Kabel aus dem Gehäuse raus zu legen (hatte ich damals beim SHT10 beim Dirk-Sensor auch gemacht).
Gibt's noch andere Ideen? Ich fürchte, mit dem Sensor direkt auf dem Board wird man nicht glücklich, oder?
Ich habe solche Sensoren schon thermisch entkoppelt gesehen (so gut es halt geht).
Da ist dann rings um den Sensor herum in die Platine ein Schlitz gefräst, nur an einer
dünnen Stelle ist die Sensor"insel" mit der restlichen Platine verbunden. Da laufen dann
auch die Anschlüsse zum Sensor drüber.
Martin
Ich denke auch das die thermische Trägheit und die gute thermische Anbindung des BME an das Board dafür verantwortlich sind.
Ich habe demnächst vor, bei meinem Außensensor noch einen DS18x20 draufzulöten (der etwas Abstand vom Board hat) und die 2. Temperatur in die custom payload zu verpacken und dann mal zu vergleichen..
Bei meinen Sensoren hatte ich im Testbetrieb festgestellt, daß die Betriebsart des Atmega 328 Chips (ca. 2-3 cm entfernt vom DS18B20, dieser nicht thermisch entkoppelt wie oben beschrieben) erheblichen Einfluß auf das Meßergebnis hatte.
Der Betrieb des Atmega im Normalmodus (Chip ständig aktiv) erhöhte die Meßtemperatur um ca. 2-3 Grad. Erst als der Controller in den Sleep-Modus versetzt wurde und nur kurz alle 8 Sekunden für die Messung aufwachte, hat der DS18B20 die Temperatur richtig gemessen. Erkennbar war dies durch einen entsprechenden Temperaturanstieg direkt nach Inbetriebnahme des Sensors.
Also ich hab jetzt den Sensor gegen eine Breakout-Board-Variante getauscht und aus dem Gehäuse herausgelegt (ja sieht schrecklich aus. Evtl. hat jemand eine Idee, wie man das schicker machen kann? :D). Das Problem ist etwas besser geworden, aber die Temperatur ist immer noch systematisch zu hoch (bis ca. 1°C).
Ich hab mal einen Test gemacht und drei THGR228N parallel laufen lassen und geplottet. Grün ist der BME, die anderen drei sind die THGR228Ns. Diese Nacht bei 12°C lagen alle vier Sensoren ganz gut beeinander (bzw. der BMW sogar systematisch drunter :o). Aber sobald dann die Temperatur steigt, setzt sich der BME ziemlich ab (knapp 1°C).
Also eigentlich sind mMn durch das Herauslegen des Sensors alle Nebeneffekte ausgeschlossen. Daher keine Idee, wie das noch zu erklären ist. Natürlich können theoretisch auch die THGR228N systematisch zu niedrig messen. Oder sind solche Abweichungen zwischen Sensor-Familien normal?
Achso: lila und rot hatten zwischenzeitlich Sendeprobleme...
1°C Abweichung klingt doch schon mal besser als vorher, damit hast du den Einfluss des Gehäuses eliminiert.
Und für den Rest
Ja, hab auch die Toleranzen gesehen, aber hätte gehofft, dass das:
- eher worst-case Abweichungen sind und man in der Praxis deutlich näher dran liegt
- die THGRs ja auch Toleranzen haben und daher auch untereinander mehr abweichen sollten
Auffällig finde ich, dass alle 3 THGRs so nahe beieinander liegen und nur der BME so stark abweicht (bei höheren Temperaturen auch nur).
Aber: ich habe nochmal ein Homematic-Thermostat daneben gelegt (HM-TC-IT-WM-W-EU). Und interessanterweise liegt der immer sehr nahe beim BME (siehe Anhang). Man könnte also denken, dass die THGRs tatsächlich tendenziell eher zu niedrig messen (anstatt der BME zu hoch) :o.
Naja, wie dem auch sei. Ich denke, dass das alles funktioniert und offenbar messen verschiedene Sensoren einfach verschiedene Temperaturen. Für mich etwas überraschend, da ich irgendwie naiv gedacht habe, dass das Thema Temperaturmessung so gut "verstanden" ist, dass das jeder Sensor recht genau mitbekommen müsste. Hätte nicht gedacht, dass es da offenbar unterschiedliche Meinungen bei der Temperatur gibt :)
Für mich sieht das nach normalen Toleranzen der Sensoren aus. Wenn BME +- 1C angibt darfst du imho nicht mehr erwarten.
Könnte sein dass die THGRs werkseitig kalibriert sind und deshalb so nahe beieinander liegen.
Wenn du es genauer brauchst könntest du dir ein entsprechend genaues Referenzthermometer besorgen, z.B. max. Fehler +- 0,1C, und den UniSensor damit kalibrieren, entweder direkt im sketch pro Sensor (vor der Übertragung) oder in FHEM (nach der Übertragung).
Dass Homematic und der BME so dicht zusammen liegen, macht ja theoretisch auch Mut. Jedoch ist jetzt nicht klar, welche von den beiden "Parteien" recht hat. ;D
Brauchen tu ich es nicht, aber hätte schon Lust das noch weiter zu optimieren. Hängt so ein bisschen davon ab, ob man so ein genaues Thermometer zu einem vertretbaren Preis beschaffen kann. So bis 50€ würde ich dafür mal investieren. Ich hab gerade mal quer gegoogelt und alles, was ich gefunden habe, war dann auch schnell dreistellig.
Vielleicht hat ja jemand noch eine andere (DIY)-Idee, wie man das kostengünstig aber präzise messen kann...
Zitat von: vbs am 26 Mai 2019, 14:36:05
Dass Homematic und der BME so dicht zusammen liegen, macht ja theoretisch auch Mut. Jedoch ist jetzt nicht klar, welche von den beiden "Parteien" recht hat. ;D
Brauchen tu ich es nicht, aber hätte schon Lust das noch weiter zu optimieren. Hängt so ein bisschen davon ab, ob man so ein genaues Thermometer zu einem vertretbaren Preis beschaffen kann. So bis 50€ würde ich dafür mal investieren. Ich hab gerade mal quer gegoogelt und alles, was ich gefunden habe, war dann auch schnell dreistellig.
Vielleicht hat ja jemand noch eine andere (DIY)-Idee, wie man das kostengünstig aber präzise messen kann...
Eiswasser mit Eiswürfeln. Solange das Eis nicht aufgetaut ist sollte das Gemisch bei ziemlich exakt 0 °C bleiben.
Oder Fieberthermometer.
siehe auch
https://www.schramm-software.de/bausatz/digitalthermometer/kalibrierung.htm (https://www.schramm-software.de/bausatz/digitalthermometer/kalibrierung.htm)
und kochendes Wasser hat 100 Grade ... mit ein wenig suchen findet man bestimmt auch weitere "Konstanten" im eigenen Haushalt
Zitat von: Wuppi68 am 26 Mai 2019, 23:06:27
und kochendes Wasser hat 100 Grade ... mit ein wenig suchen findet man bestimmt auch weitere "Konstanten" im eigenen Haushalt
keine gute Konstante, ist abhängig von Luftdruck und Höhe, Eiswasser ist da besser.
Ich fürchte, dass ein einzelner Kalibrationspunkt nicht ausreichend sein wird. Mindestens zwei sollten es wohl sein. Im Moment sehe ich, dass sich alle 5 Sensoren bei ca. 10 °C recht einig sind. Auf dem Weg zu ca. 17 °C driften sie dann auseinander.
Hallo Leute, ich brauche dringend eure Hilfe denn ich bin mit meinem Latein völlig am Ende. Ich habe den HB-UNI-SEN-BATT nachgebaut, bekomme ihm aber nicht an die Zentrale angemeldet. Nachdem der Button kurz gedrückt wird Passiert in Fhem rein gar nichts.
Dabei bin ich wie folgt vorgegangen:
- Schaltung auf diese Platine aufgebaut https://github.com/alexreinert/PCB#hb-uni-sen-batt (https://github.com/alexreinert/PCB#hb-uni-sen-batt)
- Fusebits nach der Anleitung "Dauersender / Babbling Idiot" gesetzt
- die Firmware von hier https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1) den Standardwerten inkl. Seriennummer und ID (ich habe nur einen Sensor bis jetzt) aufgespielt.
- die HMConfig_UniSensor1.pm in Fhem eingefügt (wird laut Log auch geladen)
- der Sensor scheint zu funktionieren und sendet über die Serielle Schnittstelle auch Werte.
- Wenn ich den Button am Sensor drücke blinkt die LED für 10-15Sek.
- Die VCCU in Fhem ist dabei in Paarungsmodus (set hmPairForSec 300)
- In fhem benutze ich einen Selbstbau-Cul der bereits mit andere HM Geräte einwandfrei funktioniert
- auch einen zweiten Funkmodul eingelötet ohne Ergebnis
- Mit dem Oszilloskop kann man sehen, dass nachdem die Taste gedrückt wurde sowohl auf MISO als auf MOSI Datenverkehr ist. Ich kann die Daten dekodieren, weiß aber nicht ob sie Sinn ergeben
Hi,
könnten fehlerhafte CC1101-Module sein, s. auch https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html (https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html).
Du bist aber in diesem Thread ziemlich OT.
Wäre auch meine erste Vermutung, gerade wenn die LED beim Taste drücken einfach nur 15 Sek. blinkt.
Im seriellen Log sieht man ob die Zentrale antwortet.
So genau kann nicht sagen ob es fake Module sind, allerdings sieht der CC1101 nicht ganz wie erwartet (abgeschrägte Ecken statt richtig eckig). Ich habe paar Bilder davon angehängt.
Ein Anlernversuch sieht so aus:
AskSin++ V4.1.0 (Jun 2 2019 17:06:17)
BME280 found
Sensor setup done
Serial: UNISENS001
Clock SYSCLOCK
Address Space: 32 - 79
CC init1
CC Version: 04
- ready
tmBattery Voltage: 3392
Battery set low: 21
Battery set crit: 19
Config Changed: List0
ledMode: 1
lowBatLimit: 21
Battery set low: 21
transmitDevTryMax: 6
updCycle: 600
altitude: 0
BME280 Temperature x10 : 253
BME280 Pressure x10 : 10038
BME280 PressureNN x10 : 10038
BME280 Humidity : 58
<- 17 01 84 70 A5A501 000000 00 FD 27 36 3A 00 86 47 00 00 0D 40 00 00 - 188
debounce
pressed
released
<- 1A 02 84 00 A5A501 000000 13 F1 03 55 4E 49 53 45 4E 53 30 30 31 70 01 01 01 - 247
debounce
released
<- 1A 03 84 00 A5A501 000000 13 F1 03 55 4E 49 53 45 4E 53 30 30 31 70 01 01 01 - 593
Der Quarz sieht komisch aus. Da wird mit hoher Wahrscheinlichkeit die Frequenz nicht stimmen. Bitte mal den Anweisungen hier folgen: https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html
Danke. Werde mich mal da durchlesen. Der CC1101 ist definitiv nicht von Texas Instruments (das TI fehlt, andere Gehäuseform). Scheint einen Nachbau oder so zu sein. Werde schon mal versuchen mir das Geld über Aliexpress zu holen. Was das wieder an Nerven kostet... Und neue Module die erst in 4 Wochen kommen, muss ich auch noch bestellen. Was ein Mist :-\
Tipps fürs nächste mal. Ich teste solche Module mitlerweile immer gesockelt mit einem Testboard, bevor ich sie fest verlöte.
Zitat von: gloob am 04 Juni 2019, 08:35:25
Tipps fürs nächste mal. Ich teste solche Module mitlerweile immer gesockelt mit einem Testboard, bevor ich sie fest verlöte.
Das klingt nach einer guten Idee, die Beiträge mit den fakes häufen sich. Hast du mal ein Foto von deinem CC1101 Sockel?
Zitat von: Tom Major am 04 Juni 2019, 11:51:45
Das klingt nach einer guten Idee, die Beiträge mit den fakes häufen sich. Hast du mal ein Foto von deinem CC1101 Sockel?
Ich habe einen nanoCUL v1.x, bei dem ich das Radio mit Stiftleisten gesockelt habe. Damit könnte das funktionieren - ich probier's mal und berichte.
Gruß Peter
Weitere Diskussionen zum testen der Module im Nachbarthread: https://forum.fhem.de/index.php/topic,91740.msg946071.html#msg946071
Verschiebe das doch bitte mal nach https://forum.fhem.de/index.php/topic,91740.msg937315.html#msg937315
Dann kann man es auch wieder auffinden.
Hallo,
ich wollte noch Universalsensoren mit Anbindung an einen HomeMatic CUL bauen.
Diese sollen dann Temperatur, Luftfeuchte, Luftdruck und Helligkeit messen.
Wo kann ich Platinen (z.B. HB-UNI-Sensor1) beziehen?
Gruß
Hubert
ich habe meine bei CatWeazle https://forum.fhem.de/index.php/topic,98150.0.html (https://forum.fhem.de/index.php/topic,98150.0.html) bestellt. Je nach dem wie viele Stück brauchst, kann sich lohnen selber in China zu bestellen zb hier https://www.seeedstudio.com/fusion_pcb.html (https://www.seeedstudio.com/fusion_pcb.html) 10Stk. 5$+11$ Versand.
Nach meinem Ärger mit dem Funkmodulen würde auch Alternativen in betracht ziehen zb die Xiaomi Aqara Sensoren (Zigbee) für ~10$ /Stk.
Hallo Hubert,
Zitat von: hubi3922 am 05 Juni 2019, 19:53:29
ich wollte noch Universalsensoren mit Anbindung an einen HomeMatic CUL bauen.
Diese sollen dann Temperatur, Luftfeuchte, Luftdruck und Helligkeit messen.
ich habe noch Platinen von der Version 1.5 da, die ist hier (https://forum.fhem.de/index.php/topic,20620.msg816223/topicseen.html#msg816223) kurz beschrieben (Schaltplan (https://github.com/pemue-git/pcb/blob/master/homematic/Aussensensor_v1.5_sch.pdf) bzw. Bilder sind auf Github). Bei Interesse schick mir gerne eine PM.
Gruß Peter
Hallo Phantomato, PeMue,
vielen Dank für die rasche Antwort.
Damit ist mir schon weitergeholfen.
Gruß Hubert
Zitat von: hubi3922 am 05 Juni 2019, 19:53:29
Hallo,
ich wollte noch Universalsensoren mit Anbindung an einen HomeMatic CUL bauen.
Diese sollen dann Temperatur, Luftfeuchte, Luftdruck und Helligkeit messen.
Wo kann ich Platinen (z.B. HB-UNI-Sensor1) beziehen?
Gruß
Hubert
Ich habe gute Erfahrungen mit jlcpcb gemacht.
Qualität passt, Preis ist gut und es dauert etwa 2,5 Wochen, das meiste davon der Versandweg.
https://jlcpcb.com/
Ich hab mal ein "Kaiser Präzisions-Thermometer 4086" bestellt... gute alte analoge Ware. Angeblich Genauigkeit von 0,2 °C. Würde ich dann mal als Referenz nehmen und eine Kennlinie mit ein paar Stützstellen in die FW einbauen. Bin gespannt...
Ich hab mal eine andere Frage: ich habe jetzt einen Olivenbaum im Garten (jaja, angeblich winterhart) und der darf nicht zu viel Wasser haben. Da ich aber keinen grünen Daumen habe, will ich das gerne mit Technik lösen. Die Erde muss auch unterhalb der oberen Schicht durchgetrocknet sein. Die meisten nehmen dann so ein Einsteck-Bodenfeuchtesensor von Amazon. Da muss ich aber immer hinlaufen und schauen. Das wäre gar nicht fhem-like 8) 8)
Hat jemand schon sowas mit dem Universalsensor gebaut?
Wegen der Homematic-Reichweite mach ich mir keine Sorgen. Zur Not packe ich noch ein Homematic WLAN Gateway in die Nähe
Schau mal hier https://github.com/jp112sdl/HB-UNI-Sen-CAP-MOIST
Muss aber noch ins FHEM-Addin rein
Zitat von: papa am 17 Juni 2019, 20:30:02
Schau mal hier https://github.com/jp112sdl/HB-UNI-Sen-CAP-MOIST
Muss aber noch ins FHEM-Addin rein
Hallo papa,
vielen Dank für den Link - sieht interessant aus. Werde ich mir mal zu Gemüte führen
Hallo die Runde
Ich kämpfe hier gerade mit einem Problem 'rum und wollte mal um Rat fragen.
Habe eine Sensorplatine Dirk/PeMue/TomMajor v2.01 mit Bauteilen bestückt. Als Letztes hatte ich den Atmega aufgelötet. Allerdings läßt sich der Bootloader nicht flashen. Das Teil bringt mir schon beim Lesen und Verifizieren dauernd Fehler. Der Atmega ist vom Ali, aus einer Serie, mit der ich schon solche Platinen ohne Probleme gelötet, geflasht und in Betrieb genommen habe. Wenn ich wiederholt die Fuses auslese, kommen auch immer wieder mal Fehler, z.T. meckert avrdude schon beim Auslesen der Kennung. Kann es sein, daß manche Exemplare Probleme mit dem Takt haben? Müßte man die dann besser schon vor dem Auflöten dahingehend testen? Wie sind denn Eure Erfahrungen so?
Ein vor längerer Zeit komplett bestückter Sensor (Dirk-Platine) läßt sich ohne diese Problem auslesen und verifizieren. Der Programmer ist also nicht das Problem.
Viele Grüße
G.
Hi,
Auf welcher Plattform (Windows/Linux) nutzt Du avrdude? Und welche USB UART (FTDI, PL2302, CH340) setzt Du ein? Meine Vermutung wäre unter Windows zu neue FTDI Treiber, die einen Fake Chip erkennen und Datenschrott in die Kommunikation einbauen.
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Zitat von: RaspiLED am 21 Juni 2019, 23:18:21
Auf welcher Plattform (Windows/Linux) nutzt Du avrdude? Und welche USB UART (FTDI, PL2302, CH340) setzt Du ein? Meine Vermutung wäre unter Windows zu neue FTDI Treiber, die einen Fake Chip erkennen und Datenschrott in die Kommunikation einbauen.
Hallo Arnd
Das schließe ich mal aus. Das Verhalten ist dasselbe unter Windows und Linux (Raspi). Wie gesagt, eine andere selbstgebaute Platine zeigt das Verhalten nicht. Ich hatte diese Probleme bei früheren Selbstbausensoren noch nie, alle mit demselben Setup geflasht und gefust.
Gruß
G.
Ist das mit RC-Oszillator oder ext. Quarz?
Spannungsversorgung beim Flashen ist sauber?
MISO/MOSI/SCK/RST mal visuell prüfen und durchmessen.
Ich flashe nie vorher sondern immer auf dem Board.
Zitat von: Tom Major am 22 Juni 2019, 00:38:02
Ist das mit RC-Oszillator oder ext. Quarz?
Spannungsversorgung beim Flashen ist sauber?
MISO/MOSI/SCK/RST mal visuell prüfen und durchmessen.
Hallo Tom
Ja, hatte alle Verbindungen geprüft und gemessen. Ist mit internem Oszillator. Auch die Pins am CC1101 hatte ich temporär mit 10 k auf VCC gezogen, ohne Verbesserung. - Nach einer langen Nacht habe ich dann noch im Netz den Hinweis gefunden, mal den SPI-Takt zu reduzieren. Mit dem Parameter - B 20 ließ sich der Chip dann flashen und reproduzierbar fehlerfrei verifizieren. Schon seltsam, ist das erste Mal, daß ich so etwas hatte.
Mal sehen, wie sich das Teil weiter schlägt.
Gruß
G.
Hmm, klingt auch für mich seltsam, hatte ich auch noch nie. -B 20 müsste den SPI Takt um Faktor 20 reduzieren wenn ich die Beschreibung richtig deute.
Frage mich halt welchen Takt avrdude default nimmt bzw. eigentlich hängt das ja vom Programmer ab, beim nächsten Mal würde ich wahrscheinlich die SPI clock mal nachmessen.
Fuse CLKDIV8 ist auch eine Sache die in dem Zusammenhang nicht ganz unwesentlich ist.
Zitat von: Tom Major am 22 Juni 2019, 16:43:49
Fuse CLKDIV8 ist auch eine Sache die in dem Zusammenhang nicht ganz unwesentlich ist.
Im Rohzustand ist ja das Bit gesetzt, d.h. ein hoher SPI-Takt sollte eigentlich kein Problem sein, oder?
Noch eine andere Frage zum Programmieren: Wenn ich einen Unisensor1-Sketch Arduino-IDE seriell aufgespielt habe und ich danach einen neuen Sketch laden möchte, findet der FTDI keine Synchronisierung. Ich muß dann erst den Bootloader wieder neu flashen, dann geht es wieder zu laden. Ist das normal oder übersehe ich hier etwas?
Gruß
G.
Hallo Gernott,
Zitat von: Gernott am 22 Juni 2019, 19:16:00
Noch eine andere Frage zum Programmieren: Wenn ich einen Unisensor1-Sketch Arduino-IDE seriell aufgespielt habe und ich danach einen neuen Sketch laden möchte, findet der FTDI keine Synchronisierung.
im Prinzip ist der Universalsensor wie ein Arduino pro mini. Dieser muss kurz vor dem Flash Vorgang resettet (https://draeger-it.blog/arduino-minipro-anschliessen-programmieren/) werden, damit das Flashen funktioniert, sprich es gibt nur ein relativ kleines Zeitfenster zum Flashen nach dem Reset. Ich programmiere aber immer per ISP und danach OTA, von daher kann ich mich auch täuschen ...
Gruß Peter
Zitat von: PeMue am 22 Juni 2019, 19:33:25
Dieser muss kurz vor dem Flash Vorgang resettet (https://draeger-it.blog/arduino-minipro-anschliessen-programmieren/) werden, damit das Flashen funktioniert...
Hallo Peter,
ja, das kenne ich beim Pro Mini. Allerdings gibt es bei der Eigenbauplatine keinen RESET-Knopf. Ich ging davon aus, das macht das DTR-Signal vom FTDI mit der RESET-Leitung am AVR automatisch. Wenn das Kompilieren fertig ist, blinkert auch kurz die LED ein paar Mal, so daß wohl ein RESET stattfindet und der Bootloader startet. Womöglich stimmt aber das Timing nicht? Ich habe allerdings bei avrdude nichts gefunden, was eine Wartezeit nach dem Reset einstellen kann.
Ist der Unisensor1 auch OTA programmierbar? Bisher hatte ich das nur bei Dirks Firmware so gemacht. - Habe es gerade gefunden. Es braucht einen speziellen OTA-Bootloader.
Gruß
G.
Wenn du C1 bestückt hast sorgt DTR für ein Reset am AVR, das geht automatisch, Arduino Standard Verhalten, kein Reset Knopf drücken nötig.
Wenn es nicht geht wurde entweder der bootloader überschrieben (sketch flash size > (32k - bootloader size) ?) oder etwas stimmt mit dem Takt beim AVR nicht.
Ich setzte normalerweise die Fuse BLB1, das schützt den bootloader vor dem (seriellen) Überschreiben.
https://github.com/TomMajor/SmartHome/tree/master/Info/Bootloader#standard-bootloader-atmega328p-rc-oszillator-oder-quarz-8mhz (https://github.com/TomMajor/SmartHome/tree/master/Info/Bootloader#standard-bootloader-atmega328p-rc-oszillator-oder-quarz-8mhz)
2. Bild
Kannst du im seriellen Monitor die Debugausgaben lesen? Dann stimmt der Takt einigermaßen denke ich.
Ob der bootloader überschrieben wurde könntest du durch ein Verify über ISP checken.
Zitat von: Tom Major am 22 Juni 2019, 23:46:07
Wenn es nicht geht wurde entweder der bootloader überschrieben....
Hallo Tom
Du hast Recht, der Bootloader war weg. Ich hatte mir den Flash runtergeladen und Bytefolgen aus dem Bootloader gesucht und nicht gefunden. Die Fusebits waren auch verstellt. Die habe ich neu gesetzt und dann den Bootloader neu geschrieben. Danach waren die Fuses wieder verstellt. Das hatte ich bisher nicht bemerkt. Nachdem ich die Fuses wieder richtig gesetzt hatte, ging dann auch das wiederholte Hochladen des Skteches.
Komischerweise hat das avrdude -verify nicht gemeckert. Komisch ist, daß da nach dem Lesen immer 0.00 s steht. Vergleicht der evtl. nur die Dateigröße:
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: verifying flash memory against D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex:
avrdude.exe: load data flash data from input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex:
avrdude.exe: input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex auto detected as Intel Hex
avrdude.exe: input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex contains 32652 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 0.00s
avrdude.exe: verifying ...
avrdude.exe: 32652 bytes of flash verified
avrdude.exe done. Thank you.
Vielen Dank für die helfenden Worte und Deine tollen Projekte!
Gruß
G.
Gleich noch eine Frage hinterher, zum PIR AM312
In der Modifikation von fhemfreund, ist dort der Spannungsregler ausgelötet oder bleibt der drin?
Mir ist auf https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1
in der Schaltung und den Bildern nicht so klar, ob Transistor direkt an den Sensor kommt oder an die Pins des Moduls.
Gruß
G.
Zitat von: Gernott am 23 Juni 2019, 11:44:07
Hallo Tom
Du hast Recht, der Bootloader war weg. Ich hatte mir den Flash runtergeladen und Bytefolgen aus dem Bootloader gesucht und nicht gefunden. Die Fusebits waren auch verstellt. Die habe ich neu gesetzt und dann den Bootloader neu geschrieben. Danach waren die Fuses wieder verstellt. Das hatte ich bisher nicht bemerkt. Nachdem ich die Fuses wieder richtig gesetzt hatte, ging dann auch das wiederholte Hochladen des Skteches.
Komischerweise hat das avrdude -verify nicht gemeckert. Komisch ist, daß da nach dem Lesen immer 0.00 s steht. Vergleicht der evtl. nur die Dateigröße:
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: verifying flash memory against D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex:
avrdude.exe: load data flash data from input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex:
avrdude.exe: input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex auto detected as Intel Hex
avrdude.exe: input file D:\Technik\Homematic\Bootloader\ATmegaBOOT_168_atmega328_pro_8MHz.hex contains 32652 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 0.00s
avrdude.exe: verifying ...
avrdude.exe: 32652 bytes of flash verified
avrdude.exe done. Thank you.
Vielen Dank für die helfenden Worte und Deine tollen Projekte!
Gruß
G.
Gerne.
Bei deinem verify sieht man das avrdude command nicht, aber 32652 bytes finde ich komisch, der bootloader hat normal 2KB, start adress 0x7800
https://github.com/TomMajor/SmartHome/blob/master/Info/Bootloader/mega328_RC-Osc_or_Quarz/ATmegaBOOT_168_atmega328_pro_8MHz.hex (https://github.com/TomMajor/SmartHome/blob/master/Info/Bootloader/mega328_RC-Osc_or_Quarz/ATmegaBOOT_168_atmega328_pro_8MHz.hex)
Verify bedeutet echtes zurücklesen, beim bootlader halt 2048 Bytes.
Eventuell machst du immer ein chip erase?, das löscht auch den bootbereich (allerdings nicht die Fuses).
Zitat von: Gernott am 23 Juni 2019, 12:23:05
Gleich noch eine Frage hinterher, zum PIR AM312
In der Modifikation von fhemfreund, ist dort der Spannungsregler ausgelötet oder bleibt der drin?
Mir ist auf https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1
in der Schaltung und den Bildern nicht so klar, ob Transistor direkt an den Sensor kommt oder an die Pins des Moduls.
Gruß
G.
Ich glaube fhemfreund hat den Spannungsregler nicht ausgelötet sondern der Transistor geht direkt an den Ausgang des PIR Moduls.
Oder ihn noch mal direkt fragen.
Zitat von: Gernott am 23 Juni 2019, 12:23:05
Gleich noch eine Frage hinterher, zum PIR AM312
In der Modifikation von fhemfreund, ist dort der Spannungsregler ausgelötet oder bleibt der drin?
Mir ist auf https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1
in der Schaltung und den Bildern nicht so klar, ob Transistor direkt an den Sensor kommt oder an die Pins des Moduls.
Gruß
G.
Ja der Spannungsregler ist ausgelötet, da er im Standby noch ein paar uA braucht. Da meine Sensoren mit 3V arbeiten, ist dieser sowieso überflüssig.
Habe mal 3 Bilder angehängt, die die Transistorbeschaltung direkt am PIR zeigen.
Übrigens: habe meine beiden Testsensoren jetzt ein paar Monate mit einer CR123 im Betrieb. Bis dato ist noch kein nenenswerter Spannungsabfall bei ca. 134.000 Sendeintervallen und ca. 930 PIR Triggerevents festzustellen.
Andreas
Zitat von: fhemfreund am 23 Juni 2019, 22:49:54
Ja der Spannungsregler ist ausgelötet, da er im Standby noch ein paar uA braucht.
Hallo Andreas
Das hatte ich mir fast gedacht. Danke für die Klarstellung und die Bilder dazu.
Gruß
G.
Nachdem ich gerade Sensoren am Universalsensor teste, habe ich einen mit BME280 auf einem kleinen breakout board vom überheizten Dachgeschoß in den Keller gebracht. Ist das normal, daß der Sensor mehr als 2 Stunden braucht, um auf einen Temperatursprung von -8 K zu regieren?
Zitat von: Gernott am 30 Juni 2019, 23:25:39
Nachdem ich gerade Sensoren am Universalsensor teste, habe ich einen mit BME280 auf einem kleinen breakout board vom überheizten Dachgeschoß in den Keller gebracht. Ist das normal, daß der Sensor mehr als 2 Stunden braucht, um auf einen Temperatursprung von -8 K zu regieren?
Screenshot_2019-06-30.png (http://screenshot_2019-06-30.png)
Das Thema gab es schon ein paar Mal, die Vermutung ist die große thermische Trägheit des Systems BME+Platine+ggf. Gehäuse und weil der BME thermisch so "fest" daran gekoppelt ist.
Könntest mal spaßeshalber einen DS18x20 der in der Luft hängt einbauen/aktivieren und die gleiche Messung mit dem Temperatursprung noch mal machen.
Habe ich irgendwann auch noch vor, meine BME Außentemperatur ist mir auch zu langsam..
Zitat von: Tom Major am 30 Juni 2019, 23:55:50
Könntest mal spaßeshalber einen DS18x20 der in der Luft hängt einbauen/aktivieren und die gleiche Messung mit dem Temperatursprung noch mal machen.
Soviel Spaß muß sein, hier das Ergebnis. Der positive Temperatursprung ist mit 600 s aufgelöst, der negative mit 60 s. Interessant ist der Einfluß der Lage. Links war der BME280-breakout horizontal positioniert, recht vertikal über eine Kante stehend. Dort wir der Sensor offenbar besser angeströmt und reagiert dann deutlich schneller. Der SHT hing ohne breakout dünn verdrahtet im Raum und reagiert ziemlich schnell.
sehr schöne Messung, Danke.
Bestätigt imho die Theorie der großen thermischen Trägheit des BME gegenüber anderen, freistehenden Sensoren.
Werde auf jeden Fall bei meinen Sensoren die Temperatur von einem zusätzlichen DS nehmen wenn möglich, auch wenn ein BME verbaut ist.
Zitat von: Tom Major am 02 Juli 2019, 23:59:05
Werde auf jeden Fall bei meinen Sensoren die Temperatur von einem zusätzlichen DS nehmen wenn möglich, auch wenn ein BME verbaut ist.
Warum eigentlich zusätzlich? Kann der DS den BME nicht einfach ersetzen?
Ich meine ich werde die DS Temperatur nehmen auch wenn ein BME verbaut ist - den ich für Luftdruck und Feuchte brauche - nur die BME Temperatur ignorieren.
Den Luftdruck braucht man ja nur einmal im Sensorzoo, die Feuchte schon öfter. Der SHT(10) scheint die Temperatur auch ziemlich genau zu messen, und läßt sich auf diesem Mini-Breakout auch frei an ein paar Drähte löten. Dafür hat der BME280 lt. Datenblatt nur 0.1 µA im sleep und der SHT 2 µA. Ist aber eher etwas für Stromsparfetischisten. Ich habe hier noch einen SHT31 (0.2 µA sleep) auf einem breakout und werde den nochmal testen, wenn dann meine dilettantische Einbindung in Tom's Unisensor-FW funktioniert.
Hallo Tom & fhemfreund
Ich habe jetzt mal testweise die Variante mit dem PIR+Transistor in Betrieb genommen. Funktioniert auch soweit. Allerdings kommt das Signal im fhem invertiert an, da der PIR-Transistor den Eingang kurz von high auf low schaltet. Der digitalInput zeigt dann im nichtaktivierten Zustand immer "1" an. Wie ließe sich das am besten invertieren?
Vorher hatte ich mich noch kurz gewundert, daß der Sensor nach dem Laden der FW gleich bei leuchtender LED anhielt. Ein zweiter Blick verriet mir dann, daß der voreingestellte digitalInput-Pin A0 auch schon von der Batteriemessung genutzt wird. Auf A1 gestellt und schon ging es wieder.
Gruß
G.
guter Hinweis mit dem Dig.Input, werde den mal default auf A1 setzen.
Ja, der PIR ist nicht aktiv auf 1, du könntest z.B. einen dummy Anwesenheit etc. machen der das mappt oder auch direkt im Perl Skript invertieren und gleich anders nennen, ungefähr an dieser Stelle
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/FHEM/HMConfig_UniSensor1.pm#L90 (https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/FHEM/HMConfig_UniSensor1.pm#L90)
Zitat von: Gernott am 03 Juli 2019, 22:52:00
Hallo Tom & fhemfreund
Ich habe jetzt mal testweise die Variante mit dem PIR+Transistor in Betrieb genommen. Funktioniert auch soweit. Allerdings kommt das Signal im fhem invertiert an, da der PIR-Transistor den Eingang kurz von high auf low schaltet. Der digitalInput zeigt dann im nichtaktivierten Zustand immer "1" an. Wie ließe sich das am besten invertieren?
Vorher hatte ich mich noch kurz gewundert, daß der Sensor nach dem Laden der FW gleich bei leuchtender LED anhielt. Ein zweiter Blick verriet mir dann, daß der voreingestellte digitalInput-Pin A0 auch schon von der Batteriemessung genutzt wird. Auf A1 gestellt und schon ging es wieder.
Gruß
G.
Ja der ist invertiert - wie von Tom schon angemerkt. Das macht aber eigentlich nichts, da man z.B. einen Event von 1 -> 0 problemlos via DOIF auswerten kann. So habe ich es übrigens mit einem Zähler für die PIR Trigger gemacht.
Andreas
Ich bin's schon wieder. Wie läßt sich der digitalInput des Universalsensors mit einem Schaltaktor peeren, so daß ein PIR dort direkt eine Schaltaktion triggern kann? Der Universalsensor hat ja keine separaten Kanäle. Geht das dann überhaupt?
Gruß
G.
Hi,
ich hab mal das Fhem Modul geupdatet und Brighness (mit Max Sensor) ist bei mir auf einmal viel zu niedrig und mit Nachkommastelle?? Im Changelog steht "fix FHEM brightness scaling bug"
Was hat es damit auf sich?
Ab Firmware 1.3 hat die Helligkeit 2 Kommastellen und ist mit Faktor 100 skaliert. Das war eine Idee aus den github issues, bei starker Dunkelheit kann der MAX44009 sehr gut im Bereich kleiner 1 Lux auflösen.
Wenn man den Sensor nicht neu compilieren will kann man das FHEM Modul nutzen was mit fw0x12.pm endet.
Sorry wenn das unklar war, hatte es im Perl Modul vermerkt aber nicht im thread hier.
Zitat von: Tom Major am 18 Juli 2019, 15:11:33
Ab Firmware 1.3 hat die Helligkeit 2 Kommastellen und ist mit Faktor 100 skaliert. Das war eine Idee aus den github issues, bei starker Dunkelheit kann der MAX44009 sehr gut im Bereich kleiner 1 Lux auflösen.
Wenn man den Sensor nicht neu compilieren will kann man das FHEM Modul nutzen was mit fw0x12.pm endet.
Sorry wenn das unklar war, hatte es im Perl Modul vermerkt aber nicht im thread hier.
Ah ok - danke für die Info. Das macht Sinn. Ich denke, ich wer erstmal wieder auf 1.2 zurück gehen, hab grad kein Bock den Sensor abzubauen und neu zu flashen :-)
Hallo,
ich habe mit der Unterstützung von PeMue die HM-UNIVERSAL-SENSOREN1 nachgebaut.
@Peter-vielen Dank nochmal an dieser Stelle
Die Platinen sind bestückt:
- mit dem Sensor MAX44009 an Board
- mit dem Sensor BME280
beide Sensoren sind über I2C angeschlossen
- mit einem Arduino Mini pro.
- und natürlich dem Sender.
Versorgung erfolgt über ein Netzteil mit 3,3V Regulierung.
Ich habe die Sketche von TomMajor und AskSin++ ausprobiert.
Im Dummy-Modus habe ich den Sensor in Fhem eingebunden. Er liefert auch fleissig immer wieder seine vorgegebenen Werte.
Sobald ich jedoch einen Sensor aktiviere, kommt nichts mehr an.
Der serielle Monitor gibt nur ein Zeile mit der Versionsnummer, Datum .. aus.
Wie bekomme ich die Sensoren aktiviert?
Danke.
Nachtrag:
Ich habe jetzt das Board mit dem BME280 abgelötet. Um einen evtl. Fehler auszuschließen.
Aber keine Änderung.
Der serieller Monitor zeigt nur:
"AskSin++ V4.1.0 (Jul 20 2019 19:05:39)"
an. Nichts mehr.
Wo kann ich weitere Fehler suchen?
Gruß
Hubert
Geht den der reale MAX44009 wenn du diesen im sketch aktivierst?
Hast du den master branch oder V4 branch aus der AskSinPP Lib genommen?
Hallo,
ich bin vor längerer Zeit aus diesem Thread ausgestiegen. Jetzt lese ich, dass es Firmware-Versionen 0.2 und 0.3 gibt. Wo bekommt man diese?
Viele Grüße
Frank
Hallo TomMajor,
der MAX44009 liefert auch keine Daten.
Ich habe Dateien von "github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1" benutzt.
Dabei fällt mir jetzt ein, der Sketch konnte die Datei "BME280I2C.h" nicht finden.
Diese habe ich nicht bei TomMajor gefunden, sondern wo anders.
Ich befürchte, hier gibt es Unstimmigkeiten.
Wo finde ich die originale Datei von TomMajor?
Gruß
Hubert
Zitat von: hubi3922 am 22 Juli 2019, 21:22:36
Hallo TomMajor,
der MAX44009 liefert auch keine Daten.
Ich habe Dateien von "github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1" benutzt.
Dabei fällt mir jetzt ein, der Sketch konnte die Datei "BME280I2C.h" nicht finden.
Diese habe ich nicht bei TomMajor gefunden, sondern wo anders.
Ich befürchte, hier gibt es Unstimmigkeiten.
Wo finde ich die originale Datei von TomMajor?
Gruß
Hubert
Wie konntest du den sketch kompilieren und flashen wenn eine Datei fehlte, ist m.E. unmöglich. :o
Der github link stimmt schon.
Die benötigten Libs sind hier beschrieben:
https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#ben%C3%B6tige-libraries (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#ben%C3%B6tige-libraries)
Am besten mal die ganze readme lesen ;)
Zitat von: Bastel-Frank am 22 Juli 2019, 08:48:47
ich bin vor längerer Zeit aus diesem Thread ausgestiegen. Jetzt lese ich, dass es Firmware-Versionen 0.2 und 0.3 gibt. Wo bekommt man diese?
Sorry, ich meinte die Versionen 1.2 und 1.3. Wo kann man diese beziehen?
Und Zusatzfrage: Funktionieren diese Versionen auch mit dem ursprünglichen Sensor von Dirk?
Viele Grüße
Frank
Hallo Tom,
das flashen klappte erst, als ich eine Datei "BME280 I2C" hatte.
Ich versuche heute einen kompletten Neuanfang.Danke für den Link.
Lg Hubert
Hallo Frank,
Zitat von: Bastel-Frank am 23 Juli 2019, 08:17:44
Sorry, ich meinte die Versionen 1.2 und 1.3. Wo kann man diese beziehen?
https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1
Zitat von: Bastel-Frank am 23 Juli 2019, 08:17:44
Und Zusatzfrage: Funktionieren diese Versionen auch mit dem ursprünglichen Sensor von Dirk?
Ja, wenn Du die richtigen Sensoren konfigurierst und einen anderen Bootloader flashst.
Gruß Peter
Zitat von: PeMue am 23 Juli 2019, 18:31:00
Ja, wenn Du die richtigen Sensoren konfigurierst und einen anderen Bootloader flashst.
Wie flasht man den benötigten Bootloader? Welcher Bootloader wird benötigt?
Zitat von: hubi3922 am 23 Juli 2019, 10:58:17
Hallo Tom,
das flashen klappte erst, als ich eine Datei "BME280 I2C" hatte.
Ich versuche heute einen kompletten Neuanfang.Danke für den Link.
Lg Hubert
Hmm, die eine Datei reicht m.E. nicht, du brauchst mindesten 4 Dateien aus der Lib.
Die BME280 Lib ganz normal wie jede andere Arduino Lib installieren.
Zitat von: Bastel-Frank am 23 Juli 2019, 08:17:44
Sorry, ich meinte die Versionen 1.2 und 1.3. Wo kann man diese beziehen?
Und Zusatzfrage: Funktionieren diese Versionen auch mit dem ursprünglichen Sensor von Dirk?
Viele Grüße
Frank
Die Infos hat Peter schon gepostet.
Die Firmware Version ist hier definiert:
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L158 (https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L158)
Zitat von: Bastel-Frank am 23 Juli 2019, 18:32:33
Wie flasht man den benötigten Bootloader? Welcher Bootloader wird benötigt?
Entweder den ganz normalen Ardino Bootloader (Arduino oder Optiboot) und das Device-Model bzw. die HM-ID in den Sektch einkompilieren oder den Bootloader (mit Firmware) selber erstellen mit
https://raw.githubusercontent.com/pa-pa/AskSinPP/master/bootloader/avr/makeota.html
Gruß Peter
Weil es immer wieder Fragen zu den I2C Adressen der Sensoren gab habe ich mal eine Aufstellung der momentan benutzten I2C Adressen für die vom UniSensor unterstützten Sensoren gemacht:
https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#m%C3%B6gliche-i2c-adressen-der-sensoren (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#m%C3%B6gliche-i2c-adressen-der-sensoren)
Könnt ihr mit bitte einen Tipp geben, welches Gehäuse man für Außen nimmt? Gerne auch einen China-Link.
Zitat von: Bastel-Frank am 24 Juli 2019, 21:17:40
Könnt ihr mit bitte einen Tipp geben, welches Gehäuse man für Außen nimmt?
https://github.com/TomMajor/SmartHome/tree/master/PCB/Sensor_PLHT -> Gehäuse
Gruß Peter
Zitat von: PeMue am 25 Juli 2019, 14:15:55
https://github.com/TomMajor/SmartHome/tree/master/PCB/Sensor_PLHT -> Gehäuse
Gruß Peter
Dankeschön :) Ich wusste, dass ich das irgendwo gelesen hatte ... aber nicht mehr gefunden habe.
Noch ne' Frage ;):
Gibt es eine Bestückungsliste evtl. mit Bezugsmöglichkeit der aktuellen Version?
Zitat von: Bastel-Frank am 25 Juli 2019, 14:51:39
Gibt es eine Bestückungsliste evtl. mit Bezugsmöglichkeit der aktuellen Version?
Eine Version davor (v1.5), siehe hier
https://github.com/pemue-git/pcb/blob/master/homematic/Aussensensor_v1.5_bom.xls
Wenn ich wieder zu Hause bin, schaue ich mal nach, wieviele Platinen ich noch habe. Ich werde aber noch eine v1.6 erstellen (mit R und T für den PIR, bzw. Stecker für das BME280/MAX40009
breakout). Ein Update des Innensensors steht auch noch auf der Roadmap, allerdings wird das noch dauern ...
Gruß Peter
Zitat von: PeMue am 25 Juli 2019, 19:45:50
Ich werde aber noch eine v1.6 erstellen (mit R und T für den PIR, bzw. Stecker für das BME280/MAX40009 breakout).
Bei der Platinenbestellung könntest Du vielleicht an mich denken ;-)
Zitat von: PeMue am 25 Juli 2019, 19:45:50
Ein Update des Innensensors steht auch noch auf der Roadmap, allerdings wird das noch dauern ...
Gruß Peter
Ich habe ein neues Design des Innensensors gemacht, stelle ich die nächsten Tage kurz vor.
Nachdem ich im Oktober 2018 ein Redesign für den alten Außen-/Innensensor von Dirk für das GAINTA G201 Gehäuse gemacht hatte:
https://forum.fhem.de/index.php/topic,20620.msg853373.html#msg853373 (https://forum.fhem.de/index.php/topic,20620.msg853373.html#msg853373)
https://github.com/TomMajor/SmartHome/tree/master/PCB/01_Sensor_PLHT_V2.01 (https://github.com/TomMajor/SmartHome/tree/master/PCB/01_Sensor_PLHT_V2.01)
und dazu passend die Firmware/AddOns für HomeMatic und FHEM (HB-UNI-Sensor1)
habe ich jetzt noch mal diesen Sensor für andere Gehäuse (momentan bei mir für Innenanwendungen) neu aufgelegt:
Features
- Bestückung mit ATmega328P, RC-Oszillator als Standard
- Sensoren für Temperatur (DS18x20, BME280), Luftdruck (BME280, BMP180), Luftfeuchte (BME280, SHT10, SHT21), Helligkeit (MAX44009, TSL2561, BH1750), UV-Index (VEML6070, VEML6075) uvm. bestückbar
- 5x I2C Stiftleisten vorhanden, damit können bis zu 5 I2C Sensoren auf Breakout-Boards parallel bestückt werden
- 1-Wire Temperatursensor DS18x20 bestückbar
- Spannungsversorgung: Batterien/Akku 2 AA-Zellen
- Die nicht benutzten Arduino Pins 3, 6, 7, A0 sind auf einem extra Steckverbinder für Erweiterungen herausgeführt (K3)
- Option: Echte Batteriespannungsmessung unter Last (Schutz vor "Babbling Idiot")
- Option: uC-Supervisor MCP111 bestückbar (Schutz vor "Babbling Idiot")
- Option: Miniatur-Quarz 8MHz bestückbar (anstatt int. RC-Osc.)
Gehäusevarianten
- BOX-SENS-WHITE
- 3D Druck, Design by Jan_von_neben_an (Schmelzerboy)
https://www.thingiverse.com/thing:3766944 (https://www.thingiverse.com/thing:3766944)
Gesamte Doku
https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/02_Sensor_PLHT_Vi2.20 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/02_Sensor_PLHT_Vi2.20)
Software
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1)
Schaltung
https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/02_Sensor_PLHT_Vi2.20/Files/HB-UNI-Sensor1_Vi2.20.pdf (https://github.com/TomMajor/AskSinPP_Examples/tree/master/PCB/02_Sensor_PLHT_Vi2.20/Files/HB-UNI-Sensor1_Vi2.20.pdf)
Vielen Dank an Jan für die Zusammenarbeit beim Gehäuse.
Ich habe aus meiner ersten, prototypischen Bestellung je 2 Stück für Jan, papa, Jerome und Marco reserviert.
Bitte keine weiteren Anfragen nach Platinen, die erste Charge ist weg.
Mit den Gerberfiles (checke ich heute oder morgen ein) kann jeder bestellen, ich habe z.B. gute Erfahrungen mit JLCPCB gemacht.
Hallo Tom
Vielen Dank, darauf habe wahrscheinlich nicht nur ich gewartet.
Du hast den step-up weggelassen. Funktioniert der DS18x20 noch, wenn man das mit Akkus betreibt? Laut Datenblatt braucht der 3 V. Mit Akkus liegt man mit 2.4 V dann doch eine Ecke drunter.
Gruß
G.
Hi Tom,
vielen lieben Dank für deine/Eure supertolle Arbeit ;D.
Viele Grüße
Frank
Zitat von: Bastel-Frank am 28 Juli 2019, 15:13:19
Hi Tom,
vielen lieben Dank für deine/Eure supertolle Arbeit ;D.
Viele Grüße
Frank
Gerne :)
Zitat von: Gernott am 28 Juli 2019, 14:22:19
Hallo Tom
Vielen Dank, darauf habe wahrscheinlich nicht nur ich gewartet.
Du hast den step-up weggelassen. Funktioniert der DS18x20 noch, wenn man das mit Akkus betreibt? Laut Datenblatt braucht der 3 V. Mit Akkus liegt man mit 2.4 V dann doch eine Ecke drunter.
Gruß
G.
Ich habe diesmal zuerst die Gehäusevarianten gesucht die ich Innen gern hätte und dann danach die Platine designt. Bei den Gehäusen sind 2 Zellen kein Problem, deswegen habe ich den StepUp weggelassen da ich den bei
der Platine sicher nie brauche, außerdem vergrößert er den Ruhestrom.
Standard für Homematic ist sicherlich Batteriebetrieb mit 3V. Ich habe gute Erfahrungen mit NiMH, bei 2,4V/2,3V z.B. funktionieren meine DS18x20 noch.
Sicherer ist es, mal eine Meßreihe zu machen bis zu welcher Spannung die eigenen DS18x20 korrekt funktionieren oder halt Batterien zu nehmen.
Mal eine andere Frage:
Gibt es schon eine Ausprägung mit einem Hall-Sensor oder Ultraschallsensor, um den Füllstand eines Behälters zu messen?
Viele Grüße
Frank
Ja. Bitte mal die Suche nach Ultraschallsensor benutzen.
Gibt sogar einen eigenen Thread von mir: https://forum.fhem.de/index.php?topic=89857.0
Hallo
Ich habe testweise einen Unisensor von Tom mit einem HM-CC-RT-DN gepeert. Allerdings werden die Temperaturwerte nur gelegentlich vom Thermostaten übernommen. Bei Dirk's Firmware gab es damals nur gelegentliche Aussetzer. Das wurde mit der Version 0.15 gelöst und funktionierte danach bei mir einwandfrei.
Die Unisensor-Firmware wurde mit der CLOCK_RTC-Option kompiliert. Auf dem Board (Aussensensor v2.01) ist ein Quarz 32.768kHz an XTAL angelötet. Intervall der Temperaturmessung ist 300 s.
Gibt es hier schon Erfahrungen mit der Synchronisierung bzw. ist etwas spezielles bei den Einstellungen bzw. Registern zu beachten?
Gruß
G.
Hab ich mich auch schonmal gefragt. Normalerweise wird das Messinterval (und Sendeinterval) ja nach dieser speziellen Homematic-Formel berechnet, damit dann zu dem Zeitpunkt der Peer auch auf Empfang steht. Ist mir nicht klar, wie das gedacht ist, wenn der Sensor einfach hart alle 300 s sendet. Naiv gedacht klappt das so nicht, aber vlt. greifen da noch andere Mechanismen.
vbs war schneller :)
Aber genau so hätte ich es auch geschrieben.
Nach meiner Kenntnis gibt es kein fixes Intervall.
Ist es nicht sogar so, dass bei originalen HM Geräten mit dem erstellen der Direktverknüpfung auch Wake On Radio beim Temperatursensor aktiviert wird, damit das HKT auf sein Verlangen nach dem Ausbleiben der zyklischen Werte sich ein Zwangsupdate holen kann?
Soweit ich weiß vergrößert der Empfänger nach einigen ausgebliebenen Telegrammen sein Empfangsfenster und wenn weiterhin keine empfangen werden, dann geht er irgendwann aus Verzweiflung für eine gewisse Zeit auf Dauerempfang, um sich dann wieder aufsynchronisieren zu können. Natürlich alles zu Lasten der Batterielebensdauer.
Ja so hat es Frank Grass mal erklärt. Mir war aber dennoch so, dass es die WoR Option beim Sender extra dafür auch noch gibt.
Der Delay muss wie hier berechnet werden.
https://github.com/pa-pa/AskSinPP/blob/6796f35eea71e8ed0baf826375d3a554b4a25992/examples/HM-WDS10-TH-O/HM-WDS10-TH-O.ino#L149
Ich muss das mal in die AskSin-Klasse verschieben. Das ist ja eher eine generelle Funktion.
Wenn ich papa's Information richtig verstehe, kann es mit der Unisensor-FW von Tom prinzipiell nicht gehen, da dort ein fixes Messintervall vorgegeben ist?
Gruß
G.
Zitat von: Gernott am 03 August 2019, 14:30:53
Wenn ich papa's Information richtig verstehe, kann es mit der Unisensor-FW von Tom prinzipiell nicht gehen, da dort ein fixes Messintervall vorgegeben ist?
Gruß
G.
ja, wenn das spezielle HM Sendeintervall das Problem ist warum es mit dem Thermostat Peer nicht geht, dann kannst du nur versuchen, an dieser Stelle
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L351 (https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L351)
halt nicht das feste Updateintervall aus List0 zu verwenden sondern die Berechnung aus papas link.
Zitat von: Tom Major am 03 August 2019, 14:51:26
halt nicht das feste Updateintervall aus List0 zu verwenden sondern die Berechnung aus papas link.
Hallo Tom
das wäre dann etwa so?
// reactivate for next measure
HMID id;
device().getDeviceID(id);
uint32_t nextsend = delays(id,msgcnt);
tick = nextsend / 1000; // seconds to wait
millis = nextsend % 1000; // millis to wait
rtc.add(*this);
uint32_t delays (const HMID& id,uint8_t msgcnt) {
uint32_t value = ((uint32_t)id) << 8 | msgcnt;
value = (value * 1103515245 + 12345) >> 16;
value = (value & 0xFF) + 480;
value *= 250;Wenn ich noch millis initialisiere und delay() in delays() umbenenne, läuft zumindest der Compiler durch.
Mangels tiefergehender Programmierkenntnisse überblicke ich nicht, was noch anzupassen wäre...
Update
Habe es jetzt mal testweise etwas laufen lassen. Zumindest scheint eine Synchronisation zustande gekommen zu sein. Hier mal das Serial-Log dazu (Sensor: A5A503, HM-CC-RT-DN: 28BDCE):
AskSin++ V4.1.0 (Aug 3 2019 18:48:14)
SHT31 OK
Sensor setup done
Serial: UNISENS003
Clock RTC
Address Space: 32 - 79
CC init1
CC Version: 14
- ready
tmBattery Voltage: 3128
Battery set low: 21
Battery set crit: 19
Config Freq: 0x21655A
Config Changed: List0
ledMode: 1
lowBatLimit: 12
Battery set low: 12
transmitDevTryMax: 6
updCycle: 240
altitude: 0
<- 17 01 84 70 A5A503 28BDCE 01 09 2A 80 27 00 86 47 00 00 0C 38 00 00 - 315
180.500
<- 17 02 A2 70 A5A503 28BDCE 01 08 2A 80 29 00 86 47 00 00 0C 38 00 00 - 434
-> 10 03 A0 01 1EA24B A5A503 00 04 00 00 00 00 00 - 741
-> 10 03 A0 01 1EA24B A5A503 00 04 00 00 00 00 00 - 937
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 08 2A 80 29 00 86 47 00 00 0C 38 00 00 - 1091
-> 10 03 A0 01 1EA24B A5A503 00 04 00 00 00 00 00 - 1126
-> 14 B9 B2 70 323FDE 35490B 01 00 29 00 00 00 00 0A 7A 0A 28 - 1345
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 08 2A 80 29 00 86 47 00 00 0C 38 00 00 - 1748
-> 14 B9 B2 70 323FDE 35490B 01 00 29 00 00 00 00 0A 7A 0A 28 - 2037
-> 0A B9 80 02 35490B 323FDE 00 - 2162
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 08 2A 80 29 00 86 47 00 00 0C 38 00 00 - 2406
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 08 2A 80 29 00 86 47 00 00 0C 38 00 00 - 3053
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 08 2A 80 29 00 86 47 00 00 0C 38 00 00 - 3700
-> 14 87 A2 70 5FD903 1EA24B 00 00 00 00 00 00 00 08 DD 0B 54 - 3776
-> 0A 87 80 02 1EA24B 5FD903 00 - 3891
waitAck: 00
166.250
<- 17 03 84 70 A5A503 28BDCE 01 0B 2A 80 28 00 86 47 00 00 0C 38 00 00 - 4425
151.750
<- 17 04 84 70 A5A503 28BDCE 01 0A 2A 80 27 00 86 47 00 00 0C 38 00 00 - 4540
137.250
<- 17 05 84 70 A5A503 28BDCE 01 08 2A 80 27 00 86 47 00 00 0C 38 00 00 - 4653
122.750
<- 17 06 84 70 A5A503 28BDCE 01 08 2A 80 28 00 86 47 00 00 0C 38 00 00 - 4765
172.500
<- 17 07 84 70 A5A503 28BDCE 01 07 2A 80 28 00 86 47 00 00 0C 38 00 00 - 4882
158.0
<- 17 08 84 70 A5A503 28BDCE 01 07 2A 80 27 00 86 47 00 00 0C 38 00 00 - 4997
143.500
<- 17 09 84 70 A5A503 28BDCE 01 07 2A 80 27 00 86 47 00 00 0C 38 00 00 - 5111
129.250
<- 17 0A 84 70 A5A503 28BDCE 01 07 2A 80 28 00 86 47 00 00 0C 38 00 00 - 5222
178.750
<- 17 0B 84 70 A5A503 28BDCE 01 07 2A 80 28 00 86 47 00 00 0C 38 00 00 - 5341
164.250
<- 17 0C 84 70 A5A503 28BDCE 01 07 2A 80 28 00 86 47 00 00 0C 38 00 00 - 5457
150.0
<- 17 0D 84 70 A5A503 28BDCE 01 07 2A 80 28 00 86 47 00 00 0C 38 00 00 - 5572
135.500
<- 17 0E 84 70 A5A503 28BDCE 01 06 2A 80 28 00 86 47 00 00 0C 38 00 00 - 5685
121.0
<- 17 0F 84 70 A5A503 28BDCE 01 07 2A 80 28 00 86 47 00 00 0C 38 00 00 - 5795
170.750
<- 17 10 84 70 A5A503 28BDCE 01 06 2A 80 28 00 86 47 00 00 0C 38 00 00 - 5912
156.250
<- 17 11 84 70 A5A503 28BDCE 01 06 2A 80 28 00 86 47 00 00 0C 38 00 00 - 6027
141.750
<- 17 12 84 70 A5A503 28BDCE 01 06 2A 80 28 00 86 47 00 00 0C 38 00 00 - 6141
127.250
<- 17 13 84 70 A5A503 28BDCE 01 05 2A 80 29 00 86 47 00 00 0C 38 00 00 - 6252
177.0
<- 17 14 84 70 A5A503 28BDCE 01 05 2A 80 29 00 86 47 00 00 0C 38 00 00 - 6371
162.500
<- 17 15 84 70 A5A503 28BDCE 01 05 2A 80 29 00 86 47 00 00 0C 38 00 00 - 6488
148.0
<- 17 16 A2 70 A5A503 28BDCE 01 05 2A 80 29 00 86 47 00 00 0C 38 00 00 - 6600
-> 10 17 A0 01 1EA24B A5A503 00 04 00 00 00 00 00 - 7172
waitAck: 00
<- 17 16 A2 70 A5A503 28BDCE 01 05 2A 80 29 00 86 47 00 00 0C 38 00 00 - 7254
-> 10 17 A0 01 1EA24B A5A503 00 04 00 00 00 00 00 - 7288
-> 10 17 A0 01 1EA24B A5A503 00 04 00 00 00 00 00 - 7485
waitAck: 00
<- 17 16 A2 70 A5A503 28BDCE 01 05 2A 80 29 00 86 47 00 00 0C 38 00 00 - 7911
waitAck: 00
<- 17 16 A2 70 A5A503 28BDCE 01 05 2A 80 29 00 86 47 00 00 0C 38 00 00 - 8558
-> 0A 16 80 02 28BDCE A5A503 00 - 8683
waitAck: 01
133.750
<- 17 17 84 70 A5A503 28BDCE 01 04 2A 80 29 00 86 47 00 00 0C 38 00 00 - 9279
183.250
<- 17 18 84 70 A5A503 28BDCE 01 04 2A 80 29 00 86 47 00 00 0C 38 00 00 - 9398
168.750
<- 17 19 84 70 A5A503 28BDCE 01 04 2A 80 2A 00 86 47 00 00 0C 38 00 00 - 9515
154.500
<- 17 1A 84 70 A5A503 28BDCE 01 04 2A 80 2A 00 86 47 00 00 0C 38 00 00 - 9629
140.0
<- 17 1B 84 70 A5A503 28BDCE 01 03 2A 80 2A 00 86 47 00 00 0C 38 00 00 - 9744
125.500
<- 17 1C 84 70 A5A503 28BDCE 01 03 2A 80 2A 00 86 47 00 00 0C 38 00 00 - 9854
175.250
<- 17 1D 84 70 A5A503 28BDCE 01 03 2A 80 2A 00 86 47 00 00 0C 38 00 00 - 9971
160.750
<- 17 1E 84 70 A5A503 28BDCE 01 02 2A 80 2C 00 86 47 00 00 0C 38 00 00 - 10088
146.250
<- 17 1F 84 70 A5A503 28BDCE 01 02 2A 80 2C 00 86 47 00 00 0C 38 00 00 - 10203
131.750
<- 17 20 84 70 A5A503 28BDCE 01 02 2A 80 2C 00 86 47 00 00 0C 38 00 00 - 10315
181.500
<- 17 21 84 70 A5A503 28BDCE 01 01 2A 80 2C 00 86 47 00 00 0C 38 00 00 - 10434
167.0
<- 17 22 84 70 A5A503 28BDCE 01 01 2A 80 2C 00 86 47 00 00 0C 38 00 00 - 10551
152.500
<- 17 23 84 70 A5A503 28BDCE 01 01 2A 80 2D 00 86 47 00 00 0C 38 00 00 - 10665
138.250
<- 17 24 84 70 A5A503 28BDCE 01 01 2A 80 2D 00 86 47 00 00 0C 38 00 00 - 10778
123.750
<- 17 25 84 70 A5A503 28BDCE 01 01 2A 80 2D 00 86 47 00 00 0C 38 00 00 - 10889
173.250
<- 17 26 84 70 A5A503 28BDCE 01 01 2A 80 2D 00 86 47 00 00 0C 38 00 00 - 11008
159.0
<- 17 27 84 70 A5A503 28BDCE 01 00 2A 80 2E 00 86 47 00 00 0C 38 00 00 - 11122
144.500
<- 17 28 84 70 A5A503 28BDCE 01 00 2A 80 2E 00 86 47 00 00 0C 38 00 00 - 11237
130.0
<- 17 29 84 70 A5A503 28BDCE 01 00 2A 80 2E 00 86 47 00 00 0C 38 00 00 - 11347
179.750
<- 17 2A A2 70 A5A503 28BDCE 01 00 2A 80 2E 00 86 47 00 00 0C 38 00 00 - 11466
-> 10 2B A0 01 1EA24B A5A503 00 04 00 00 00 00 00 - 11624
-> 10 2B A0 01 1EA24B A5A503 00 04 00 00 00 00 00 - 11831
-> 10 2B A0 01 1EA24B A5A503 00 04 00 00 00 00 00 - 12027
waitAck: 00
<- 17 2A A2 70 A5A503 28BDCE 01 00 2A 80 2E 00 86 47 00 00 0C 38 00 00 - 12130
waitAck: 00
<- 17 2A A2 70 A5A503 28BDCE 01 00 2A 80 2E 00 86 47 00 00 0C 38 00 00 - 12777
-> 0A 2A 80 02 28BDCE A5A503 00 - 12902
waitAck: 01
165.250
<- 17 2B 84 70 A5A503 28BDCE 00 FF 2A 80 2F 00 86 47 00 00 0C 38 00 00 - 13506
150.750
<- 17 2C 84 70 A5A503 28BDCE 00 FF 2A 80 2F 00 86 47 00 00 0C 38 00 00 - 13621
136.250
<- 17 2D 84 70 A5A503 28BDCE 00 FE 2A 80 2F 00 86 47 00 00 0C 38 00 00 - 13733
122.0
<- 17 2E 84 70 A5A503 28BDCE 00 FE 2A 80 2F 00 86 47 00 00 0C 38 00 00 - 13844
171.500
<- 17 2F 84 70 A5A503 28BDCE 00 FE 2A 80 2F 00 86 47 00 00 0C 38 00 00 - 13961
157.0
<- 17 30 84 70 A5A503 28BDCE 00 FE 2A 80 2F 00 86 47 00 00 0C 38 00 00 - 14075
142.750
<- 17 31 84 70 A5A503 28BDCE 00 FE 2A 80 2F 00 86 47 00 00 0C 38 00 00 - 14190
128.250
<- 17 32 84 70 A5A503 28BDCE 00 FE 2A 80 2F 00 86 47 00 00 0C 38 00 00 - 14303
177.750
<- 17 33 84 70 A5A503 28BDCE 01 01 2A 80 32 00 86 47 00 00 0C 38 00 00 - 14419
163.500
Sieht das einigermaßen sinnvoll aus?
Gruß
G.
Zitat von: Gernott am 03 August 2019, 17:03:37
Hallo Tom
das wäre dann etwa so?
// reactivate for next measure
HMID id;
device().getDeviceID(id);
uint32_t nextsend = delays(id,msgcnt);
tick = nextsend / 1000; // seconds to wait
millis = nextsend % 1000; // millis to wait
rtc.add(*this);
uint32_t delays (const HMID& id,uint8_t msgcnt) {
uint32_t value = ((uint32_t)id) << 8 | msgcnt;
value = (value * 1103515245 + 12345) >> 16;
value = (value & 0xFF) + 480;
value *= 250;
Wenn ich noch millis initialisiere und delay() in delays() umbenenne, läuft zumindest der Compiler durch.
Mangels tiefergehender Programmierkenntnisse überblicke ich nicht, was noch anzupassen wäre...
ich würde nicht rtc.add sondern clock.add machen da beim UniSensor per define am Anfang Sysclock (8MHz Quarz oder RC) oder RTC (32kHz Quarz) gewählt werden kann.
Sonst würde ich sagen probieren ob das mit dem Peer damit besser klappt.
Bei papa bei der Stelle
if( millis != 0 ) {
..
else
weiß ich nicht wozu diese da ist und ob man die hier auch brauchen würde, ich dachte die millis funktionieren sowie so nicht korrekt wenn das device im sleep ist.
Die RTC hat nur einen Sekundentakt. Deshalb müssen die restlichen Millisekunden mit der sysclock gewartet werden.
Es läuft nicht stabil. Es war mit clock.add (..) kompiliert, allerdings ohne den Teil mit den millis aus Tom's hinweis. Werde das mal reinbasteln und nochmal testen.
Die Zeitangaben im Log sind immer Vielfache von 250 ms. Ist das so richtig?
Screenshot_2019-08-04 Home, Sweet Home.png (http://screenshot_2019-08-04%20home,%20sweet%20home.png)
Hast du RTC option aktiv und 32kHZ Quarz verbaut?
Sonst könnte ev. die Ungenauigkeit des RC-Osc. schon für die Instabilitäten verantwortlich sein wenn das magic Homematic Zeitfenster nicht getroffen wird (Vermutung).
Zitat von: Tom Major am 04 August 2019, 11:50:18
Hast du RTC option aktiv und 32kHZ Quarz verbaut?
Ja, habe ich: Auf dem Board (Aussensensor v2.01) ist ein Quarz 32.768kHz an XTAL angelötet.
Mit der zusätzlichen Schleife aus papa's Sketch ist der Sensor erstmal Amok gelaufen und hat im Sekundentakt gesendet. Ursache war offenbar in Zeile 338 vom Unisensor-Setch clock.add(*this) anstelle von CLOCK.add(*this). Oder hat das eine spezielle Bewandtnis? Zumindest läuft er nun nicht mehr Amok.
Gruß
G.
Hallo Tom
Funktioniert die sysclock überhaupt im CLOCK_RTC-Modus?
#ifdef CLOCK_SYSCLOCK
#define CLOCK sysclock
#define SAVEPWR_MODE Sleep<>
#elif defined CLOCK_RTC
#define CLOCK rtc
#define SAVEPWR_MODE SleepRTC
#undef seconds2ticks
#define seconds2ticks(tm) (tm)
#else
#error INVALID CLOCK OPTION
#endif
Also getestet sind damals beide Varianten von mir, Sysclock define und RTC define, das passte.
clock.add in Kleinschreibung, das ist der Parameter der in der trigger Funktion reinkommt und passte bei meinem Tests, wenn du CLOCK.add nimmst wird direkt das define genommen. Kann nur vermuten dass das Senden jede Sekunde mit der neuen Funktion fürs magic Zeitfenster zusammenhängt, keine Ahnung.
Könnte ich mir bei Gelegenheit ev. selbst mal anschauen.
Für RTC option muss auch immer der interne RC-Osc im AVR aktiviert sein, das ist dann seine run clock außerhalb der (RTC-) Sleep Zeiten.
Hallo Tom
Danke für die Antwort. Habe gerade mal papa's Beispielsketch HM-WDS10-TH-O auf die Platine geflasht. Damit läuft es stabil, wie es aussieht. Die Message an den HM-CC-RT-DN wird meistens mit ACK: 01 quittiert, und wenn nicht, wird die Nachricht immer 6x übertragen. Das war z.B. bei meinen Versuchen, den Unisensor umzustricken, nicht der Fall. Dort wird allerdings ebenfalls SleepRTC verwendet, wie ich gesehen habe.
Leider sind meine Kenntnisse und Fähigkeiten begrenzt, bin aber schon an der Spannungsübertragung und der Batteriemessung unter Last interessiert. Ich werde also nochmal etwas vor mich hin dilettieren...
Update
Irgendwas scheint mit der peer-Kommunikation nicht zu stimmen. Die Peer-message wird nur einmal mit waitAck gesendet, danach nur jeweils 1x, ohne waitACK:
altitude: 0
<- 17 01 84 70 A5A503 28BDCE 01 19 2A 80 2B 00 86 47 00 00 0C 38 00 00 - 231
180.500
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00 - 350
-> 0B 03 A0 01 1EA24B A5A503 01 0E - 505
-> 0B 03 A0 01 1EA24B A5A503 01 0E - 702
-> 0B 03 A0 01 1EA24B A5A503 01 0E - 907
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00 - 1009
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00 - 1656
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00 - 2304
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00 - 2951
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00 - 3598
waitAck: 00
166.250
<- 17 03 84 70 A5A503 28BDCE 01 0F 2A 80 2D 00 86 47 00 00 0C 38 00 00 - 4313
151.750
<- 17 04 84 70 A5A503 28BDCE 01 10 2A 80 2E 00 86 47 00 00 0C 38 00 00 - 4429
137.250
<- 17 05 84 70 A5A503 28BDCE 01 0F 2A 80 2E 00 86 47 00 00 0C 38 00 00 - 4542
122.750
Beim Sketch von papa wird jede Message solange gesendet, bis waitAck: 01 gemeldet wird oder 6 Versuche erreicht sind. Woran das liegen könnte, weiß ich nicht.
Gruß
G.
Zitat von: Gernott am 04 August 2019, 18:14:22
Hallo Tom
Danke für die Antwort. Habe gerade mal papa's Beispielsketch HM-WDS10-TH-O auf die Platine geflasht. Damit läuft es stabil, wie es aussieht. Die Message an den HM-CC-RT-DN wird meistens mit ACK: 01 quittiert, und wenn nicht, wird die Nachricht immer 6x übertragen. Das war z.B. bei meinen Versuchen, den Unisensor umzustricken, nicht der Fall. Dort wird allerdings ebenfalls SleepRTC verwendet, wie ich gesehen habe.
Leider sind meine Kenntnisse und Fähigkeiten begrenzt, bin aber schon an der Spannungsübertragung und der Batteriemessung unter Last interessiert. Ich werde also nochmal etwas vor mich hin dilettieren...
Update
Irgendwas scheint mit der peer-Kommunikation nicht zu stimmen. Die Peer-message wird nur einmal mit waitAck gesendet, danach nur jeweils 1x, ohne waitACK:
Beim Sketch von papa wird jede Message solange gesendet, bis waitAck: 01 gemeldet wird oder 6 Versuche erreicht sind. Woran das liegen könnte, weiß ich nicht.
Gruß
G.
Hast du gesehen dass beim Unisensor etwas Kreativität ;) in dieser Form drin ist:
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L198 (https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L198)
Zitat
// als Standard wird BCAST gesendet um Energie zu sparen, siehe Beschreibung unten.
// Bei jeder 20. Nachricht senden wir stattdessen BIDI|WKMEUP, um eventuell anstehende Konfigurationsänderungen auch
// ohne Betätigung des Anlerntaster übernehmen zu können (mit Verzögerung, worst-case 20x Sendeintervall).
papa verwendet im HM-WDS10-TH-O stets BIDI.
Zitat von: Tom Major am 04 August 2019, 23:15:27
Hast du gesehen dass beim Unisensor etwas Kreativität ;) in dieser Form drin ist:
Aha, nein habe ich nicht.
Kann es sein, daß für die stabile Synchronisierung die peer-Messages mehrfach gesendet werden müssen, damit sie nicht zu oft in's Leere laufen und damit immer wieder mal auf den internen Sensor zurückgeschaltet wird? Zumindest ist das meine Beobachtung hier.
Ich werde dann wohl doch den anderen Sketch nehmen. Dort ist der Strom in der Sendepause auch nur 2..3 µA. Kann man da die Spannungsmessung unter Belastung einbauen, oder ist das auch aufwendig?
Zu den peer Messages kann ich nichts sagen, habe ich mich nicht mit beschäftigt.
Wenn die HW stimmt braucht der Unisensor im RTC Betrieb 1uA + die Ruheströme der verbauten Sensoren.
papa hat glaub ich letztens auch die Spannungsmessung unter Belastung eingebaut, schau mal in die Battery Klasse.
Ich werde die Tage mal testen, wie stabil es läuft, wenn ich schrittweise die Anzahl der BCAST-Messages reduziere.
Mit dem default-Wert von 20 sieht es so aus.
du könntest ja mal testweise radikal alle messages BIDI machen wie papa in seinem sketch um zu sehen ob damit dein Problem mit dem Peer vollständig gelöst wird..
Zitat von: Tom Major am 05 August 2019, 22:37:19
du könntest ja mal testweise radikal alle messages BIDI machen wie papa in seinem sketch um zu sehen ob damit dein Problem mit dem Peer vollständig gelöst wird..
Nein leider nicht, es gibt immer wieder Aussetzer. Der Sketch von papa (Diagramm oben) und der entsprechend modifizierte Unisensor1-Sketch (unten) verhalten sich praktisch gleich, soweit man das nach einem Tag sagen kann.
Gibt es eigentlich Fehlfunktionen beim Thermostat wenn die Aussetzer kommen oder wird dann der letzte Wert genommen?
Eventuell ist ein Original Thermostat-fähiger Sensor auch nicht anders?
Zitat von: Tom Major am 07 August 2019, 22:49:46
Gibt es eigentlich Fehlfunktionen beim Thermostat wenn die Aussetzer kommen oder wird dann der letzte Wert genommen?
Eventuell ist ein Original Thermostat-fähiger Sensor auch nicht anders?
Der Thermostat springt dann vorübergehend auf die Temperatur seines internen Sensors und regelt dann je nach Differenz heftig herum. Im Versuch habe ich die interne Temperatur um 3.5K nach unten gesetzt, damit man diese Ereignisse besser sieht. Im Winter ist der Regler meist deutlich wärmer, da er dicht an der Heizung sitzt. Einen originalen Sensor habe ich nicht. Dirk hatte damals bei seinem Sensor, von denen ich hier einige laufen habe, mit der Asksin-FW 0.15 eine stabile Synchronisation erreicht. Ich habe aber keine Ahnung, was er da gegenüber der 0.14 geändert hat. - Falls es nicht besser geht, werde ich einen von diesen Sensoren in den Raum mit dem Regler umziehen.
Zitat von: Gernott am 08 August 2019, 00:22:11
Dirk hatte damals bei seinem Sensor, von denen ich hier einige laufen habe, mit der Asksin-FW 0.15 eine stabile Synchronisation erreicht. Ich habe aber keine Ahnung, was er da gegenüber der 0.14 geändert hat.
habe mir das gerade mal bei Dirk angeschaut, du meinst eventuell diese issue?
"Pairing with thermostat goes often lost"
https://github.com/kc-GitHub/Wettersensor/issues/16 (https://github.com/kc-GitHub/Wettersensor/issues/16)
Hat er am 9.8.2015 markiert als gefixt und geschlossen.
Jetzt kommt das merkwürdige, er hat am 9.8. zwar 11x das readme geändert aber kein Stück Code wenn ich das richtig sehe.
Auch in dem Zeitraum vorher/nachher sehe ich keine Codeänderung die zur Issue passt.
https://github.com/kc-GitHub/Wettersensor/commits/master (https://github.com/kc-GitHub/Wettersensor/commits/master)
Ich habe im Master mal die Reihenfolge zwischen Messen/Senden und Reaktivieren des Alarms getauscht. Probier mal bitte aus, ob das jetzt besser ist.
Hallo,
in der Version 0.15 in der AskSinMain.cpp steht im Kommentar
Zitat
// AES will be ignored at the moment, but burst needed will be translated into the message flag - bit 0 in regLstByte, translated to bit 4 = burst transmission in msgFlag
das heisst ja, dass immer mit Burst gesendet wird. Das funktioniert dann auch mit den Thermostaten. Das ist zwar nicht die eigendlich gewünschte Funktion mit exakter Zeitmessung und erhöht den Stromverbrauch bei allen auf Burst reagierenden Empfängern - aber es funktioniert.
Zitat von: plombe am 08 August 2019, 10:48:23
Hallo,
in der Version 0.15 in der AskSinMain.cpp steht im Kommentardas heisst ja, dass immer mit Burst gesendet wird. Das funktioniert dann auch mit den Thermostaten. Das ist zwar nicht die eigendlich gewünschte Funktion mit exakter Zeitmessung und erhöht den Stromverbrauch bei allen auf Burst reagierenden Empfängern - aber es funktioniert.
eventuell wird bei Dirk nicht immer Burst gesendet, sondern es ist konfigurierbar, siehe dieses hier 2 Zeilen vor deinem Zitat:
Zitat// now we need the respective list4 to know if we have to send a burst message
Und in seinem FHEM und CCU config file gibt es ein burstRx register true/false zum Konfigurieren in List0.
Eventuell war das sein Fix für die "Pairing with thermostat goes often lost" issue.
imho nicht erstrebenswert weil es den DC ziemlich erhöhen wird...
@Tom Major
Leider war Burst fest eingestellt und nicht konfigurierbar. Ich habe mal gekramt und so sah mein Sensor 2016 aus:
Starting sketch...
freeMem: 1246 byte
Device type from PROGMEM: F1 01
Serial from PROGMEM: 55 57 53 37 34 37 35 31 33 34
Address from PROGMEM: EA D5 C7
powerMode: 3
Config changed. Data: (L:0)
lowBatLimit: 16
ledMode: 0
burstRx: 0
transmDevTryMax: 3
content of dDef for 2 elements
cnl:0, lst:0, pMax:0
idx:0, len:9, addr:0
regs: 01 05 0A 0B 0C 12 14 24 25
data: 00 24 F1 00 11 10 03 00 00
cnl:1, lst:4, pMax:6
idx:5, len:1, addr:5
regs: 12
data: 10 03 00 00 00 00
45 12 19 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Slot=647 (161), dst=163205, nTime=162169(419), cnt=0 (1038)
counter=1, mills=1132, startMillis=0, timer=0
burst
<- 14 00 B2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1521)
-> 0A 00 80 02 45 12 19 EA D5 C7 00 (1640)
Slot=590 (147), dst=311265, nTime=147919(419), cnt=1 (163350)
counter=1, mills=163443, startMillis=1132, timer=0
<- 14 01 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (163451)
-> 0A 01 80 02 45 12 19 EA D5 C7 00 (163594)
Slot=532 (133), dst=444687, nTime=133409(409), cnt=2 (311281)
counter=1, mills=311375, startMillis=163443, timer=0
<- 14 02 A2 70 EA D5 C7 45 12 19 00 F5 35 00 00 00 00 00 00 0D 48 (311383)
-> 0A 02 80 02 45 12 19 EA D5 C7 00 (311526)
Slot=730 (182), dst=627601, nTime=182909(409), cnt=3 (444696)
counter=1, mills=444789, startMillis=311375, timer=0
<- 14 03 A2 70 EA D5 C7 45 12 19 00 F5 35 00 00 00 00 00 00 0D 48 (444799)
-> 0A 03 80 02 45 12 19 EA D5 C7 00 (444940)
Slot=673 (168), dst=796300, nTime=168669(419), cnt=4 (627633)
counter=1, mills=627727, startMillis=444789, timer=0
<- 14 04 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (627735)
-> 0A 04 80 02 45 12 19 EA D5 C7 00 (627878)
Slot=615 (153), dst=950470, nTime=154169(419), cnt=5 (796305)
counter=1, mills=796397, startMillis=627727, timer=0
<- 14 05 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (796408)
-> 0A 05 80 02 45 12 19 EA D5 C7 00 (796549)
Slot=557 (139), dst=1090384, nTime=139669(419), cnt=6 (950717)
counter=1, mills=950811, startMillis=796397, timer=0
<- 14 06 A2 70 EA D5 C7 45 12 19 00 F4 37 00 00 00 00 00 00 0D 48 (950819)
-> 0A 06 80 02 45 12 19 EA D5 C7 00 (950962)
Slot=500 (125), dst=1216029, nTime=125419(419), cnt=7 (1090614)
counter=1, mills=1090706, startMillis=950811, timer=0
<- 14 07 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1090716)
-> 0A 07 80 02 45 12 19 EA D5 C7 00 (1090857)
Slot=698 (174), dst=1391166, nTime=174919(419), cnt=8 (1216249)
counter=1, mills=1216344, startMillis=1090706, timer=0
<- 14 08 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1216354)
-> 0A 08 80 02 45 12 19 EA D5 C7 00 (1216495)
Slot=640 (160), dst=1551820, nTime=160419(419), cnt=9 (1391405)
counter=1, mills=1391497, startMillis=1216344, timer=0
<- 14 09 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1391508)
-> 0A 09 80 02 45 12 19 EA D5 C7 00 (1391649)
Wenn man die berechneten Zeiten(dst) mit den Sendezeiten sieht, läuft das auseinander. Ohne Burst würde das so nicht gehen.
Zitat von: papa am 08 August 2019, 08:00:21
Ich habe im Master mal die Reihenfolge zwischen Messen/Senden und Reaktivieren des Alarms getauscht. Probier mal bitte aus, ob das jetzt besser ist.
Muss dann die msgcnt-Zeile auch mit hoch?
else {
// reactivate for next measure
uint8_t msgcnt = device().nextcount();
HMID id;
device().getDeviceID(id);
uint32_t nextsend = delay(id,msgcnt);
tick = nextsend / 1000; // seconds to wait
millis = nextsend % 1000; // millis to wait
rtc.add(*this);
Sonst meckert der Compiler.
Da hast Du natürlich Recht
Zitat von: plombe am 08 August 2019, 20:41:39
@Tom Major
Leider war Burst fest eingestellt und nicht konfigurierbar. Ich habe mal gekramt und so sah mein Sensor 2016 aus:
Starting sketch...
freeMem: 1246 byte
Device type from PROGMEM: F1 01
Serial from PROGMEM: 55 57 53 37 34 37 35 31 33 34
Address from PROGMEM: EA D5 C7
powerMode: 3
Config changed. Data: (L:0)
lowBatLimit: 16
ledMode: 0
burstRx: 0
transmDevTryMax: 3
content of dDef for 2 elements
cnl:0, lst:0, pMax:0
idx:0, len:9, addr:0
regs: 01 05 0A 0B 0C 12 14 24 25
data: 00 24 F1 00 11 10 03 00 00
cnl:1, lst:4, pMax:6
idx:5, len:1, addr:5
regs: 12
data: 10 03 00 00 00 00
45 12 19 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Slot=647 (161), dst=163205, nTime=162169(419), cnt=0 (1038)
counter=1, mills=1132, startMillis=0, timer=0
burst
<- 14 00 B2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1521)
-> 0A 00 80 02 45 12 19 EA D5 C7 00 (1640)
Slot=590 (147), dst=311265, nTime=147919(419), cnt=1 (163350)
counter=1, mills=163443, startMillis=1132, timer=0
<- 14 01 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (163451)
-> 0A 01 80 02 45 12 19 EA D5 C7 00 (163594)
Slot=532 (133), dst=444687, nTime=133409(409), cnt=2 (311281)
counter=1, mills=311375, startMillis=163443, timer=0
<- 14 02 A2 70 EA D5 C7 45 12 19 00 F5 35 00 00 00 00 00 00 0D 48 (311383)
-> 0A 02 80 02 45 12 19 EA D5 C7 00 (311526)
Slot=730 (182), dst=627601, nTime=182909(409), cnt=3 (444696)
counter=1, mills=444789, startMillis=311375, timer=0
<- 14 03 A2 70 EA D5 C7 45 12 19 00 F5 35 00 00 00 00 00 00 0D 48 (444799)
-> 0A 03 80 02 45 12 19 EA D5 C7 00 (444940)
Slot=673 (168), dst=796300, nTime=168669(419), cnt=4 (627633)
counter=1, mills=627727, startMillis=444789, timer=0
<- 14 04 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (627735)
-> 0A 04 80 02 45 12 19 EA D5 C7 00 (627878)
Slot=615 (153), dst=950470, nTime=154169(419), cnt=5 (796305)
counter=1, mills=796397, startMillis=627727, timer=0
<- 14 05 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (796408)
-> 0A 05 80 02 45 12 19 EA D5 C7 00 (796549)
Slot=557 (139), dst=1090384, nTime=139669(419), cnt=6 (950717)
counter=1, mills=950811, startMillis=796397, timer=0
<- 14 06 A2 70 EA D5 C7 45 12 19 00 F4 37 00 00 00 00 00 00 0D 48 (950819)
-> 0A 06 80 02 45 12 19 EA D5 C7 00 (950962)
Slot=500 (125), dst=1216029, nTime=125419(419), cnt=7 (1090614)
counter=1, mills=1090706, startMillis=950811, timer=0
<- 14 07 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1090716)
-> 0A 07 80 02 45 12 19 EA D5 C7 00 (1090857)
Slot=698 (174), dst=1391166, nTime=174919(419), cnt=8 (1216249)
counter=1, mills=1216344, startMillis=1090706, timer=0
<- 14 08 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1216354)
-> 0A 08 80 02 45 12 19 EA D5 C7 00 (1216495)
Slot=640 (160), dst=1551820, nTime=160419(419), cnt=9 (1391405)
counter=1, mills=1391497, startMillis=1216344, timer=0
<- 14 09 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1391508)
-> 0A 09 80 02 45 12 19 EA D5 C7 00 (1391649)
Wenn man die berechneten Zeiten(dst) mit den Sendezeiten sieht, läuft das auseinander. Ohne Burst würde das so nicht gehen.
Bin jetzt nicht in allen Details drin, aber wäre es nicht so dass man 'burstRx' auf 0/1 konfigurieren kann?
Wenn die Zeiten auseinanderlaufen wäre es interessant wie sich ein originaler HM-WDS10-TH-O oder das Wandthermostat diesbezüglich verhalten, dass sie stabile Verbindung zum HK-Teil hinbekommen - auch immer Burst oder stabilere Zeitbasis oder stimmt die Formel für die Sendezeit bei den Homebrew Geräten noch nicht exakt?
@Tom Major
Nach dem Verändern der Software sieht seitdem mein Sensor so aus
Starting sketch...
freeMem: 1229 byte
Device type from PROGMEM: F1 01
Serial from PROGMEM: 55 57 53 37 34 37 35 31 33 37
Address from PROGMEM: ED D8 CA
MAID: F1 00 11
PEER: 45 12 19
powerMode: 3
Config changed. Data: (L:0)
lowBatLimit: 16
ledMode: 0
burstRx: 0
peerNeedsBurst: 0
expectAES: 0
transmDevTryMax: 3
Slot=698 (174), dst=175538, nTime=174400(-100), cnt=0 (1140)
<- 14 00 86 70 ED D8 CA 00 00 00 01 0C 2F 00 00 00 00 00 00 0A 8C (1155)
Slot=640 (160), dst=335538, nTime=159900(-100), cnt=1 (175640)
<- 14 01 86 70 ED D8 CA 00 00 00 01 08 2F 00 00 00 00 00 00 0A F0 (175656)
Slot=582 (145), dst=481039, nTime=145400(-100), cnt=2 (335641)
<- 14 02 86 70 ED D8 CA 00 00 00 01 06 30 00 00 00 00 00 00 0A F0 (335658)
Slot=525 (131), dst=612290, nTime=131150(-100), cnt=3 (481142)
<- 14 03 86 70 ED D8 CA 00 00 00 01 06 30 00 00 00 00 00 00 0A F0 (481158)
Slot=723 (180), dst=793360, nTime=180650(-100), cnt=4 (612712)
<- 14 04 86 70 ED D8 CA 00 00 00 01 06 31 00 00 00 00 00 00 0A F0 (612728)
Slot=665 (166), dst=959930, nTime=166150(-100), cnt=5 (793782)
<- 14 05 86 70 ED D8 CA 00 00 00 01 06 31 00 00 00 00 00 00 0A F0 (793798)
Slot=608 (152), dst=1112249, nTime=151900(-100), cnt=6 (960351)
<- 14 06 86 70 ED D8 CA 00 00 00 01 07 30 00 00 00 00 00 00 0A F0 (960368)
Slot=550 (137), dst=1250069, nTime=137400(-100), cnt=7 (1112671)
<- 14 07 86 70 ED D8 CA 00 00 00 01 07 30 00 00 00 00 00 00 0A F0 (1112688)
Gesendet wird an 00 00 00(Broadcast), es wird kein Ack angefordert.
So laufen 6 Sensoren seit Ende 2016 und haben nie die Verbindung zu den HM-CC-RT-DN verloren.
Zitat von: papa am 08 August 2019, 08:00:21
Ich habe im Master mal die Reihenfolge zwischen Messen/Senden und Reaktivieren des Alarms getauscht. Probier mal bitte aus, ob das jetzt besser ist.
Nein leider nicht, siehe Plot. Zum Test habe ich noch einen originalen Homematic-Aussensensor mit dem Heizkörperregler gepeert. Der Aussensensor ist ziemlich zickig und meldete sich nach dem peerChan erstmal nicht mehr. Leiter, Batterie raus und rein, dann mochte er wieder. Zuerst kam keine Übertragung zustande, dann habe ich den Aktor neu gestartet und es lief ab da ohne Aussetzer.
Ich habe mal nach dem Start für einige Minuten aus dem seriellen Log die Anzahl bis zum ACK:01 und die vorhergehenden Pausenzeiten als Trend für beide Varianten aufgetragen. Interpretieren kann ich es nicht. Zumindest war in dem beobachteten Zeitraum bei Deiner modifizierten Variante sogar mehr Sendeversuche bis zum ACK nötig als vorher. Es kam aber nicht zur Unterbrechung der Übertragung beim Aktor.
@plombe:
Was hast Du denn an der Firmware für den Dirk-Sensor modifiziert? Würdest Du die Firmware zur Verfügung stellen?
Mist - habe ich wieder zurück gebaut. Verwende nun eine andere Methode zum Senden. Diese erwaret keine Antwort des Peers. Kannst Du das mal bitte probieren ?
Welchen Sensor nimmst Du zum Testen ? Vielleicht dauert der measure() Aufruf auch zu lange.
Zitat von: papa am 12 August 2019, 23:03:53
Mist - habe ich wieder zurück gebaut. Verwende nun eine andere Methode zum Senden. Diese erwaret keine Antwort des Peers. Kannst Du das mal bitte probieren ?
Welchen Sensor nimmst Du zum Testen ? Vielleicht dauert der measure() Aufruf auch zu lange.
Ich verwende einen SHT31. Habe mal mit micros() die Zeit für measure() ermittelt, waren etwas über 40 ms.
Ich werde die Tage mal Deine neue Version testen.
Die letzte Version arbeitet leider auch nicht stabil.
Das sieht ja noch schlechter aus als vorher. Es gibt noch eine Ungenauigkeit - die RTC zählt ja immer nur in ganzen Sekunden. Dadurch kann eine Ungenauigkeit von fast einer ganzen Sekunde in die Berechnung des nächsten Sendeslot auftreten - nämlich genau dann, wenn direkt nach dem Aktivieren des nächsten Alarm die Sekunde bei der RTC vorbei ist. Das muss ich die Tage mal noch fixen. Sonst fällt mir dann auch langsam nichts mehr ein.
@Gernott Kannst Du bitte mal die Version aus dem asynch Branch testen. Dazu musst Du aber auch die Lib aus diesem Branch nehmen.
Hallo papa,
du weisst hoffentlich, dass die alte Version 0.15 nur aufgrund eines Fehlers funktioniert. In der Register.h waren gegenüber der vorherigen Versionen 4 Register hinzugefügt worden. Aber die Adressen wurden nicht angepasst, so dass beim Auslesen des Wertes für peerNeedsBurst stattdessen der Wert für lowBatLimit genommen und daher immer mit Burst gesendet wird. Daher funktioniert diese Version. Korrigiert man dies, funktioniert nichts mehr.
-89 { 1, 4, 6, 0x05, 1, 0x0005, 0x0000, (void*)®s.ch1.l4}, // List 4
+89 { 1, 4, 6, 0x00, 1, 0x0009, 0x0000, (void*)®s.ch1.l4}, // List 4
-103 { 0x0000, 0x0002, 0x001a, 0x0025, }, // start address
-104 { 0x0002, 0x0030, 0x000b, 0x0000, }, // length
+103 { 0x0000, 0x0002, 0x0020, 0x0032, }, // start address
+104 { 0x0002, 0x001e, 0x0012, 0x0000, }, // length
H.G.
Nein - das wusste ich nicht. Aber ich würde es gern mit der AskSin++ hinkriegen. Die originalen Sensoren können es ja auch.
In diesem Zusammenhang frage ich mich wo die Formel herstammt - empirisch ermittelt oder eine originale Firmware reversed?
// here we calc when to send next value
uint32_t delay (const HMID& id,uint8_t msgcnt) {
uint32_t value = ((uint32_t)id) << 8 | msgcnt;
value = (value * 1103515245 + 12345) >> 16;
value = (value & 0xFF) + 480;
value *= 250;
Der erste Teil ist ein Pseudo-Zufallsgenerator (Parameter 1103515245 und 12345)
http://pubs.opengroup.org/onlinepubs/009695399/functions/rand.html (http://pubs.opengroup.org/onlinepubs/009695399/functions/rand.html)
Zitat von: Tom Major am 18 August 2019, 13:26:32
In diesem Zusammenhang frage ich mich wo die Formel herstammt - empirisch ermittelt oder eine originale Firmware reversed?
// here we calc when to send next value
uint32_t delay (const HMID& id,uint8_t msgcnt) {
uint32_t value = ((uint32_t)id) << 8 | msgcnt;
value = (value * 1103515245 + 12345) >> 16;
value = (value & 0xFF) + 480;
value *= 250;
der ursprung müsste hier liegen:
https://forum.fhem.de/index.php/topic,18193.msg120907.html#msg120907 (https://forum.fhem.de/index.php/topic,18193.msg120907.html#msg120907)
Zitat von: frank am 18 August 2019, 13:57:46
der ursprung müsste hier liegen:
https://forum.fhem.de/index.php/topic,18193.msg120907.html#msg120907 (https://forum.fhem.de/index.php/topic,18193.msg120907.html#msg120907)
Sehr interessante Info in dem Link, Danke.
250ms Zeitfenster ist nicht viel.
RTC/Uhrenquarz ist sicher ein Muss bei dieser Art Anwendung.
250ms-fenster gilt wohl nur beim vd. tc und vd können sich auch synchronisieren.
bei gepeerten tempfühlern gibt es noch unterschiede mit dem fenster. siehe zb hier:
https://forum.fhem.de/index.php/topic,45735.msg568831.html#msg568831 (https://forum.fhem.de/index.php/topic,45735.msg568831.html#msg568831)
Damals hatte ich meine Sensoren erstmal ohne Schlafzustand mit dem HM-CC-RT-DN gepeert und ein Ack bei jedem Telegramm angefordert (A2). An einem Kontrollpin habe ich die echten Sendezeiten gemessen. Dadurch sah ich, wo korrigiert werden mußte.
Ich hatte in die Sensoren 8 MHz Quarze eingesetzt, aber jetzt in der Versuchsschaltung gesehen, daß die Resonatoren hinreichend genau sind. Es geht ja nur um 2,5 bis 3 Minuten.
Unter Berücksichtigung eines Korrekturwertes (errechneter Wert:gemessener Wert 0.9963) bei der Sendezeitberechnung ist die Übertragung der Versuchsschaltung hinreichend stabil, auch wenn manchmal kein Ack kommt. Der HM-CC-RT-DN vergrößert ja dann sein Empfangsfenster und empfängt bei der nächsten Übertragung wieder.
Das ist dann also mehr ein Ausprobieren gewesen.
Überraschenderweise passte der Korrekturwert bei allen Sensoren.
Eine genaue Zeit mit dem Watchdog zu erreichen, hatte ich mal beschrieben. Das funktioniert auch, wenn ich den Sensor in den Tiefkühler lege.
Da ich ja kein Programmierer bin, kann ich das leider bei der AskSin++ nicht umsetzen.
H.G.
Zitat von: frank am 18 August 2019, 14:24:44
250ms-fenster gilt wohl nur beim vd. tc und vd können sich auch synchronisieren.
bei gepeerten tempfühlern gibt es noch unterschiede mit dem fenster. siehe zb hier:
https://forum.fhem.de/index.php/topic,45735.msg568831.html#msg568831 (https://forum.fhem.de/index.php/topic,45735.msg568831.html#msg568831)
Ich habe jetzt auch einfach mal eine Sekunde extra Wartezeit eingebaut. Das sieht mit meinen Testthermostat jetzt ganz gut aus. Seit gut einer Stunde keine Aussetzer mehr. Wer es selber ausprobieren möchte - das ganze ist im asynch-Branch eingecheckt.
Leider hatte ich heute nach 3 Aussetzer. Habe jetzt mal auf 1,5 Sekunden erhöht.
Zitat von: papa am 19 August 2019, 07:52:15
Leider hatte ich heute nach 3 Aussetzer. Habe jetzt mal auf 1,5 Sekunden erhöht.
Habe mutig auf 2 s erhöht, setzt aber auch aus. 1 s ging auch nicht, 1.5 s hatte ich übersprungen.
1,5 war auch Mist. Bin jetzt auf 750ms. Mal sehen wie es üner Nacht aussieht. Hoffentlich gibt es da nicht noch ein anderes Problem.
Zitat von: papa am 19 August 2019, 21:04:22
1,5 war auch Mist. Bin jetzt auf 750ms. Mal sehen wie es üner Nacht aussieht. Hoffentlich gibt es da nicht noch ein anderes Problem.
Ich probiere gerade mal 500 ms. In der Peerlist stehen jetzt jedesmal (unpeering, neue FW, peering) zwei unbekannte IDs, die sich nur mittels peerBulk entfernen lassen. Ist das normal?
Nein, sollte nicht sein. Aber Du kannst einfach die neue FW draufmachen ohne die Peering zu löschen.
Ich habe mich nach langer Zeit auch mal wieder an einen Asksinpp Eigenbausensor begeben und komme leider an einer Stelle in der Arduino IDE nicht weiter. Ich versuche den aktuellen HB-UNI-Sensor1 von TomMajor zu kompilieren und erhalte die nachfolgende Fehlermeldung, wenn ich
#define NDEBUG
auskommentieren:
C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\arduino\avr\cores\arduino\Print.h: In function 'write.constprop':
C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\arduino\avr\cores\arduino\Print.h:55:5: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper.exe: fatal error: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\tools\avr/bin/avr-gcc returned 1 exit status
compilation terminated.
c:/program files/windowsapps/arduinollc.arduinoide_1.8.21.0_x86__mdqgnx93n4wtt/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
exit status 1
Fehler beim Kompilieren für das Board Arduino Pro or Pro Mini.
Wenn ich
#define NDEBUG
einkommentiere, läuft das Kompilieren ohne Probleme durch und der Sketch wird übertragen. Allerdings kann ich dem Sensor keine Ausgabe über den Serial Monitor entlocken, obwohl das Debugging ja offensichtlich eingeschaltet ist. Pairing mit Fhem und Übertragung von Werten läuft hingegen ohne Auffälligkeiten.
Mit demFreqTest Sketch werden ohne Probleme Meldungen auf den Serial Monitor ausgegeben. An dem Sensor selbst und an dem verwendeten Ftdi Adapter liegt es also offenbar nicht.
Hat jemand eine Idee wo mein Fehler liegt? ???
Der "internal compiler error: Segmentation fault" ist ein gcc Bug der öfters vorkommt, das Netz ist voll davon.
Es gibt diverse workarounds, meiner ist in der Arduino IDE / Settings die Box 'Compiler warnings' auf einen anderen als den aktuellen Eintrag zu stellen (es gibt 4 Einträge). Das hilft bei mir immer.
Hallo Tom,
vielen Dank für deine schnelle Antwort. Das Ändern der Compiler warnings hat leider nicht geholfen. Dafür konnte eine Neuinstallation der IDE die Fehlermeldungen vollständig beseitigen.
Leider bekomme ich weiterhin keine Ausgaben auf dem Serial Monitor. Ich habe das Gefühl, dass der Sensor direkt nach dem Starten hängenbleibt. Jedoch nur, wenn er am FTDI Adapter hängt.
Nach dem Öffnen des Serial Monitors startet der Sensor ja neu dann blinkt die LED einmal auf, geht wieder aus und wieder an und bleibt dann auch dauerhaft an. Dieses Verhalten konnte ich bei bisher zwei Sensoren, einmal Atmega328 auf deiner "Sensor P/L/H/T v2.01" Platine und ein nackter Pro Mini, reproduzieren.
Wenn der Sensor nicht an den FTDI angeschlossen ist, blinkt die LED dreimal auf und bleibt danach auch erstmal aus.
Mit einem anderen Sketch aus der AsksinPP v4 Lib funktioniert die Ausgabe komischerweise ganz normal.
Zitat von: Spezialtrick am 20 August 2019, 15:28:09
Nach dem Öffnen des Serial Monitors startet der Sensor ja neu dann blinkt die LED einmal auf, geht wieder aus und wieder an und bleibt dann auch dauerhaft an.
Kann es sein, daß es mit der verwendeten Spannungsmessung und dem eingestellten Wert für BAT_VOLT_CRITICAL zusammenhängt? Dann geht u.U. der Sensor nach dem ersten Durchlauf in den Dauerschlaf.
Bei mir war das der Fall, wenn ich die externe Batterie messe, aber für das Flashen direkt auf die +3.3V einspeise.
Zitat von: Gernott am 19 August 2019, 22:02:18
Ich probiere gerade mal 500 ms.
Egal wie ich das setze. Ich habe immer wieder Aussetzer. Irgendwas stimmt da noch nicht :-(
Was mich ja auch wundert, dass das Wandthermostat immer 3 Telegramme mit dem selben Messagecounter schickt.
CLIMATECTRL_EVENT, INFO und WEATHER.
z.B.
ignore 0C 05 86 5A 5154B0 000000 8C E3 3C - 432234
ignore 0E 05 84 10 5154B0 000000 0B 8C E3 0B 00 - 442222
ignore 0C 05 84 70 5154B0 000000 00 E3 3C - 452206
Vielleicht ist das CLIMATECTRL_EVENT (enthält ja das selbe wie WEATHER) noch von Bedeutung?
Zitat von: jp112sdl am 20 August 2019, 19:53:18
Was mich ja auch wundert, dass das Wandthermostat immer 3 Telegramme mit dem selben Messagecounter schickt.
CLIMATECTRL_EVENT, INFO und WEATHER.
z.B.
ignore 0C 05 86 5A 5154B0 000000 8C E3 3C - 432234
ignore 0E 05 84 10 5154B0 000000 0B 8C E3 0B 00 - 442222
ignore 0C 05 84 70 5154B0 000000 00 E3 3C - 452206
Vielleicht ist das CLIMATECTRL_EVENT (enthält ja das selbe wie WEATHER) noch von Bedeutung?
Könnte das nicht bedeuten dass die Originalgeräte es auch nicht sauber mit dem Timing hinbekommen und deswegen zeitversetzt 3 Telegramme absetzten einfach um die Wahrscheinlichkeit zu erhöhen?
Wobei nur das Wandthermostat den Typ 10 und 5A sendet.
<frame id="THERMALCONTROL_EVENT" direction="from_device" allowed_receivers="BROADCAST,CENTRAL,OTHER" event="true" type="0x5A" fixed_channel="2">
<parameter type="integer" index="9.2" size="0.6" param="SET_TEMPERATURE"/>
<parameter type="integer" signed="true" index="9.0" size="1.2" param="ACTUAL_TEMPERATURE"/>
<parameter type="integer" index="11.0" size="1.0" param="ACTUAL_HUMIDITY"/>
</frame>
Und THERMALCONTROL_EVENT wird auch auf Kanal 2 gesendet.
Das WDS40 hat jedoch nur WEATHER... kann also nur 1 Telegramm senden...
Hmm...
W
@Spezialtrick
Hmm, viel fällt mir dazu heute nicht mehr ein.
Nur z.B. das, mal den FTDI Adapter so trennen mit Einzelkabeln dass nur Tx und Gnd vom Sensor in Richtung PC gehen, ob das hilft.
Und die Batterie wie Gernott schreibt.
@Jerome
Das WDS40 sendet also nur einmal? Dann ist die Theorie wohl hinfällig mit der Erhöhung der Wahrscheinlichkeit.
Man könnte wahrscheinlich mit dem AskSinPP Analyzer mal einen Millisek. genauen Log machen zwischen Originalgerät und papas Temperatursensor um zu sehen ob da im Original etwas anders im Timing läuft.
Ist aber sicher aufwendig und geht wegen dem Start Synchronisation vom Pairing-Zeitpunkt aus wohl nur nacheinander für beide Geräte? und dann halt die Logs bezüglich Timing analysieren..
Zitat von: Tom Major am 20 August 2019, 23:01:25
@Spezialtrick
Hmm, viel fällt mir dazu heute nicht mehr ein.
Nur z.B. das, mal den FTDI Adapter so trennen mit Einzelkabeln dass nur Tx und Gnd vom Sensor in Richtung PC gehen, ob das hilft.
Und die Batterie wie Gernott schreibt.
Offenbar hatte mein Atmega einen Defekt. Nachdem ich diesen ausgetauscht habe, erhalte ich auch die gewünschten Ausgaben auf dem Serial Monitor. Allerdings nur, wenn die Option 1 für die Batteriespannungsmessung ausgewählt ist. Gernott hat also den richtigen Hinweis geliefert. Danke!
Komischerweise, kann ich den Sketch lediglich einmal aufspielen, nachdem ich den Bootloader gebrannt habe. Dann klappt es nicht mehr, bis ich wiederrum den Bootloader erneut brenne. Aber damit kann ich leben.
Gibt es einen Trick damit auch die Messwerte des UV Sensors in FHEM auftauchen? Auf dem Serial Monitor konnte ich die Werte sehen. :)
Zitat von: Spezialtrick am 23 August 2019, 15:26:06
Komischerweise, kann ich den Sketch lediglich einmal aufspielen, nachdem ich den Bootloader gebrannt habe. Dann klappt es nicht mehr, bis ich wiederrum den Bootloader erneut brenne. Aber damit kann ich leben.
Welchen Bootloader verwendest Du? Den OTA Bootloader mit HM-ID und Seriennummer? Oder den Standard Ardiono (bzw. Optiboot) Bootloader?
Gruß Peter
Zitat von: Spezialtrick am 23 August 2019, 15:26:06
Komischerweise, kann ich den Sketch lediglich einmal aufspielen, nachdem ich den Bootloader gebrannt habe. Dann klappt es nicht mehr, bis ich wiederrum den Bootloader erneut brenne. Aber damit kann ich leben.
Gibt es einen Trick damit auch die Messwerte des UV Sensors in FHEM auftauchen? Auf dem Serial Monitor konnte ich die Werte sehen. :)
1x aufspielen: Klingt danach ob der bootldr überschrieben wird.
Ist sketch size < 32k - bldr size gewährleistet?
UV Sensor: mal die customData in Sketch und Perl script anschauen. damit kann man quasi jedes beliebige reading aus den customData für FHEM erzeugen, auch einen UV-Index.
Zitat von: PeMue am 23 August 2019, 15:29:40
Welchen Bootloader verwendest Du? Den OTA Bootloader mit HM-ID und Seriennummer? Oder den Standard Ardiono (bzw. Optiboot) Bootloader?
Gruß Peter
Ich verwende den Standard Arduino Bootloader den Holger hier hinterlegt hat und flashe diesen ebenfalls mit den beiliegenden Tools:
https://github.com/pa-pa/AskSinPP/blob/master/bootloader/avr/ATmegaBOOT_168_atmega328_pro_8MHz.hex (https://github.com/pa-pa/AskSinPP/blob/master/bootloader/avr/ATmegaBOOT_168_atmega328_pro_8MHz.hex)
Zitat von: Tom Major am 23 August 2019, 15:38:15
1x aufspielen: Klingt danach ob der bootldr überschrieben wird.
Ist sketch size < 32k - bldr size gewährleistet?
Laut der Ausgabe der Arduino IDE ja:
avrdude: 27658 bytes of flash verified
Zitat von: PeMue am 23 August 2019, 15:29:40
Welchen Bootloader verwendest Du? Den OTA Bootloader mit HM-ID und Seriennummer? Oder den Standard Ardiono (bzw. Optiboot) Bootloader?
Sollte ich einen anderen Bootloader verwenden?
Zitat von: Spezialtrick am 23 August 2019, 17:25:23
Sollte ich einen anderen Bootloader verwenden?
Eas gibt noch den OTA Bootloader, normalerweise reicht der Standard ...
Gruß Peter
Zitat von: Spezialtrick am 23 August 2019, 15:46:38
Ich verwende den Standard Arduino Bootloader den Holger hier hinterlegt hat und flashe diesen ebenfalls mit den beiliegenden Tools:
https://github.com/pa-pa/AskSinPP/blob/master/bootloader/avr/ATmegaBOOT_168_atmega328_pro_8MHz.hex (https://github.com/pa-pa/AskSinPP/blob/master/bootloader/avr/ATmegaBOOT_168_atmega328_pro_8MHz.hex)
Laut der Ausgabe der Arduino IDE ja:
avrdude: 27658 bytes of flash verified
Sieht gut aus, ich habe keine Idee warum das serielle Flashen dann nur einmal geht.
Ich setze sicherheitshalber immer noch die BLB1 Fuse so (2. Bild):
https://github.com/TomMajor/SmartHome/tree/master/Info/Bootloader#standard-bootloader-atmega328p-rc-oszillator-oder-quarz-8mhz (https://github.com/TomMajor/SmartHome/tree/master/Info/Bootloader#standard-bootloader-atmega328p-rc-oszillator-oder-quarz-8mhz)
Dann kann die Application nie den bootldr überschreiben (zumindest in der Theorie ;) )
Zitat von: papa am 19 August 2019, 21:04:22
1,5 war auch Mist. Bin jetzt auf 750ms. Mal sehen wie es üner Nacht aussieht. Hoffentlich gibt es da nicht noch ein anderes Problem.
Ich war einige Tage unterwegs und hatte nach 600 ms mit vielen Aussetzern dann mal 700 ms gesetzt. Damit ist er 3 Tage nur mit je einem Aussetzer pro Tag gelaufen. Ich werde es nun mal feinfühlig erhöhen und mal sehen, wie es sich entwickelt.
Zitat von: Spezialtrick am 23 August 2019, 15:26:06
Gernott hat also den richtigen Hinweis geliefert. Danke!
Komischerweise, kann ich den Sketch lediglich einmal aufspielen, nachdem ich den Bootloader gebrannt habe. Dann klappt es nicht mehr, bis ich wiederrum den Bootloader erneut brenne. Aber damit kann ich leben.
Bitte, gerne. Vielleicht habe ich ja noch einen. Vor etlichen Wochen hatte ich dieses Problem auch. Prüfe mal nach dem Flashen des Bootloaders, ob die Fuses noch stimmen. Aus mir unerfindlichen Gründen haben die sich dabei jedesmal verstellt und der Sketch hat den Bootloader überschrieben. Ging natürlich dann nur ein Mal, wie bei Dir. Nachdem ich die Fuses wieder korrigiert hatte, konnte ich dann den Sketch hochladen, ohne den Bootloader jedes Mal zu überschreiben (siehe hier (https://forum.fhem.de/index.php/topic,20620.msg951650.html#msg951650)).
Zitat von: Gernott am 23 August 2019, 20:22:10
Ich war einige Tage unterwegs und hatte nach 600 ms mit vielen Aussetzern dann mal 700 ms gesetzt. Damit ist er 3 Tage nur mit je einem Aussetzer pro Tag gelaufen. Ich werde es nun mal feinfühlig erhöhen und mal sehen, wie es sich entwickelt.
So gut sieht es bei mir nicht aus. Ich vermute aber auch, das ich auch schlechten Empfang habe, da das Thermostat unterm Dach und der Sensor im Keller ist (2 Etagen dazwischen). Da kann schon mal was verloren gehen.
Kurzes Update:
Hatte von 700 ms (1 Aussetzer/Tag) auf 750 ms gestellt. Da hatte ich wieder 10 Aussetzer pro Tag. Jetzt läuft es mit 740 ms seit einem Tag synchron und die Temperaturkurven sind auch ziemlich parallel. Das Optimum scheint (bei mir?) dann also in diesem Bereich zu liegen.
Zitat von: Gernott am 23 August 2019, 20:33:34
Bitte, gerne. Vielleicht habe ich ja noch einen. Vor etlichen Wochen hatte ich dieses Problem auch. Prüfe mal nach dem Flashen des Bootloaders, ob die Fuses noch stimmen. Aus mir unerfindlichen Gründen haben die sich dabei jedesmal verstellt und der Sketch hat den Bootloader überschrieben. Ging natürlich dann nur ein Mal, wie bei Dir. Nachdem ich die Fuses wieder korrigiert hatte, konnte ich dann den Sketch hochladen, ohne den Bootloader jedes Mal zu überschreiben (siehe hier (https://forum.fhem.de/index.php/topic,20620.msg951650.html#msg951650)).
Zitat von: Tom Major am 23 August 2019, 19:33:00
Sieht gut aus, ich habe keine Idee warum das serielle Flashen dann nur einmal geht.
Ich setze sicherheitshalber immer noch die BLB1 Fuse so (2. Bild):
https://github.com/TomMajor/SmartHome/tree/master/Info/Bootloader#standard-bootloader-atmega328p-rc-oszillator-oder-quarz-8mhz (https://github.com/TomMajor/SmartHome/tree/master/Info/Bootloader#standard-bootloader-atmega328p-rc-oszillator-oder-quarz-8mhz)
Dann kann die Application nie den bootldr überschreiben (zumindest in der Theorie ;) )
Genauso war es bei mir. Nachdem Flashen des Bootloaders wurden die Fuses immer wieder verändert. Insbesondere wurde die Lock Fuse immer mit 0xFF gesetzt.
Nachdem ich diese auf 0xEF geändert habe, kann ich nun immer wieder einen Sketch aus der IDE flashen. :)
Zitat von: Tom Major am 23 August 2019, 15:38:15
UV Sensor: mal die customData in Sketch und Perl script anschauen. damit kann man quasi jedes beliebige reading aus den customData für FHEM erzeugen, auch einen UV-Index.
Im Fhem Modul findet sich ja dieser Teil zum CustomData:
# 16bit customData, ab Firmware 0x13
$stateMsg .= ' X: ' . $customData;
push (@events, [$shash, 1, 'customData:' . $customData]);Und im Sensor Sketch dieser Teil:
#ifdef SENSOR_VEML6070
veml6070.measure();
// Beispiel custom payload, 4bit für UV-Index (integer 0..11)
uint8_t uvi = veml6070.uvIndex();
customData &= 0xFFF0;
customData |= (uvi & 0x0F);@Tom Major: Könntest du mir hierzu ein paar weiterführende Tipps geben? Ich habe ehrlich gesagt keine Idee wo ich ansetzen soll, weil ich den Code nicht lesen kann. Analog zu den anderen Messwerten die mit dem Weather Event gesendet werden, könnte der Teil im Fhem Modul doch irgendwie so lauten:
# 16bit customData, ab Firmware 0x13
my $customData = customData &= 0xFFF0;
$stateMsg .= ' X: ' . $customData;
push (@events, [$shash, 1, 'customData:' . $customData]);Soweit die UV-Messung überhaupt an Fhem übertragen wird. ???
Zitat von: Spezialtrick am 25 August 2019, 16:29:25
@Tom Major: Könntest du mir hierzu ein paar weiterführende Tipps geben? Ich habe ehrlich gesagt keine Idee wo ich ansetzen soll, weil ich den Code nicht lesen kann. Analog zu den anderen Messwerten die mit dem Weather Event gesendet werden, könnte der Teil im Fhem Modul doch irgendwie so lauten:
# 16bit customData, ab Firmware 0x13
my $customData = customData &= 0xFFF0;
$stateMsg .= ' X: ' . $customData;
push (@events, [$shash, 1, 'customData:' . $customData]);
Soweit die UV-Messung überhaupt an Fhem übertragen wird. ???
Ab Firmware 1.3 ist die customData immer in der Message dabei.
So müsste es ungefähr gehen (ungetestet)
# UV-Index VEML6070
my $uvindex = $customData & 0x000F;
$stateMsg .= ' U: ' . $uvindex;
push (@events, [$shash, 1, 'UV-Index:' . $uvindex]);
Falls das geht ? kann ich das als Beispiel in dem Skript einkommentiert mit aufnehmen.
Du musst nach Änderung mindestens ein reload des Skripts machen oder FHEM Neustart.
Zitat von: Tom Major am 25 August 2019, 17:40:55
Ab Firmware 1.3 ist die customData immer in der Message dabei.
So müsste es ungefähr gehen (ungetestet)
# UV-Index VEML6070
my $uvindex = $customData & 0x000F;
$stateMsg .= ' U: ' . $uvindex;
push (@events, [$shash, 1, 'UV-Index:' . $uvindex]);
Falls das geht ? kann ich das als Beispiel in dem Skript einkommentiert mit aufnehmen.
Das scheint zu funktionieren. :)
Zumindest wird das Reading im Sensor angezeigt. Derzeit logischerweise ohne UV Strahlung. :D Ich melde mich morgen, wenn die Sonne wieder scheint.
Herzlichen Dank schon mal!
ok, sehr gut.
Ich denke bei Sonne sollte jetzt einem UVI > 0 in FHEM nichts im Wege stehen. :)
Finales Update zu meinen Versuchen mit papa's AsksinPP-async. Mit einem EXTRAMILLIS zwischen 720 und 740 ist die Verbindung zum HM-CC-RT-DN stabil. Ich habe den Code zur Berechnung der Sendezeiten auch in den UniSensor1 von Tom implementiert, wo er ebenfalls stabil läuft.
Vielen Dank an papa und Tom für die Unterstützung.
Zitat von: Gernott am 29 August 2019, 19:42:49
Finales Update zu meinen Versuchen mit papa's AsksinPP-async. Mit einem EXTRAMILLIS zwischen 720 und 740 ist die Verbindung zum HM-CC-RT-DN stabil. Ich habe den Code zur Berechnung der Sendezeiten auch in den UniSensor1 von Tom implementiert, wo er ebenfalls stabil läuft.
Vielen Dank an papa und Tom für die Unterstützung.
Gut zu wissen.
Kannst du mal deinen aktuellen sketch posten? Dann nehme ich die Änderungen ev. als Kommentar mit in den UniSensor, in einem halben Jahr kommt sicher der nächste mit diesem Problem. ;)
Zitat von: Tom Major am 29 August 2019, 20:30:28
Gut zu wissen.
Kannst du mal deinen aktuellen sketch posten? Dann nehme ich die Änderungen ev. als Kommentar mit in den UniSensor, in einem halben Jahr kommt sicher der nächste mit diesem Problem. ;)
Hier ist er. Ich hatte noch den SHT31 dazugenommen, aus einem von papa's Beispielen.
Zitat von: Gernott am 29 August 2019, 19:42:49
Finales Update zu meinen Versuchen mit papa's AsksinPP-async. Mit einem EXTRAMILLIS zwischen 720 und 740 ist die Verbindung zum HM-CC-RT-DN stabil. Ich habe den Code zur Berechnung der Sendezeiten auch in den UniSensor1 von Tom implementiert, wo er ebenfalls stabil läuft.
Vielen Dank an papa und Tom für die Unterstützung.
Das klingt ja super. Dann muss ich das mal in den Master mergen. Der async-Branch ist eigentlich für was anderes.
Ich wollte einfach mal DANKE sagen! :)
Mein neuer Universalsensor läuft seit nunmehr fast vier Wochen einwandfrei und meldet zuverlässig alle paar Minuten die Sensorwerte.
Ich messe mit dem Sensor die Temperatur, die Luftfeuchtigkeit, den Luftdruck, die Helligkeit und die UV-Einstrahlung.
Danke an Dirk für die Initiierung des Projekts! :)
Danke an Papa für das tolle Gehäuse und die Umsetzung der AsksinPP! :)
Danke an Tom Major für den "idiotensicheren" Sketch! :)
Danke an alle anderen die dieses Projekt möglich gemacht haben! :)
Ein paar Fotos von meiner Umsetzung des Sensors füge ich als Anhang bei.
(https://uploads.tapatalk-cdn.com/20190923/c75f64c34dc5570333681df64cd5393d.jpg)
(https://uploads.tapatalk-cdn.com/20190923/0a8428596aca86bb84af73bf78e97148.jpg)
(https://uploads.tapatalk-cdn.com/20190923/9e44841df77083641e6685ed4a6bbdbe.jpg)
(https://uploads.tapatalk-cdn.com/20190923/cc8e43cbb8ec0be379b7dbeb77744109.jpg)
(https://uploads.tapatalk-cdn.com/20190923/a9f7914a0ba05a31860a6322d452eec1.jpg)
Zitat von: Spezialtrick am 23 September 2019, 20:44:54
Ich wollte einfach mal DANKE sagen! :)
Mein neuer Universalsensor läuft seit nunmehr fast vier Wochen einwandfrei und meldet zuverlässig alle paar Minuten die Sensorwerte.
Ich messe mit dem Sensor die Temperatur, die Luftfeuchtigkeit, den Luftdruck, die Helligkeit und die UV-Einstrahlung.
Danke an Dirk für die Initiierung des Projekts! :)
Danke an Papa für das tolle Gehäuse und die Umsetzung der AsksinPP! :)
Danke an Tom Major für den "idiotensicheren" Sketch! :)
Danke an alle anderen die dieses Projekt möglich gemacht haben! :)
Ein paar Fotos von meiner Umsetzung des Sensors füge ich als Anhang bei.
Kleiner Tipp, wenn die Kabel nach unten raus gehen, kann oben kein Wasser rein laufen.
Zitat von: gloob am 23 September 2019, 21:09:20
Kleiner Tipp, wenn die Kabel nach unten raus gehen, kann oben kein Wasser rein laufen.
Der Sensor steht auf einem überdachten Balkon. Wasser stellt also kein Problem dar. :)
Zitat von: Spezialtrick am 23 September 2019, 20:44:54
Ich wollte einfach mal DANKE sagen! :)
Mein neuer Universalsensor läuft seit nunmehr fast vier Wochen einwandfrei und meldet zuverlässig alle paar Minuten die Sensorwerte.
Ich messe mit dem Sensor die Temperatur, die Luftfeuchtigkeit, den Luftdruck, die Helligkeit und die UV-Einstrahlung.
Danke an Dirk für die Initiierung des Projekts! :)
Danke an Papa für das tolle Gehäuse und die Umsetzung der AsksinPP! :)
Danke an Tom Major für den "idiotensicheren" Sketch! :)
Danke an alle anderen die dieses Projekt möglich gemacht haben! :)
Ein paar Fotos von meiner Umsetzung des Sensors füge ich als Anhang bei.
Freut mich und danke für die Rückmeldung. Sonst hört man eher nur bei Problemen von den Projekten. ;)
Zitat von: Tom Major am 25 September 2019, 20:04:03
Freut mich und danke für die Rückmeldung. Sonst hört man eher nur bei Problemen von den Projekten. ;)
Daher wollte ich mal eine positive Rückmeldung geben. :)
Welche Zeit habt ihr für das
updateIntervall vergeben?
Mein HB-UNI-Sensor ist jetzt testweise aufgebaut. Er läuft seit ein paar Tagen und liefert fleißig seine Werte.
Um genauere Temperaturwerte zu bekommen, habe ich zusätzlich zum BME280-Sensor auch den DS18B20 eingelötet und aktiviert. Als PIN habe ich die ,,3" eingetragen. Er wird aber nicht erkannt und liefert nur den Wert -99.
Hat jemand einen Tipp für mich?
Gruß
Hubert
Zitat von: hubi3922 am 12 Oktober 2019, 19:56:20
Mein HB-UNI-Sensor ist jetzt testweise aufgebaut. Er läuft seit ein paar Tagen und liefert fleißig seine Werte.
Um genauere Temperaturwerte zu bekommen, habe ich zusätzlich zum BME280-Sensor auch den DS18B20 eingelötet und aktiviert. Als PIN habe ich die ,,3" eingetragen. Er wird aber nicht erkannt und liefert nur den Wert -99.
Hat jemand einen Tipp für mich?
Gruß
Hubert
- Verbindungen des 18b20 durchmessen
- FTDI Adapter anschliessen und debug log anschauen, es gibt DS18b20 found bzw. not found Meldungen
- läuft der ds18b20 alleine wenn BME und MAX deaktiviert sind?
Hallo Tom,
die Verbindungen habe ich gemessen, sind ok.
Das debug log meldet den DS18x20 als no found.
Ich habe erst eine Ausgabe bekommen, als ich am COM-Port die Geschwindigkeit von 7200 eingestellt habe.
Ich habe den DS18X20 aktiviert gelassen und dann mal die anderen Sensoren (BME280, MAX..) deaktiviert, mal beide, mal einzeln.
Der Sensor lieferte dann immer die Testwerte.
Zitat von: hubi3922 am 12 Oktober 2019, 23:15:22
Hallo Tom,
die Verbindungen habe ich gemessen, sind ok.
Das debug log meldet den DS18x20 als no found.
Ich habe erst eine Ausgabe bekommen, als ich am COM-Port die Geschwindigkeit von 7200 eingestellt habe.
Ich habe den DS18X20 aktiviert gelassen und dann mal die anderen Sensoren (BME280, MAX..) deaktiviert, mal beide, mal einzeln.
Der Sensor lieferte dann immer die Testwerte.
Aufgrund deiner Aussage mit den 7200 Baud an der seriellen vermute ich dass dein AVR noch die Fuse CKDIV8 aktiv hat.
Die muss raus.
Das bringt das DS18x20 timing durcheinander. Wundert mich das das der Rest überhaupt läuft..
Hallo Tom,
perfekter Hinweis.
Es lag in Tat an der noch aktiven Fuse CKDIV8.
Nach dem deaktivieren war der Sensor DS18x20 in der seriellen Ausgabe als gefunden aufgelistet.
Es werden unterschiedliche Werte für die Temperatur vom BME280 und DS18x20 angezeigt.
In FHEM wird dann der Wert des DS18x20 übernommen.
Danke.
Um den Uni-Sensor fertig aufzubauen, habe ich noch Batteriehalter und Acrylstäbe für die Lichtmessung bestellt.
Gruß
Hubert
Zitat von: hubi3922 am 13 Oktober 2019, 19:38:20
Hallo Tom,
perfekter Hinweis.
Es lag in Tat an der noch aktiven Fuse CKDIV8.
Nach dem deaktivieren war der Sensor DS18x20 in der seriellen Ausgabe als gefunden aufgelistet.
Es werden unterschiedliche Werte für die Temperatur vom BME280 und DS18x20 angezeigt.
In FHEM wird dann der Wert des DS18x20 übernommen.
Danke.
Um den Uni-Sensor fertig aufzubauen, habe ich noch Batteriehalter und Acrylstäbe für die Lichtmessung bestellt.
Gruß
Hubert
Freut mich das es jetzt geht.
Den I2C-Sensoren macht eine um Faktor 8 langsamere clock nichts aus, aber der 1-Wire Bus am ds18b20 braucht relativ genaues timing im us Bereich.
Ja, der Temperatur Messwert eines aufgelöteten BME ist einfach träger als der eines in der Luft hängenden ds18b20.
Hatte ich auch hier vermerkt (mit Messwerten von Gernott) und empfehle immer einen ds18b20 zusätzlich zu verbauen.
https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#tr%C3%A4gheit-verschiedener-temperatursensoren (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#tr%C3%A4gheit-verschiedener-temperatursensoren)
Respekt vor den aufgelöteten BME und MAX, dein Werk oder war PeMue involviert?
Danke.
PeMue hat mir zum Start mit drei Platinen und dem aufgelötetem MAX geholfen.
Vielen Dank nochmal.
Das war der Start. Leider habe ich nur eine Platine so richtig funktionsfähig bekommen.
Danach habe ich Platinen mit deiner Vorlage bestellt. Die weiteren Bauteile habe ich dann mit einem Heißluftlötkolben gelötet. Klappte besser als ich gedacht hätte.
Hubert
ok, alles klar.
Klingt interessant das mit dem Heißluftlötkolben, da habe ich noch keine Erfahrungen.
Hallo zusammen,
ich klink mich mal ein weil ich auch gerade an dem Uni-Sensor dran bin.
Bekommt man die Breakoutlosen BME & Max Chips mit Heißluft gelötet oder müssen die in den Ofen?
Ich hab mir eine Maiskolben Lötstation gebaut, SMD geht ganz gut damit.
Und hat jemand eine Bezugsquelle für den Max?
Den BME gibts ja bei Reichelt wenn ich richtig gesehen habe.
Danke & Viele Grüße
Lars
Hallo Lars,
ich habe meine MAX über 1,2,3 bekommen. Die waren aber nicht ganz billig. Für 4 Stück habe ich 18,80 Euro bezahl. Sind jedoch original echt.
Ich habe sowohl den MAX, wie auch den BME Sensor mit Heißluft gelötet. Klappte ganz gut.
Es war für mich auch ein Neu-Versuch und wollte nicht direkt ein paar Hundert Euro für eine Lötstation anlegen. Deshalb habe ich für die ersten Lötversuche eine günstige geholt.
(,,858D SMD Hot Air Rework Station HeißLuft")
Gruß
Hubert
Zitat von: hubi3922 am 16 Oktober 2019, 16:40:36
Ich habe sowohl den MAX, wie auch den BME Sensor mit Heißluft gelötet. Klappte ganz gut.
Hast Du die Lotpaste von Hand dispenst, den Baustein draufgesetzt und heiß gemacht?
Danke + Gruß
Peter
Hallo Peter,
ja, ich habe ein Dispenser Set bestellt. Dann mit einer ganz dünnen Nadel die Lötpaste unter einer Leuchtlupe aufgetragen (mit sehr viel Feingefühl und einer ruhigen Hand ;) ). Es war schon sehr knifflig. Das Auftragen der Lötpaste durch die dünne Nadel war grenzwertig, schwierig. Die Lötpaste kam kaum durch die Nadel.
Meiner Meinung nach, ist es nichts für eine größere Stückzahl. Dafür ist es zu kompliziert und evtl Fehler sind da noch gar nicht berücksichtigt.
Mit einer Schablone wäre es bestimmt einfacher.
Gruß
Hubert
Ich glaube, so präzise muss man das gar nicht machen. Ich hab das auch einmal gemacht mit Heißluft und Lötpaste (zum ersten Mal) und hab, ich glaube mit einem Zahnstocher, etwas Lötpaste auf dem Pad verteilt. Die Paste "schrumpft" ja sehr zusammen und zieht sich dann automatisch zu den Pads. Man darf aber nicht zu viel und nicht zu wenig nehmen. Also ich hatte mir das im Vorfeld auch sehr kniffelig vorgestellt und es ging dann überraschend gut.
...danke für die Tips und Infos.
Viele Grüße
Lars
Zitat von: vbs am 16 Oktober 2019, 23:43:09
Man darf aber nicht zu viel und nicht zu wenig nehmen. Also ich hatte mir das im Vorfeld auch sehr kniffelig vorgestellt und es ging dann überraschend gut.
Unter folgenden Voraussetzungen:
- die Lotpaste ist keine 6 Monate alt, ansonsten verliert sie die Viskosität und man kann nicht mehr sauber dispensen
- eine sehr ruhige Hand und
- eine gute Lupe
Im Vergleich zur Schablone aber sehr zeitaufwändig, daher spendiere ich lieber die 15 € für eine Schablone.
Gruß Peter
Zitat von: PeMue am 18 Oktober 2019, 10:22:16
Im Vergleich zur Schablone aber sehr zeitaufwändig, daher spendiere ich lieber die 15 € für eine Schablone.
Gruß Peter
Doofe Frage: Das geht aber nur im Ofen, weil sie sonst von der Heißluft-Lötstation weggeweht wird? Wie sehen denn solche Schablonen aus?
Zitat von: Kai-Alfonso am 18 Oktober 2019, 13:49:35
Doofe Frage: Das geht aber nur im Ofen, weil sie sonst von der Heißluft-Lötstation weggeweht wird?
Nicht notwendigerweise, die Schablone ist nur für das Dispensen da. Man muss halt aufpassen, dass man nicht zu sehr von der Seite bläst.
Zitat von: Kai-Alfonso am 18 Oktober 2019, 13:49:35
Wie sehen denn solche Schablonen aus?
Siehe hier (https://www.pcb-supermarkt.de/media/image/1d/06/95/smd_eco.jpg).
Gruß Peter
Zitat von: PeMue am 18 Oktober 2019, 14:01:03
Nicht notwendigerweise, die Schablone ist nur für das Dispensen da. Man muss halt aufpassen, dass man nicht zu sehr von der Seite bläst.
Siehe hier (https://www.pcb-supermarkt.de/media/image/1d/06/95/smd_eco.jpg).
Gruß Peter
Verstehe, ich glaube ich würde es mal versuchen. Eine ruhige Hand habe ich, ich bräuchte noch eine bessere Lupe. Hast du einen Einkaufstipp für die Schablone
Moin
Ich dachte die bestellt man mit der Platine mit!?
Gruss Christoph
ja, bestellt man mit der Platine. Bei jlcpcb kostet das dann ab 7$ extra.
Zitat von: pc1246 am 18 Oktober 2019, 18:07:28
Moin
Ich dachte die bestellt man mit der Platine mit!?
Gruss Christoph
Nah nochmal drüber nachdenken macht ja eine universale Schablone keinen Sinn bzw. Kann gar nicht funktionieren
Zitat von: Kai-Alfonso am 19 Oktober 2019, 12:24:18
Nach nochmal drüber nachdenken macht ja eine universale Schablone keinen Sinn bzw. kann gar nicht funktionieren
Das gilt nicht pauschal. Ich habe eine Schablone für das LaCrosse Gateway, dispense aber auch den BME680 auf andere Platinen (aber eben dann auch nur diesen).
Gruß Peter
Guten Morgen,
ich habe hier einen Uni-Sensor, der mag unter keinen Umständen funken. Jedenfalls sehe ich keine Homematic Telegramme im CUL mit Verbose 4. Evtl CC1101 kaputt? Sehe ich das in der Serial Console?
Als Bootloader habe ich den OTA Boatloader genommen (makeota.html). Der Startvorgang sieht wie folgt aus:
08:12:15.457 -> AskSin++ V3.1.1 (Nov 5 2019 07:49:17)
08:12:15.457 -> BME280 found
08:12:15.457 -> Sensor setup done
08:12:15.457 -> Serial: UNISENS010
08:12:15.457 -> Clock SYSCLOCK
08:12:15.457 -> Address Space: 32 - 79
08:12:15.491 -> CC init1
08:12:15.491 -> CC Version: 14
08:12:15.491 -> - ready
08:12:15.696 -> tmBatteryLoad Voltage: 3712
08:12:15.696 -> Battery set low: 21
08:12:15.696 -> Battery set crit: 19
08:12:15.730 -> Config Changed: List0
08:12:15.730 -> ledMode: 1
08:12:15.730 -> lowBatLimit: 21
08:12:15.730 -> Battery set low: 21
08:12:15.730 -> transmitDevTryMax: 6
08:12:15.730 -> updCycle: 600
08:12:15.730 -> altitude: 0
08:12:20.526 -> BME280 Temperature x10 : 303
08:12:20.526 -> BME280 Pressure x10 : 9832
08:12:20.562 -> BME280 PressureNN x10 : 9832
08:12:20.562 -> BME280 Humidity : 74
08:12:20.595 -> <- 17 01 84 70 84E0C6 000000 01 2F 26 68 4A 00 86 47 00 00 0E 80 00 00 - 344
Hab auch schon die Lötstellen des Funkmoduls auf Konnectivität/Kurzschluss überprüft. An C12 habe ich einen 1µF Kondensator genommen, R9 ist 100kOhm (laut Aussensensor_v1.5_sch.pdf von PeMue)
Ich vermute ja, das
08:12:15.491 -> CC init1
08:12:15.491 -> CC Version: 14
08:12:15.491 -> - ready
die erfolgreiche Initialisierung ist. Ist das korrekt?
Ich bin grad auf der Arbeit und es kann natürlich sein, das meine CUL hier defekt ist, also muss ich das zu Hause auch noch mal testen mit meinen MHUART.
Noch eine kurze Frage:
Im Serial Log steht
08:12:15.457 -> Serial: UNISENS010
obwohl ich die Serial per OTA Bootloader vorgebe. Ist das eine Standard-Meldung, die sowieso kommt, auch wenn der Serial/ID vom Bootloader kommt?
Vielen Dank und liebe Grüße
Wenn die Serial und die HMID aus dem Bootloader genommen werden sollen, muss der Code auch mit dem Define USE_OTA_BOOTLOADER übersetzt sein. Stimmt denn die HMID 84E0C6 ?
Zitat von: papa am 05 November 2019, 09:30:55
Wenn die Serial und die HMID aus dem Bootloader genommen werden sollen, muss der Code auch mit dem Define USE_OTA_BOOTLOADER übersetzt sein. Stimmt denn die HMID 84E0C6 ?
ach, gar nicht gesehen dort unten. Ja, die HMID stimmt, bin auch nicht davon ausgegangen, das der den OTA Bootloader nicht lädt. Ich weiß es nicht, meine aber, der normale Bootloader blinkt auch nicht 7 mal beim booten.
Ok, aber das erklärt nicht mein Problem, das ich kein Funk sehe :-\
alle Lötpunkte sehen eigentlich gut aus...
Zitat von: Kai-Alfonso am 05 November 2019, 10:20:06
...
Ok, aber das erklärt nicht mein Problem, das ich kein Funk sehe :-\
alle Lötpunkte sehen eigentlich gut aus...
Dein Problem wird wohl im CC1101 Funkmodul liegen: https://forum.fhem.de/index.php?topic=91740.0
Zitat von: gloob am 05 November 2019, 10:23:46
Dein Problem wird wohl im CC1101 Funkmodul liegen: https://forum.fhem.de/index.php?topic=91740.0
Hm, hatte ich auch schon dran gedacht, weil mir das, was Du mir geschickt hast, auch gelesen habe. Aber ich meine, das ich schon Module aus der Bestellung erfolgreich als Sensor betreibe.
Wenn ich das mal Vergleiche mit dem Test von dartrax hier:
https://forum.fhem.de/index.php/topic,91740.msg843102.html#msg843102
habe ich das mittlere Modul, was gehen sollte
Was sagt denn der Frequenz-Test Sketch?
Zitat von: gloob am 05 November 2019, 10:34:23
Was sagt denn der Frequenz-Test Sketch?
Wo finde ich den?
Zitat von: Kai-Alfonso am 05 November 2019, 10:39:12
Wo finde ich den?
https://github.com/pa-pa/AskSinPP/tree/master/examples/FreqTest
Zitat von: gloob am 05 November 2019, 10:41:34
https://github.com/pa-pa/AskSinPP/tree/master/examples/FreqTest
Danke, werde ich mal eben flashen 8)
Siehe auch https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html
Zitat von: papa am 05 November 2019, 11:09:38
Siehe auch https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html
Danke für die Info - ich habe hier auf der Arbeit momentan keine anderen HM Devices, nur eine CUL die folgendes liefert:
ccconf
freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dBich vermute, das mir das passive Verhalten des Sketches nix hilft, oder? Und Aktive Ping kann ich auch nicht nutzen, weil ich zwar die HMID der Zentrale (=Cul) habe, aber kein gepairtes Device?
Hi und guten Morgen,
wollte mich nur zurückmelden. Mit einem anderen Modul der gleichen Lieferung geht es nun. 8)
Hallo Tom,
hättest Du mir bitte für den Q1 (https://github.com/TomMajor/SmartHome/tree/master/PCB/01_Sensor_PLHT_V2.01) Deines Außensensors v2.01 einen passenden 32 kHz Quarz?
Ich habe welche gesucht, bin aber nicht fündig geworden.
Danke + Gruß
Peter
dir ist klar dass die Pads auf der Platine eigentlich für den 8MHz Resonator sind?
https://www.reichelt.de/smd-resonator-8-00-mhz-groesse-3-2x1-3x0-9mm-cstce-8-00-p89701.html (https://www.reichelt.de/smd-resonator-8-00-mhz-groesse-3-2x1-3x0-9mm-cstce-8-00-p89701.html)
Ein Uhrenquarz lässt sich natürlich immer auflöten wenn man den RTC mode nutzen will.
Diese sind ziemlicher Standard und gibts überall.
Ich habe diese
https://de.farnell.com/abracon/ab26t-32-768khz/crystal-32-768khz-12-5pf-cylinder/dp/2467704 (https://de.farnell.com/abracon/ab26t-32-768khz/crystal-32-768khz-12-5pf-cylinder/dp/2467704)
Das wäre ein ähnlicher von Reichelt
https://www.reichelt.de/standardquarz-grundton-32-768-khz-iqd-lfxtal002997-p245393.html
2x C gegen Masse bei 12,5pF CL (meine beiden links) erforderlich.
Wenn du einem mit ca. 6pF CL bekommst kannst du auf die 2x C verzichten
https://de.farnell.com/citizen-finedevice/cfs206-32-768kdzb-ub/quarz-uhr-32-768khz-zylinder-6pf/dp/1457085 (https://de.farnell.com/citizen-finedevice/cfs206-32-768kdzb-ub/quarz-uhr-32-768khz-zylinder-6pf/dp/1457085)
Guten Morgen,
ich muss es noch mal gegenprüfen, ob es nur am Funkmodul liegt (also das Gerät selber noch an ist) oder am Gerät selber. Aber welchen Grund kann es haben, das mein Aussensensor bei Kälte nachts die Grätsche macht (=er schickt keine Daten mehr) und morgens dann wieder normal weiterfunkt? Da ist jetzt schon den dritten Abend passiert zu unterschiedlichen Uhrzeiten/Temperaturen. Er schickt dann über mehrere Stunden keine Daten und morgens geht es dann weiter
Oder kann es ein Batterieproblem sein? (keine Akkus, Varta Ultra Lithium)
Hallo Tom,
Zitat von: Tom Major am 10 November 2019, 21:06:03
dir ist klar dass die Pads auf der Platine eigentlich für den 8MHz Resonator sind?
https://www.reichelt.de/smd-resonator-8-00-mhz-groesse-3-2x1-3x0-9mm-cstce-8-00-p89701.html (https://www.reichelt.de/smd-resonator-8-00-mhz-groesse-3-2x1-3x0-9mm-cstce-8-00-p89701.html)
ist mir klar. Ich dachte nur, dass es auch (baugleiche) 32 kHz Quarze in SMD gibt, aber ich habe nur zweipolige gefunden. Aber die bedrahteten (und die zwei Kondensatoren) müssten sich auch auflöten lassen.
Danke + Gruß
Peter
Zitat von: PeMue am 11 November 2019, 10:40:53
Hallo Tom,
ist mir klar. Ich dachte nur, dass es auch (baugleiche) 32 kHz Quarze in SMD gibt, aber ich habe nur zweipolige gefunden. Aber die bedrahteten (und die zwei Kondensatoren) müssten sich auch auflöten lassen.
Danke + Gruß
Peter
Hi Peter,
verstehe dich, kann dir aber keinen genau passenden SMD für 32k nennen. Hatte schon mal früher danach gesucht, ist aber zu lange her, weiß keine Details mehr.
Btw, hatte es auch heute im orangen Forum gepostet, der oben verlinkte CSTCE 8,00 ist End Of Life.
Bei Reichelt gibt es noch Restbestände.
Ersatztyp wäre z.B. der CSTNE8M00G550000R0 , momentan aber nicht bei Reichelt.
Production Start Date : 2/1/2001
Last Time Buy Date : 9/30/2019
Date of Discontinuation : 3/31/2020
Hallo zusammen,
ich hätte aktuell Bedarf an einem HM-WDS den ich mit einem HM-CC-RT-DN peeren kann. Hardware hätte ich ne HMSensor und BME280, nun ein paar Verständnis-fragen:
* Wenn ich die HMSensor mit 32kHz Quarz bestücke, passen dann die Timings für den Heizkörperthermostat?
* Wie erkenne ich, dass die Temperaturen richtig übertragen werden? Wie "monitored" man nen RT? (PS: RaspiMatic User)
* Gibt es in diesem Kontext Unterschiede zwischen WDS40 und WDS10? Sind ja beide _THSensor_ Typen.
Ich hätte folgenden Sketch versucht (nicht getestet):
//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------
// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER
#define EXTRAMILLIS 730 // 730 millisecond extra time to better hit the slot
#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>
#include <Register.h>
#include <MultiChannelDevice.h>
#include <Weather.h>
#include <sensors/Bme280.h>
// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8
//Einstellbarer OFFSET für Temperatur -> gemessene Temp +/- Offset = Angezeigte Temp.
#define OFFSETtemp 0 //z.B -50 ≙ -5°C / 50 ≙ +5°C
//Einstellbarer OFFSET für Luftfeuchte -> gemessene Luftf. +/- Offset = Angezeigte Luftf.
#define OFFSEThumi 0 //z.B -10 ≙ -10%RF / 10 ≙ +10%RF
// number of available peers per channel
#define PEERS_PER_CHANNEL 6
// all library classes are placed in the namespace 'as'
using namespace as;
// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
{0x34,0x56,0x79}, // Device ID
"papa111111", // Device Serial
{0x00,0x3f}, // Device Model: HM-WDS40-TH-I
0x10, // Firmware Version
as::DeviceType::THSensor, // Device Type
{0x01,0x00} // Info Bytes
};
/**
* Configure the used hardware
*/
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef StatusLed<LED_PIN> LedType;
typedef BatterySensorUni<17,7,3000> BatteryType; // External battery measurement
typedef AskSinRTC<LedType,BatteryType,RadioType> Hal;
/*
* Define List0 registers
*/
DEFREGISTER(WeatherRegsList0,MASTERID_REGS,DREG_BURSTRX)
typedef RegList0<WeatherRegsList0> WeatherList0;
/*
* Sensors class is used by the WeatherChannel to measure the data. It has to implement
* temperature() and humidity().
*/
class Sensors : public Alarm {
Bme280 bme280;
public:
Sensors () {}
// init the used hardware
void init () { bme280.init(); }
// return how many milliseconds the measure should start in front of sending the message
uint16_t before () const { return 4000; }
// get the data
virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
DPRINTLN("Measure... ");
bme280.measure();
DPRINT("T: ");DDEC(bme280.temperature()+OFFSETtemp);DPRINT(" H: ");DDECLN(bme280.humidity()+OFFSEThumi);
}
uint16_t temperature () { return bme280.temperature()+OFFSETtemp; }
uint8_t humidity () { return bme280.humidity()+OFFSEThumi; }
};
typedef WeatherChannel<Hal,RTC,Sensors,PEERS_PER_CHANNEL,EXTRAMILLIS,WeatherList0> ChannelType;
typedef MultiChannelDevice<Hal,ChannelType,1,WeatherList0> WeatherType;
Hal hal;
WeatherType sdev(devinfo,0x20);
ConfigButton<WeatherType> cfgBtn(sdev);
void setup () {
DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
sdev.init(hal);
buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
// Measure Battery every 1h; warn 2V, critical 1V (TLV61224 StepUp can handle 0.7V)
hal.initBattery(60UL*60,20,10);
sdev.initDone();
DDEVINFO(sdev);
}
void loop() {
bool worked = hal.runready();
bool poll = sdev.pollRadio();
if( worked == false && poll == false ) {
if( hal.battery.critical() ) {
// this call will never return
hal.activity.sleepForever(hal);
}
hal.sleep<>();
}
}
Gerne auch noch weitere Kommentare und Ideen, ich würde das ganze gerne in eine Projektbeschreibung gießen und veröffentlichen.
=== edit ===
Ich hab den Sketch geflashed und eine Direktverknüpfung mit dem Heizkörper gemacht. Mal sehen was der Analyzer so verrät.
=== edit #2 ===
Sketch für externe Batteriemessung angepasst.
Mir fällt dazu nur ein, die Timings sind in diesem Fall kritisch, 32kHz Quarz ist ein Muss (gegenüber dem wakeup per WDT).
papa hatte dazu neulich auch einen Fix bzgl. der Timings in der AskSinPP gemacht.
Und es gab einen FHEM user der den HB-UNI-Sensor1 mit SHT31 nach einigen Adaptionen mit den Timings erfolgreich an einem RT betreiben konnte, user Name weiß ich aber gerade nicht mehr.
Die Frage für mich ist aktuell wie ich die Funktionalität verifizieren kann. Bislang gibt es nur die Idee die Telegramme per Analyzer zu sichten. Gibt es noch weitere Ansatzpunkt?
So, ich hab den Sensor kurzerhand in den Kühlschrank gepackt und siehe da es funktioniert.
Der HM-CC-RT-DN zeigt in der CCU die Temperatur vom WDS40 an.
Zitat von: Psi am 18 November 2019, 10:40:56
So, ich hab den Sensor kurzerhand in den Kühlschrank gepackt und siehe da es funktioniert.
Der HM-CC-RT-DN zeigt in der CCU die Temperatur vom WDS40 an.
Man muß sich den Trendplot über einige Tage ansehen, um zu erkennen, wie oft es Aussetzer gibt, wenn die Synchronisierung verloren geht. Dazu stellt man im RT-DN eine genügend große Temperaturdifferenz von -3 K o.ä. ein. Dann erkennt man die Einbrüche gut, wenn er auf den internen Sensor umschaltet. Das sollte man allerdings im Sommer machen, da er im Heizungsbetrieb bei solchen Sprüngen ziemlich rumrödelt.
Der User, den Tom meinte, bin ich.
Zitat von: Gernott am 19 November 2019, 22:51:30
Man muß sich den Trendplot über einige Tage ansehen, um zu erkennen, wie oft es Aussetzer gibt, wenn die Synchronisierung verloren geht. Dazu stellt man im RT-DN eine genügend große Temperaturdifferenz von -3 K o.ä. ein. Dann erkennt man die Einbrüche gut, wenn er auf den internen Sensor umschaltet. Das sollte man allerdings im Sommer machen, da er im Heizungsbetrieb bei solchen Sprüngen ziemlich rumrödelt.
Danke für den Tipp, allerdings hab ich in der CCU (bin RaspiMatic User) keine Einstellung für Temperaturdifferenz gefunden. Mir ist aber aber auch schon aufgefallen, dass ab und an der Wert des Sensors und der Wert des RT-DN nicht ganz übereinstimmen.
Zitat von: Psi am 19 November 2019, 23:00:48
Mir ist aber aber auch schon aufgefallen, dass ab und an der Wert des Sensors und der Wert des RT-DN nicht ganz übereinstimmen.
Im FHEM-Plot sieht das dann so aus wie hier: https://forum.fhem.de/index.php/topic,20620.msg964184.html#msg964184
Hey Gernott,
sorry das mir der Name entfallen war :(
Läuft das Timing mit den Sensor -> RT jetzt eigentlich stabil?
@Psi
Ich glaube dieses Offset ist gemeint:
14.5 Offset-Temperatur einstellen (tOF)
Da die Temperatur am Heizkörper gemessen wird,
kann es an einer anderen Stelle im Raum kälter oder
wärmer sein. Um dies anzugleichen, kann ein Temperatur-Offset von ±3.5°C eingestellt werden. Werden
z.B. 18°C anstatt eingestellter 20°C gemessen, ist ein
Offset von -2.0°C einzustellen. Die Offset-Temperatur
können Sie individuell anpassen.
Werksseitig ist eine Offset-Temperatur von 0.0° eingestellt.
• Drücken Sie die Auto/Manu-Taste ( ) länger als 3
Sekunden.
• Wählen Sie mit dem Stellrad den Menüpunkt ,,tOF"
aus und bestätigen Sie mit der Boost-Taste ( ).
• Drehen Sie das Stellrad so lange, bis die gewünschte Temperatur erscheint (max. ±3.5°C).
• Bestätigen Sie mit der Boost-Taste ( ).
Ahh okay, ich dachte das wird über die CCU eingestellt. Danke Tom!
Plotten ist kein Problem, hab Grafana am laufen. Die letzten 24h sehen auch recht gut aus.
Zitat von: Psi am 19 November 2019, 23:41:42
Ahh okay, ich dachte das wird über die CCU eingestellt. Danke Tom!
Plotten ist kein Problem, hab Grafana am laufen. Die letzten 24h sehen auch recht gut aus.
Müsste das nicht in RM über das DevConfig Tool auch direkt einstellbar sein?
Zitat von: Tom Major am 19 November 2019, 23:25:13
Hey Gernott,
sorry das mir der Name entfallen war :(
Läuft das Timing mit den Sensor -> RT jetzt eigentlich stabil?
Macht nichts, ich kenne das auch, ist das Alter...
Für mich läuft er stabil genug. Es kommt unregelmäßig alle paar Tage mal zu einem kurzen Aussetzer, aber damit kann ich leben.
Zitat von: Gernott am 19 November 2019, 23:48:25
Macht nichts, ich kenne das auch, ist das Alter...
Für mich läuft er stabil genug. Es kommt unregelmäßig alle paar Tage mal zu einem kurzen Aussetzer, aber damit kann ich leben.
Das klingt ja nicht schlecht. Ich würde vermuten dass auch die Originalgeräte mal einen Aussetzer haben, das Zeitfenster ist klein.
Hallo zusammen, vielleicht kann mir jemand auf die Sprünge helfen: Ich würde gerne den WDS40 Example Sketch mit der Batteriespannungsmessung unter Last von Tom Major (30/10R) nutzen (Versorgung direkt an 2xAA ohne Stepup Wandler).
Kann die BatterySensor.h genutzt werden (falls ja, wie würde die typedef aussehen?), oder müsste die tmBattery.h eingebunden werden?
Vielen Dank vorab an alle, die diese genialen Nachbauten ermöglichen :D
Zitat von: Andre27 am 03 Dezember 2019, 21:24:59
Hallo zusammen, vielleicht kann mir jemand auf die Sprünge helfen: Ich würde gerne den WDS40 Example Sketch mit der Batteriespannungsmessung unter Last von Tom Major (30/10R) nutzen (Versorgung direkt an 2xAA ohne Stepup Wandler).
Kann die BatterySensor.h genutzt werden (falls ja, wie würde die typedef aussehen?), oder müsste die tmBattery.h eingebunden werden?
Vielen Dank vorab an alle, die diese genialen Nachbauten ermöglichen :D
Bin nicht sicher, ich glaube ? stan23 hatte mal was in der Richtung bei BatterySensor.h gemacht, sehe es aber auf die Schnelle nicht im code.
tmBattery.h zu verwenden müsste auch gehen, eventuell muss du dort den Messwert durch 100 teilen da bei vielen Geräten die 100mV Auflösung verwendet wird.
Danke, ich habe versucht die tmBattery.h einzubinden - der Compiler wirft dann jede Menge Fehler bzgl setIdle/unsetIdle, Auszug:
error: 'as::AskSin<as::DualStatusLed<5, 4>, as::tmBatteryLoad<14, 9, 4000, 200>, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2>, as::NoBuzzer>::BatteryType {aka class as::tmBatteryLoad<14, 9, 4000, 200>}' has no member named 'setIdle'
Leider reichen meine Programmierkenntnisse hier nicht mehr so ganz aus, um zu verstehen, wie es weiter geht... :-\
Das ist neu - damit wird angezeigt, ob das System gerade was macht oder nicht. Einfach leer implementieren.
void setIdle () {}
void unsetIdle () {}
Perfekt - danke euch, damit läuft's ;D Spannung passt auch. Dann werde ich mich jetzt auch mal ans Testen in Verbindung mit dem HM-CC-RT-DN machen.
Moin Moin!
Ich habe seit 01.12. zwei PIRs basierend auf der großen Universalsensorplatine am laufen - so weit, so gut... Nun ist letzte Nacht der erste mit Batteriewarnung gekommen, also nach knapp über einem Monat - mit etwas über 18T Auslösungen (ich lasse einen Counter mitlaufen). Und - Ich habe schon darauf gewartet, wann der erste aussteigt.
Um hier die Laufzeit zu vergrößern, würde ich die Sensoren gern deaktivieren und das Senden / Auslösen nur aktiv schalten, wenn die Alarmanlage aktiviert wird. Ich habe gelesen - die original HMIP Teile können das wohl inzwischen? Habt ihr schon einmal darüber nachgedacht - also die Universalsensoren deaktivieren und wieder aktivieren - und, könnte man das in der Firmware implementieren?
... fragt sich der
Peter
@Tom Major
Angelehnt an die HB-UNI-Sensor1 PIR-Schaltung (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#bewegungsmelder-mit-pir-as312-am-digitalen-eingang), ist aus einem "arbeitslosen" panStamp AVR 2 (https://github.com/panStamp/panstamp/wiki/panStamp-AVR-2.-Technical-details) eine HB-UNI-Sensor1 KSE (Klingelsignalerkennung) entstanden. Ich habe die PIR-Schaltung durch einen Optokoppler ersetzt und im Arduino Sketch ausschließlich #define SENSOR_DIGINPUT aktiviert. Das Senden von Funktelegrammen unabhängig vom eingestellten Sendeintervall funktioniert sehr zuverlässig.
Allerdings wird häufig nach dem Interrupt bedingten Senden das Reading digitalInput nicht auf 1 zurückgesetzt. digitalInput 0 bleibt bis zum nächsten regulären WakeUp/Sendeintervall erhalten. Das Ganze unabhängig davon, ob der RTC oder SYSCLOCK verwendet wird.
Ein Notify, das auf event-on-change-reading digitalInput triggert, kann in dem Zeitraum bis zu der voraussichtlichen Zustandsänderung durch das reguläre Sendeintervall keine Aktionen auslösen.
Wie habt ihr das beim PIR-Sensor gelöst?
Zitat von: locutus am 07 Juli 2020, 21:54:48
Wie habt ihr das beim PIR-Sensor gelöst?
Mit dem HM-SEC-MDIR.ino Sketch.
Zitat von: locutus am 07 Juli 2020, 21:54:48
@Tom Major
Angelehnt an die HB-UNI-Sensor1 PIR-Schaltung (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#bewegungsmelder-mit-pir-as312-am-digitalen-eingang), ist aus einem "arbeitslosen" panStamp AVR 2 (https://github.com/panStamp/panstamp/wiki/panStamp-AVR-2.-Technical-details) eine HB-UNI-Sensor1 KSE (Klingelsignalerkennung) entstanden. Ich habe die PIR-Schaltung durch einen Optokoppler ersetzt und im Arduino Sketch ausschließlich #define SENSOR_DIGINPUT aktiviert. Das Senden von Funktelegrammen unabhängig vom eingestellten Sendeintervall funktioniert sehr zuverlässig.
Allerdings wird häufig nach dem Interrupt bedingten Senden das Reading digitalInput nicht auf 1 zurückgesetzt. digitalInput 0 bleibt bis zum nächsten regulären WakeUp/Sendeintervall erhalten. Das Ganze unabhängig davon, ob der RTC oder SYSCLOCK verwendet wird.
Hmm, verstehe ich nicht ganz. Das Feature SENSOR_DIGINPUT sollte bei jeder Änderung ein neues Telegramm an die Zentrale absetzen.
Das kann man im seriellen Debug Log des Gerätes prüfen, einer der hinteren Bytes in der payload ist entweder 0 oder 1 je nach Status des DIGINPUT.
Dann würde ich auch erwarten das FHEM Reading diesen Zustand immer korrekt anzeigt wenn das Telegramm rausgegangen ist.
Das ist aber nicht der Fall. Ob analog oder digital Pin, mit oder ohne Pull-Up Widerstand und trotz Statusänderung, die 0 wird sporadisch beibehalten:
DIGINPUT change
DS18x20 Temperature : 215
<- 17 10 84 70 A5A502 000000 00 D7 2A 80 58 00 86 47 00 01 0D 1D 00 00 - 21053
DIGINPUT change
DS18x20 Temperature : 215
<- 17 11 84 70 A5A502 000000 00 D7 2A 80 58 00 86 47 00 01 0D 1D 00 00 - 22366
DIGINPUT change
DS18x20 Temperature : 215
<- 17 12 84 70 A5A502 000000 00 D7 2A 80 58 00 86 47 00 00 0D 1D 00 00 - 23678
DIGINPUT change
DS18x20 Temperature : 215
<- 17 13 84 70 A5A502 000000 00 D7 2A 80 58 00 86 47 00 01 0D 1D 00 00 - 24991
DIGINPUT change
DS18x20 Temperature : 215
<- 17 14 84 70 A5A502 000000 00 D7 2A 80 58 00 86 47 00 00 0D 1D 00 00 - 26304Zitat von: Gernott am 07 Juli 2020, 22:39:38
Mit dem HM-SEC-MDIR.ino Sketch.
Danke für den Tipp! Der HM-Sen-DB-PCB.ino (https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/HM-Sen-DB-PCB/HM-Sen-DB-PCB.ino) Sketch ist auf den panStamp wie zugeschnitten.
Anpassungen für panStamp AVR2:
...
#define LED_PIN 9
...
#define CLOCK rtc
...
rtc.init();
...
hal.activity.savePower<SleepRTC>(hal);
...
Mit RTC beträgt der Ruhestrom ca. 1,5 µA.
Hallo zusammen,
ich versuche nun schon ein paar Stunden den Bootloader per Arduino UNO als ISP auf den ATMEGA328P zu flashen. Leider ohne Erfolg. Die Verkabelung ist in Ordnung, einen normalen Nano bekomme ich geflasht.
Ich hoffe, ihr habt einen Tipp für mich?
Viele Grüße
Frank
Zitat von: Bastel-Frank am 03 August 2020, 14:53:21
Ich hoffe, ihr habt einen Tipp für mich?
Ich hätte viele. Wäre aber eine Lotterie, wenn Du nicht etwas genauer ausführst, was Du gemacht hast und was Dein Flashprogramm dabei so meldet.
Ich nutze die aktuelle Arduino IDE (habe aber auch direkt mit avrdude versucht). Ein UNO ist als ISP programmiert und anschließend habe ich den Nano mit dem ATmega328P gewählt.
Die Meldungen der IDE sehen so aus ...
avrdude: Version 6.3-20190619
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : COM7
Using Programmer : stk500v1
Overriding Baud Rate : 19200
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x000000 (retrying)
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x000000 (retrying)
Fehler beim Brennen des Bootloaders.
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
Für mich auffällig ist, dass als Device Signature 0x000000 gemeldet wird. Beim ersten Versuch den Bootloader zur programmieren wurde eine andere Device Signature gemeldet.
Zitat von: Bastel-Frank am 03 August 2020, 16:43:36
Für mich auffällig ist, dass als Device Signature 0x000000 gemeldet wird. Beim ersten Versuch den Bootloader zur programmieren wurde eine andere Device Signature gemeldet.
Das klingt nicht gut. Der Atmega wird nicht mehr erkannt und damit nicht geflasht. Wenn er beim ersten Mal noch ansprechbar war, sind die Lötstellen vermutlich in Ordnung. Es gibt eine Methode, einen Atmega wiederzuerwecken, braucht aber eine spezielle Schaltung. Ich hatte eine solchen Fall und habe dann den Atmega ausgewechselt. Die Teile kosten nicht die Welt und mit Heißluft ist er schnell runter.
Ich hatte bei jungfräulichen Atmega 328 P noch den Takt des ISP-Programmers runtersetzen müssen ( avrdude -B 20), da es mit dem Standardtakt zu Fehlern kam.
Zitat von: Gernott am 03 August 2020, 20:45:02
Es gibt eine Methode, einen Atmega wiederzuerwecken, braucht aber eine spezielle Schaltung.
Wie sieht diese Schaltung aus?
Was ist von solchen Programmern zu halten? https://www.ebay.de/itm/USB-ISP-USBASP-AVR-Programmer-Adapter-mit-10-Pin-Kabel-auf-6-Pin-Arduino/114325171441?hash=item1a9e4facf1:g:bBwAAOSwgaxec55t
Zitat von: Bastel-Frank am 04 August 2020, 07:55:40
Wie sieht diese Schaltung aus?
Suche mal im Netz nach "High Voltage Programming". Damit kann man einen verfusten Atmega programmieren. Ich würde aber erstmal einen neuen auflöten und nochmal testen.
Ich habe eine neue Platine mit neuen Bauteilen bestückt. Beim Auslesen der Fuses kommt diese Meldung avrdude: Device signature = 0x1e9406
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
Dies bedeutet, dass sich anscheinend die Device Signature geändert hat. Wenn ich in der avrdude.conf die Device Signature auf 1E 94 06 töte ich den 328P (Bauart TQFP) anscheinend, danach ist er nicht mehr ansprechbar. Kann es sein, dass mit der Standard-Bootloader (ATmegaBOOT_168_atmega328_pro_8MHz.hex) dazu nicht kompatible ist?
PS: Laut Aliexpress hat dieser Chip 20Mhz (https://de.aliexpress.com/item/4000064299962.html?spm=a2g0o.productlist.0.0.372273a8snIhQe&algo_pvid=6eb42ce9-89bd-439e-adc5-5ad0073360b9&algo_expid=6eb42ce9-89bd-439e-adc5-5ad0073360b9-1&btsid=0be3769015965304902233793eb238&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_)
Zitat von: Bastel-Frank am 04 August 2020, 10:40:36
Ich habe eine neue Platine mit neuen Bauteilen bestückt. Beim Auslesen der Fuses kommt diese Meldung avrdude: Device signature = 0x1e9406
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
Dies bedeutet, dass sich anscheinend die Device Signature geändert hat. Wenn ich in der avrdude.conf die Device Signature auf 1E 94 06 töte ich den 328P (Bauart TQFP) anscheinend, danach ist er nicht mehr ansprechbar. Kann es sein, dass mit der Standard-Bootloader (ATmegaBOOT_168_atmega328_pro_8MHz.hex) dazu nicht kompatible ist?
Um hier weiterzuhelfen, woher hast du die FuseBits? Sind diese korrekt? Beschreibe mal welche Quelle du nutzt und was du genau machst, Schritt für Schritt.
HV-Programmer ... falls Interesse, damit habe ich schon mehrere Chips gerettet.
https://www.instructables.com/id/HV-Rescue-Simple/
(https://www.instructables.com/id/HV-Rescue-Simple/)
Zitat von: Bastel-Frank am 04 August 2020, 10:40:36
Wenn ich in der avrdude.conf die Device Signature auf 1E 94 06 töte ich den 328P (Bauart TQFP) anscheinend, danach ist er nicht mehr ansprechbar.
Fuse 1E .... ext. Crypstal Osc.; Frequency 8.0- Mhz; ....
--> hast du den Quarz richtig angeschlossen mit 2 Kondensatoren und Widerstand?
Huhu, ich hab noch eine alte Version bei mir gefunden, die ich jetzt mal noch mal nutzen wollte.
Hier ist ein Listing des Devices - wie ihr seht, ist es gepaired mit der Zentrale und liefert Daten wie erwartet:
nternals:
.triggerUsed 1
CFGFN
DEF A9C06F
FUUID 5f410589-f33f-ce3b-2240-3cf4e26d70a0c9d7
HMUART_EG_MSGCNT 27
HMUART_EG_RAWMSG 0501004566A270A9C06F0B98D00137002762000208030D48
HMUART_EG_RSSI -69
HMUART_EG_TIME 2020-08-22 13:51:08
HMUART_OG_MSGCNT 51
HMUART_OG_RAWMSG 0500003966A270A9C06F0B98D00137002762000208030D48
HMUART_OG_RSSI -57
HMUART_OG_TIME 2020-08-22 13:51:08
IODev HMUART_EG
LASTInputDev HMUART_OG
MSGCNT 78
NAME HM_A9C06F
NOTIFYDEV global
NR 4110
STATE T: 31.1 L: 1331 P: 1008.2 P-NN: 1015.0
TYPE CUL_HM
chanNo 01
lastMsg No:66 - t:70 s:A9C06F d:0B98D0 0137002762000208030D48
protCmdDel 6
protLastRcv 2020-08-22 13:51:08
protRcv 35 last_at:2020-08-22 13:51:08
protResnd 8 last_at:2020-08-22 13:51:12
protResndFail 1 last_at:2020-08-22 13:46:54
protSnd 67 last_at:2020-08-22 13:51:08
protState CMDs_pending
rssi_at_HMUART_EG cnt:28 min:-81 max:-69 avg:-76.07 lst:-69
rssi_at_HMUART_OG cnt:51 min:-75 max:-57 avg:-64.74 lst:-57
.attraggr:
.attrminint:
READINGS:
2020-08-22 13:48:19 .D-devInfo 030100
2020-08-22 13:48:19 .D-stc 70
2020-08-22 13:46:23 .R-altitude 0 m
2020-08-22 13:46:23 .R-burstRx off
2020-08-22 13:46:23 .R-ledMode undef lit:1
2020-08-22 13:46:23 .R-lowBatLimitTHPL 1.6 V
2020-08-22 13:46:23 .R-pairCentral 0x0B98D0
2020-08-22 13:46:23 .R-transmDevTryMax 3
2020-08-22 13:48:24 .associatedWith HM_A9C06F,HM_A9C06F
2020-08-22 13:47:32 .peerListRDate 2020-08-22 13:47:32
2020-08-22 13:51:08 .protLastRcv 20200822135108
2020-08-22 13:46:18 CommandAccepted yes
2020-08-22 13:48:19 D-firmware 0.15
2020-08-22 13:48:19 D-serialNr UJI4498487
2020-08-22 13:47:24 PairedTo 0x0B98D0
2020-08-22 13:47:24 RegL_00. 00:00 01:00 05:64 0A:0B 0B:98 0C:D0 12:10 14:03 24:00 25:00
2020-08-22 13:51:08 batVoltage 3.40
2020-08-22 13:51:08 battery ok
2020-08-22 13:48:24 cfgState ok
2020-08-22 13:51:12 commState CMDs_pending
2020-08-22 13:51:08 luminosity 1331
2020-08-22 13:51:08 pressure 1008.2
2020-08-22 13:51:08 pressure-nn 1015.0
2020-08-22 13:48:20 recentStateType info
2020-08-22 13:51:08 state T: 31.1 L: 1331 P: 1008.2 P-NN: 1015.0
2020-08-22 13:51:08 temperature 31.1
cmdStack:
++A0010B98D0A9C06F010E
helper:
HM_CMDNR 103
cSnd 010B98D0A9C06F010E,010B98D0A9C06F010E
mId F102
peerFriend peerRecT
peerIDsRaw ,00000000
peerOpt p:THPLSensor
regLst 0
rxType 156
supp_Pair_Rep 0
ack:
cmds:
TmplKey :no:1598096904.88233
TmplTs 1598096904.88233
cmdKey 1:1:0::HM_A9C06F:F102:01:
cmdLst:
assignHmKey noArg
burstXmit noArg
clear [readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
deviceRename newName
fwUpdate <filename> <bootTime> ...
getConfig noArg
getDevInfo noArg
getRegRaw [List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
getSerial noArg
getVersion noArg
peerBulk -peer1,peer2,...- [set|unset]
peerChan 0 <actChn> ... single [set|unset] [actor|remote|both]
peerSmart -peerOpt-
raw data ...
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2- ...
regSet [prep|exec] -regName- -value- ... [-peerChannel-]
reset noArg
statusRequest noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt Thermostat_Schlafzimmer_Weather
tplChan
tplDel
tplPeer
expert:
def 0
det 0
raw 1
tpl 0
io:
newChn +A9C06F,02,00,00
nextSend 1598097069.03096
prefIO
rxt 2
vccu
p:
A9C06F
00
00
00
mRssi:
mNo 66
io:
HMUART_EG:
-65
-65
HMUART_OG:
-57
-57
prt:
bErr 0
sProc 2
sleeping 0
wuReSent 2
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rpt:
IO HMUART_EG
flg A
ts 1598097068.80499
ack:
HASH(0x7f08890)
6680020B98D0A9C06F00
rssi:
at_HMUART_EG:
avg -76.0714285714286
cnt 28
lst -69
max -69
min -81
at_HMUART_OG:
avg -64.7450980392157
cnt 51
lst -57
max -57
min -75
shadowReg:
tmpl:
Attributes:
.mId F102
IODev HMUART_EG
IOgrp VCCU:HMUART_EG
autoReadReg 4_reqStatus
expert rawReg
firmware 0.15
model HB-UW-Sen-THPL-O
peerIDs 00000000,
room Geräte-Inbox
serialNr UJI4498487
subType THPLSensor
Aber irgendwie verhält sich das Teil komisch. Er taucht nicht automatisch im Action Detector auf und wenn ich actCycle manuell setzen will kommt folgende Meldung (siehe Anhang)
Per edit der fhem.cfg kann ich das Attribut wohl setzen, hat aber keinen Effekt und keine Fehlermeldung.
Komisch
mach mal fhem update
Zitat von: frank am 22 August 2020, 15:31:31
mach mal fhem update
merkwürdig, aber das hat wirklich geklappt. Vielen Dank für den Tipp
Hallo Leute,
ich habe gerade versucht den Sensor mit Firmware 0.14 zu resetten und an einer Raspberrymatik anzulernen. Leider hat das nicht geklappt.
Reset hat weder via Fhem Befehl noch durch langes drücken auf die Taste funktioniert.
Auch ein Set unpair hat nicht dazu geführt, das ich den an der CCU anlernen konnte.
Kann jemand helfen? Gibts da ein Trick?
Ich habe auch versucht via HM-USB Stick auf Windows die 0.15 Firmware draufzuspielen. Leider stützt das Firmware Tool jedesmal beim Laden des Firmware Files ab. Andere Files von EQ3 gehen problemlos. (Ich habe beide .tgz und die .eq3 Datei versucht aus Github)
hier noch ein List des Devices:
Internals:
DEF 5D7D27
FUUID 5c571872-f33f-661b-b5e9-f5dd929cd85ae907
IODev hmusb2
LASTInputDev hmusb2
MSGCNT 6786
NAME HA_XX_TF
NOTIFYDEV global
NR 304
NTFY_ORDER 50-HA_XX_TF
STATE T: 24.0 H: 57 L: 352 P: 996.6 P-NN: 1001.3
TYPE CUL_HM
chanNo 01
hmusb2_MSGCNT 6786
hmusb2_RAWMSG E5D7D27,0000,46C6102A,FF,FFB3,06A2705D7D2700000000F03926EE000089660B54
hmusb2_RSSI -77
hmusb2_TIME 2020-09-24 09:46:42
lastMsg No:06 - t:70 s:5D7D27 d:000000 00F03926EE000089660B54
protCmdDel 27
protCmdPend 2 CMDs pending
protLastRcv 2020-09-24 09:46:42
protRcv 373 last_at:2020-09-24 09:46:42
protResnd 11 last_at:2020-09-24 09:39:33
protResndFail 3 last_at:2020-09-24 09:36:41
protSnd 14 last_at:2020-09-24 09:39:30
protState CMDs_pending
rssi_at_hmusb2 cnt:374 min:-81 max:-45 avg:-67.76 lst:-77
READINGS:
2020-09-24 09:46:28 Activity alive
2020-09-24 09:39:29 D-firmware 0.14
2020-09-24 09:39:29 D-serialNr UWS4265196
2020-09-24 09:46:42 batVoltage 2.90
2020-09-24 09:46:42 battery ok
2020-09-24 09:39:34 cfgState updating
2020-09-24 09:39:33 commState CMDs_pending
2020-09-24 09:46:42 humidity 57
2020-09-24 09:46:42 luminosity 352
2020-09-24 09:46:42 pressure 996.6
2020-09-24 09:46:42 pressure-nn 1001.3
2020-09-24 09:46:42 state T: 24.0 H: 57 L: 352 P: 996.6 P-NN: 1001.3
2020-09-24 09:46:42 temperature 24.0
noch nie etwas von "pending cmds" gehört?
du musst aufs knöpfchen drücken, damit die cmds auch abgearbeitet werden.
warum reset?
ich hätte der raspimatic die selbe hmid gegeben, wenn sowieso alle devices "migriert" werden.
das list ist unvollständig.
Habe ich schon... 100x knöfchen drücken hat nichts verändert. Bleibt immer auf pending.
Habe gerade noch mal das Pairing gestartet und nun ist das List auch ok.
Ich habe in meiner alten Installation mal den AES Key geändert. In der neuen habe ich neue HMID und stardard key, da der nur Stress gemacht hat. Daher muss ich via Reset alles manuell rüberziehen.
Hier ein vollständiges List:
Internals:
DEF 5D7D27
FUUID 5c571872-f33f-661b-b5e9-f5dd929cd85ae907
IODev hmusb2
LASTInputDev hmusb2
MSGCNT 34
NAME HA_XX_TF
NOTIFYDEV global
NR 259
NTFY_ORDER 50-HA_XX_TF
STATE T: 26.3 H: 60 L: 632 P: 998.1 P-NN: 1002.8
TYPE CUL_HM
chanNo 01
hmusb2_MSGCNT 34
hmusb2_RAWMSG RBF8797E8,0001,00286411,FF,FFBD,37A4105D7D272574C40601000000
hmusb2_RSSI -67
hmusb2_TIME 2020-09-24 11:52:48
lastMsg No:37 - t:10 s:5D7D27 d:2574C4 0601000000
protCmdPend 7 CMDs pending
protLastRcv 2020-09-24 11:52:48
protRcv 24 last_at:2020-09-24 11:52:48
protResnd 8 last_at:2020-09-24 11:52:53
protSnd 41 last_at:2020-09-24 11:52:48
protState CMDs_pending
rssi_at_hmusb2 cnt:34 min:-82 max:-66 avg:-73.11 lst:-67
READINGS:
2020-09-24 11:29:38 Activity alive
2020-09-24 11:51:12 CommandAccepted yes
2020-09-24 11:52:48 D-firmware 0.14
2020-09-24 11:52:48 D-serialNr UWS4265196
2020-09-24 11:51:47 PairedTo 0x2574C4
2020-09-24 09:54:41 R-altitude 0 m
2020-09-24 09:54:41 R-burstRx off
2020-09-24 09:54:41 R-ledMode on
2020-09-24 09:54:41 R-lowBatLimitTHPL 1.6 V
2020-09-24 11:51:27 R-pairCentral 0x2574C4
2020-09-24 09:54:41 R-transmDevTryMax 3
2020-09-24 11:51:56 batVoltage 2.90
2020-09-24 11:51:56 battery ok
2020-09-24 11:52:48 cfgState updating
2020-09-24 11:52:53 commState CMDs_pending
2020-09-24 11:51:56 humidity 60
2020-09-24 11:51:56 luminosity 632
2020-09-24 09:54:37 powerOn 2020-09-24 09:54:37
2020-09-24 11:51:56 pressure 998.1
2020-09-24 11:51:56 pressure-nn 1002.8
2020-09-24 11:52:48 recentStateType info
2020-09-24 11:51:56 state T: 26.3 H: 60 L: 632 P: 998.1 P-NN: 1002.8
2020-09-24 11:51:56 temperature 26.3
Ich habe noch ein wenig rumprobiert... leider ohne Erfolg. Ich kann den Sensor nicht resetten (Via Fhem oder button)
Kann ich das Teil irgendwie via OTA Update resetten?
Sonst müsste ich den Sendor leider entsorgen :-( Und es ist mein letzes Device auf meinem alten Fhem Server.
Wie versuchst Du es denn mit dem Button zurückzusetzen, wie hier (https://wiki.fhem.de/wiki/Universalsensor#Zur.C3.BCcksetzen_auf_Werkseinstellungen) beschrieben?
Falls alles nichts hilft, bevor Du es entsorgst, schick's zu mir, ggf. lässt sich noch was verwenden. Versandkosten würde ich natürlich übernehmen ;)
Ja, genau so. Extra noch mal validiert. Hat jemand noch ne Firmware, die sich flashen lässt? Dann würde ich es erst damit noch mal versuchen.
Zitat von: slor am 30 September 2020, 20:36:51
Ja, genau so. Extra noch mal validiert. Hat jemand noch ne Firmware, die sich flashen lässt? Dann würde ich es erst damit noch mal versuchen.
Probier doch mal die Firmware von Tom Majors github Seite, vermutlich musst Du neu compilieren. Du brauchst auch eine andere Sensor ID bzw. ein anderes FHEM Modul.
Gruß Peter
Zitat von: slor am 30 September 2020, 20:36:51
Ja, genau so. Extra noch mal validiert. Hat jemand noch ne Firmware, die sich flashen lässt? Dann würde ich es erst damit noch mal versuchen.
Ich kenne das Firmware-Tool von "HM-USB-Stick" nicht, aber Du könntest es auch damit versuchen:
https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb (https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb)
Damit habe ich die 0.15 Firmware auf ein Dutzend von Sensoren gespielt. Aber Voraussetzung ist, dass überhaupt ein OTA-Bootloader drauf ist. Ansonsten gibt es immer noch die Möglichkeit per ISP zu flashen. Wenn es damit nicht gehen sollte, dann ist wirklich irgendwas kaputt.
Hallo
Ich habe hier einen Unisensor auf der Außenplatine v.2.01 mit DS18B20 und SHT10 betrieben. Da die Akkus nur etwa 3 Monate hielten, habe ich mal den Sleep-Strom gemessen. Bei 3 V waren es genau 300 µA. Zuerst hatte ich den CC1101 in Verdacht, aber dann erinnerte ich mich an das Ohmsche Gesetz, wonach dieser Strom über einen 10 k-Widerstand fließen mußte. Also habe ich im Sketch alle Sensoren deaktiviert und der Sleep-Strom war erwartungsgemäß bei 2..3 µA. Mit aktiviertem DS18B20 blieb der Strom niedrig. Mit Aktivierung des SHT10 sprang er wieder auf den hohen Wert.
Am SCL habe ich dann im Sleep tatsächlich 0 V gemessen, am SDA 3V. Also fließt der Strom über den Pull-up R5 am SCL. Wenn ich nun im Sketch einen SHT31 aktiviere, messe ich im Sleep am SCL 3V und der Sleep-Strom ist entsprechend niedrig. Das bestätigt auch meine Erfahrung mit allen meinen anderen Sensoren, die alle mit SHT3x ausgestattet sind.
Das Problem scheint also irgendwo im Sketch zu liegen, wo bei aktiviertem SHT10 der SCL im Sleep auf Low verbleibt. Weiß jemand, wie das korrigiert werden kann? Meine hardwarenahen Software-Kenntnisse sind leider etwas mau...
Update
Kann das Problem hier liegen?
// Initialize CLK signal direction
// Note: All functions exit with CLK low and DAT in input mode
pinMode(_pinClock, OUTPUT);
(Aus der im Sketch verlinkten Bibliothek https://github.com/spease/Sensirion/blob/master/Sensirion.cpp)
Gruß
G.
Sprichst du vom HB-UNI-Sensor1? Falls ja, ich habe mal kurz geschaut und sehe vermutlich das Problem.
Kopier mal diese Zeile
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/Arduino/HB-UNI-Sensor1.ino#L487 (https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/Arduino/HB-UNI-Sensor1.ino#L487)
2 Zeilen nach unten, also nach dem #endif aber vor dem sht10.init()
Damit müsste SCL high bleiben, oder?
Zitat von: Tom Major am 24 Januar 2021, 23:55:02
Kopier mal diese Zeile
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/Arduino/HB-UNI-Sensor1.ino#L487 (https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/Arduino/HB-UNI-Sensor1.ino#L487)
2 Zeilen nach unten, also nach dem #endif aber vor dem sht10.init()
Damit müsste SCL high bleiben, oder?
Ja, das klappt so. Vielen Dank. --
Nächste Baustelle: Einer meiner Unisensor1 auf einer Innenplatine zieht etwas 2.44 mA aus den Batterien bei 3 V. Alle Sensoren sind deaktiviert und abgesteckt. Was kann denn diesen Strom im sleep verursachen? Das CC1101-Modul? Kann man das im aufgelöteten Zustand irgendwie testen? VCC-Zuleitung auftrennen und Strom messen?
Zitat von: Gernott am 25 Januar 2021, 20:47:18
Ja, das klappt so. Vielen Dank. --
ok, ich werde es diese Woche auf Github updaten.
Erklärung: SHT10 ist kein echter I2C, die Sensirion Lib macht Bit banging auf den Leitungen. Deswegen habe ich den I2C Shared Access code drin. Der wurde aber nur enabled wenn noch ein wirklicher I2C Sensor wie der BME drin ist, sonst nicht. Ich werde ihn jetzt immer bei SHT10 enablen.
Hi Gernott,
ich habe den Fix für den SHT10 im Repo upgedatet.
https://github.com/TomMajor/SmartHome/commit/415ba938bdb02f5d2fd22279508fcdfcd47028bd (https://github.com/TomMajor/SmartHome/commit/415ba938bdb02f5d2fd22279508fcdfcd47028bd)
Was die neue Frage betrifft, ja, soviel wie möglich bzgl. Vcc auftrennen und einzeln messen. Im orangen Forum lese ich manchmal von CC1101 Modulen mit hohem Sleep Strom.
Zitat von: Tom Major am 29 Januar 2021, 00:15:16
Hi Gernott,
ich habe den Fix für den SHT10 im Repo upgedatet.
https://github.com/TomMajor/SmartHome/commit/415ba938bdb02f5d2fd22279508fcdfcd47028bd (https://github.com/TomMajor/SmartHome/commit/415ba938bdb02f5d2fd22279508fcdfcd47028bd)
Was die neue Frage betrifft, ja, soviel wie möglich bzgl. Vcc auftrennen und einzeln messen. Im orangen Forum lese ich manchmal von CC1101 Modulen mit hohem Sleep Strom.
Danke!
Ich habe mal die +-Leitung auf der Platine zum C1101 getrennt und den Strom gemessen. Es ist tatsächlich das Modul. Es ist also schon dringend notwendig, alle Module vor dem Auflöten auf der Testbench zu testen, insbesondere auch zum Sleep-Strom.
Zitat von: Gernott am 30 Januar 2021, 12:38:35
Es ist also schon dringend notwendig, alle Module vor dem Auflöten auf der Testbench zu testen, insbesondere auch zum Sleep-Strom.
Danke für den Tipp. Die Frequenz teste ich schon standardmäßig, den Ruhestrom noch nicht. Muss ich mal mit einbauen.
Gruß Peter
Hallo zusammen,
mein alter Universal-Sensor von Dirk (ATMega328P, Platine "Universal-Sensor Rev 1.3, 07/2014, Firmwareversion 0.15) mit THPL-Sensoren funktioniert noch leidlich gut.
In FHEM läuft er unter dem Typ "HB-UW-Sen-THPL-I".
Da die Funkreichweite recht mager ist, möchte ich den Frequenztest "FreqTest" laufen lassen, um den CC1101 zu tunen, da ich vermute, dass es an einer suboptimalen Frequenzeinstellung liegt; so ist jedenfalls meine Hoffnung. Unabhängig von diesem Makel möchte ich auf eine neue Firmware wechseln.
Dazu müsste ich natürlich wissen, ob generell damals auf diesen Controllern ein Bootloader installiert war, so dass ich
a. den Frequenztest-Sketch mit einem FTDI flashen kann
b. anschließend den aktuellen HB-UNI-Sensor1-Sketch flashen kann.
Falls kein Bootloader installiert ist, kann ich dann diesen Bootloader nehmen, funktioniert das mit einem Pololulu USB AVR Programmer?
https://github.com/TomMajor/SmartHome/tree/master/Info/Bootloader
Ich habe noch nicht soviel Übung im Flashen, deswegen möchte ich mich vorher vergewissern. Habe zwar die GitHub-Beiträge gelesen, aber da die Hardware schon älter ist und wahrscheinlich keine so ausgefeilte Batteriespannungsüberprüfung usw. hat...
Vielen Dank!
P.S.: Sehe gerade, dass auf dem Batteriehalter noch neben der Seriennr. der Aufdruck "OTAU 0.7.0" steht.
Zitat von: FFHEM am 01 März 2021, 16:45:59
Dazu müsste ich natürlich wissen, ob generell damals auf diesen Controllern ein Bootloader installiert war, so dass ich
a. den Frequenztest-Sketch mit einem FTDI flashen kann
b. anschließend den aktuellen HB-UNI-Sensor1-Sketch flashen kann.
Falls kein Bootloader installiert ist, kann ich dann diesen Bootloader nehmen, funktioniert das mit einem Pololulu USB AVR Programmer?
https://github.com/TomMajor/SmartHome/tree/master/Info/Bootloader
Ich habe noch nicht soviel Übung im Flashen, deswegen möchte ich mich vorher vergewissern. Habe zwar die GitHub-Beiträge gelesen, aber da die Hardware schon älter ist und wahrscheinlich keine so ausgefeilte Batteriespannungsüberprüfung usw. hat...
Der bootloader sollte passen und wenn der Pololulu funktioniert kann du "alles" damit flashen, auch den bootloader ;)
Anmerkung: falls nicht bekannt, der bootloader ist ein Komfort-Feature um jederzeit über 4 Leitungen seriell, z.B. mit einem FTDI flashen zu können, direkt aus der Arduino IDE heraus.
Ebenso kann man auch auf den bootloader ganz verzichten und z.B. mit avrdude über 6 Leitungen ISP flashen (FreqTest, danach Sketch), das geht immer solange der AVR ganz ist und die Fuses bzgl. Clock nicht verhunzt sind.
Vielen Dank, Tom Major, dann werde ich es mal ausprobieren!
Und bei der Gelegenheit ein weiteres großes Dankeschön an Dich für alle Deine Arbeit!!!
Gruß, Friedhelm
Zitat von: FFHEM am 02 März 2021, 16:26:03
Vielen Dank, Tom Major, dann werde ich es mal ausprobieren!
Und bei der Gelegenheit ein weiteres großes Dankeschön an Dich für alle Deine Arbeit!!!
Gruß, Friedhelm
Gerne.
Hier gibt es übrigens jede Menge Infos zu Grundlagen Flashen usw. sowie viele AskSinPP Projekte:
https://asksinpp.de/Grundlagen/02_software.html#sketch-download-und-anpassen (https://asksinpp.de/Grundlagen/02_software.html#sketch-download-und-anpassen)
So, habe nun doch (noch) nicht den alten HM_WDS10_TH_O umgeflasht, sondern meinen neuen HB_Uni_Sens_Batt mit dem HB-UNI-Sensor1-Sketch geflasht und neben dem BME 280 noch einen BH1750 angeschlossen, funktioniert alles wunderbar.
Nur bin ich wohl zu dämlich, den Luftdruckwert zu korrigieren, also die "altitude" zu setzen.
In der HB-Uni-Sensor1.ino steht:
void defaults()
{
clear();
ledMode(1);
lowBatLimit(BAT_VOLT_LOW);
transmitDevTryMax(6);
updIntervall(180); ### geändert
altitude(85); ### geändert
}Neu compiliert, übertragen: keine Änderung, weder bei Luftdruck noch beim Updateintervall. Mehrfach ausprobiert.
Das Setzen per "regset set xxxx altitude 85" klappt auch nicht, auch nicht mit mehrfachem getconfig und Taster drücken (ist ja von Homematic bekannt).
Also das hier funktioniert nicht:
Zitat
Parameter Höhe einstellen:
"Ich konnte bei meinem THPL Sensor mit BME280 und MAX44009 über getConfig // Config drücken // set regSet altitude 590 // Config drücken // getConfig // Config drücken die Höhe einstellen. Bitte berichtigt mich, wenn ich da zu viel drücke und mache- so hat es jedenfalls funktioniert ::)"
FHEM user kpwg
Wo liegt mein Fehler?
Vielen Dank!
zeig ein list
Vielen Dank für's Ansehen!
Internals:
CFGFN
DEF A5A501
FUUID 6040fe82-f33f-26cd-e33e-b1c1142d397277f1
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 430
NAME TempHumLichtLuftdruck
NOTIFYDEV global
NR 1366
STATE 21.5 °C 39 % 160.00 lx 1024.9 hP
ok
TYPE CUL_HM
chanNo 01
lastMsg No:32 - t:10 s:A5A501 d:FF3004 0601000016
myHmUART_MSGCNT 430
myHmUART_RAWMSG 0501000D328210A5A501FF30040601000016
myHmUART_RSSI -13
myHmUART_TIME 2021-03-06 19:17:22
protLastRcv 2021-03-06 19:17:22
protRcv 431 last_at:2021-03-06 19:17:22
protResnd 1 last_at:2021-03-06 18:29:31
protSnd 109 last_at:2021-03-06 19:17:22
protState CMDs_done
rssi_at_myHmUART cnt:431 min:-69 max:-8 avg:-27.27 lst:-13
rssi_myHmUART cnt:20 min:-66 max:-21 avg:-28.15 lst:-22
READINGS:
2021-03-05 16:48:28 CommandAccepted yes
2021-03-06 19:10:10 D 7.0
2021-03-06 19:17:21 D-firmware 1.3
2021-03-06 19:17:21 D-serialNr UNISENS001
2021-03-06 19:17:22 PairedTo 0xFF3004
2021-03-06 19:17:22 RegL_00. 00:00 05:40 0A:FF 0B:30 0C:04 12:15 14:06 20:02 21:58 22:00 23:00
2021-03-06 19:10:10 batVoltage 3.04
2021-03-06 19:10:10 battery ok
2021-03-06 19:10:10 brightness 160.00
2021-03-06 19:17:52 cfgState ok
2021-03-06 19:17:22 commState CMDs_done
2021-03-06 19:10:10 customData 0
2021-03-06 19:10:10 dewpoint 7.0
2021-03-06 19:10:10 digitalInput 0
2021-03-06 19:10:10 humidity 39
2021-03-06 19:17:08 powerOn 2021-03-06 19:17:08
2021-03-06 19:10:10 pressure 1024.9
2021-03-06 19:17:22 recentStateType info
2021-03-06 19:10:10 state T: 21.5 P: 1024.9 H: 39 B: 160.00 I: 0 X: 0
2021-03-06 19:10:10 temperature 21.5
helper:
HM_CMDNR 50
PONtest 0
cSnd 01FF3004A5A5010103,01FF3004A5A501010E
cfgChkResult No regs found for:-ret--ret-TempHumLichtLuftdruck type:UniSensor1 - -ret-list:peer register :value-ret- 0: ledMode :undef lit:1-ret- 0: lowBatLimit :2.1 V-ret- 0: pairCentral :0xFF3004-ret- 0: transmDevTryMax :6-ret- 0: updateIntervall :600 s-ret- -ret- -ret-
mId F103
peerFriend
peerIDsRaw ,00000000
peerIDsState complete
peerOpt p:UniSensor1
regLst 0
rxType 156
supp_Pair_Rep 0
cmds:
TmplKey :no:1615054646.8854
TmplTs 1615054646.8854
cmdKey 1:1:0::TempHumLichtLuftdruck:F103:01:
cmdLst:
assignHmKey noArg
burstXmit noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate <filename> <bootTime> ...
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
getSerial noArg
getVersion noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 <actChn> ... single [set|unset] [actor|remote|both]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
statusRequest noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 0
det 0
raw 1
tpl 0
io:
newChn +A5A501,00,00,00
nextSend 1615054643.0492
prefIO
rxt 2
vccu
p:
A5A501
00
00
00
mRssi:
mNo 32
io:
myHmUART:
-5
-5
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
sleeping 0
q:
qReqConf
qReqStat 00
regCollect:
role:
chn 1
dev 1
rssi:
at_myHmUART:
avg -27.2761020881671
cnt 431
lst -13
max -8
min -69
myHmUART:
avg -28.15
cnt 20
lst -22
max -21
min -66
shadowReg:
tmpl:
nb:
cnt 2
Attributes:
IODev myHmUART
IOgrp VCCU:myHmUART
autoReadReg 5_readMissing
devStateIcon ok:measure_battery_100@green low:measure_battery_0@red
expert rawReg
firmware 1.3
group Temperatur
icon temp_outside
model HB-UNI-Sensor1
peerIDs 00000000
room CUL_HM,Wetterstation
serialNr UNISENS001
stateFormat temperature °C humidity % brightness lx pressure hP
battery
subType UniSensor1
erweitere mal attr expert um allreg, damit die register auch für nicht eingeweihte "sichtbar" werden.
wurde die zusätzliche HMConfig....pm geladen?
das sollte im fhem.log beim restart zu sehen sein.
Nun mit mehr Infos:
Das updateIntervall kann ich ohne Probleme mit regset... setzen, aber die Höhe (altitude) bleibt beim jeweiligen letzten Versuch auf
set_80 m
stehen, s. List weiter unten.
Die beiden Dateien
HMConfig_UniSensor1.pm
HMConfig_UniSensor1_fw0x12.pm
stehen im Verzeichnis /opt/fhem/FHEM und sind im Log beim Neustart zu sehen,
ich hatte vorher die Datei "HMConfig_UniSensor1_fw0x12.pm" noch nicht im FHEM-Verzeichnis liegen.
2021.03.07 09:34:19.294 3: additional HM config file loaded: ./FHEM/HMConfig_UniSensor1_fw0x12.pm
2021.03.07 09:34:19.302 1: PERL WARNING: Subroutine CUL_HM_ParseUniSensor1 redefined at ./FHEM/HMConfig_UniSensor1.pm line 37, <$fh> line 136.
2021.03.07 09:34:19.303 3: additional HM config file loaded: ./FHEM/HMConfig_UniSensor1.pm
2021.03.07 09:34:19.308 3: additional HM config file loaded: ./FHEM/HMConfig_SenTHPL.pm
Da auch die Änderung im Sketch (wahrscheinlich ändere ich an der falschen Stelle) keine Änderung brachte, habe ich zum Test einen anderen Sketch, den FreqTest einmal geflasht, um eine Änderung zu erzwingen, dann erneut den HB-Uni-Sensor1 geflasht mit den geänderten Defaultwerten für altitude.
Am Terminal ergab das dennoch keine Änderung der altitude:
AskSin++ v5.0.0 (Mar 7 2021 09:56:38)
09:57:29.706 -> BME280 found
09:57:29.706 -> BH1750 found
09:57:29.739 -> Sensor setup done
09:57:29.739 -> Serial: UNISENS001
09:57:29.739 -> Clock SYSCLOCK
09:57:29.739 -> Address Space: 32 - 73
09:57:29.739 -> CC init1
09:57:29.739 -> CC Version: 14
09:57:29.739 -> - ready
09:57:29.805 -> tmBattery Voltage: 3362
09:57:29.838 -> Battery set low: 21
09:57:29.838 -> Battery set crit: 19
09:57:29.838 -> Config Freq: 0x216612
09:57:29.838 -> Config Changed: List0
09:57:29.838 -> ledMode: 1
09:57:29.838 -> lowBatLimit: 21
09:57:29.838 -> Battery set low: 21
09:57:29.838 -> transmitDevTryMax: 6
09:57:29.838 -> updCycle: 180
09:57:29.838 -> altitude: 0
09:57:35.243 -> BME280 Temperature x10 : 245
09:57:35.243 -> BME280 Pressure x10 : 10201
09:57:35.276 -> BME280 PressureNN x10 : 10201
09:57:35.276 -> BME280 Humidity : 34
09:57:35.740 -> BH1750 Brightness Lux x100: 702
09:57:35.774 -> <- 17 01 84 70 A5A501 000000 00 F5 27 D9 22 00 00 02 BE 00 0D 22 00 00 - 735
List des Devices:
Internals:
DEF A5A501
FUUID 6040fe82-f33f-26cd-e33e-b1c1142d397277f1
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 22
NAME TempHumLichtLuftdruck
NOTIFYDEV global
NR 1286
NTFY_ORDER 50-TempHumLichtLuftdruck
STATE 19.5 °C 40 % 40.42 lx 1020.4 hP
ok
TYPE CUL_HM
chanNo 01
lastMsg No:94 - t:10 s:A5A501 d:FF3004 060100001D
myHmUART_MSGCNT 22
myHmUART_RAWMSG 05010014948210A5A501FF3004060100001D
myHmUART_RSSI -20
myHmUART_TIME 2021-03-07 09:37:42
protLastRcv 2021-03-07 09:37:42
protRcv 22 last_at:2021-03-07 09:37:42
protSnd 18 last_at:2021-03-07 09:37:42
protState CMDs_done
rssi_at_myHmUART cnt:22 min:-25 max:-19 avg:-22.09 lst:-20
rssi_myHmUART cnt:3 min:-30 max:-28 avg:-29 lst:-29
READINGS:
2021-03-07 09:37:33 CommandAccepted yes
2021-03-07 09:35:59 D 5.5
2021-03-07 09:37:41 D-firmware 1.3
2021-03-07 09:37:41 D-serialNr UNISENS001
2021-03-07 09:37:42 PairedTo 0xFF3004
2021-03-07 09:37:15 R-altitude set_80 m
2021-03-04 16:38:06 R-ledMode undef lit:1
2021-03-04 16:38:06 R-lowBatLimit 2.1 V
2021-03-04 16:38:06 R-pairCentral 0xFF3004
2021-03-05 16:47:45 R-sign off
2021-03-04 16:38:06 R-transmDevTryMax 6
2021-03-07 09:30:06 R-updateIntervall 180 s
2021-03-07 09:35:59 batVoltage 3.09
2021-03-07 09:35:59 battery ok
2021-03-07 09:35:59 brightness 40.42
2021-03-07 09:38:12 cfgState ok
2021-03-07 09:37:42 commState CMDs_done
2021-03-07 09:35:59 customData 0
2021-03-07 09:35:59 dewpoint 5.5
2021-03-07 09:35:59 digitalInput 0
2021-03-07 09:35:59 humidity 40
2021-03-06 19:17:08 powerOn 2021-03-06 19:17:08
2021-03-07 09:35:59 pressure 1020.4
2021-03-07 09:37:42 recentStateType info
2021-03-07 09:35:59 state T: 19.5 P: 1020.4 H: 40 B: 40.42 I: 0 X: 0
2021-03-07 09:35:59 temperature 19.5
helper:
HM_CMDNR 148
cSnd 01FF3004A5A5010103,01FF3004A5A501010E
mId F103
peerFriend
peerIDsRaw ,00000000
peerIDsState complete
peerOpt p:UniSensor1
regLst 0
rxType 156
supp_Pair_Rep 0
cmds:
TmplKey :no:1615106266.90198
TmplTs 1615106266.90198
cmdKey 1:1:0::TempHumLichtLuftdruck:F103:01:
cmdLst:
assignHmKey noArg
burstXmit noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate <filename> <bootTime> ...
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
getSerial noArg
getVersion noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 <actChn> ... single [set|unset] [actor|remote|both]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
statusRequest noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 1
raw 0
tpl 0
io:
newChn +A5A501,00,00,00
nextSend 1615106262.9143
rxt 2
vccu VCCU
p:
A5A501
00
00
00
prefIO:
myHmUART
mRssi:
mNo 94
io:
myHmUART:
-12
-12
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
sleeping 0
try 1
q:
qReqConf
qReqStat 00
regCollect:
role:
chn 1
dev 1
rssi:
at_myHmUART:
avg -22.0909090909091
cnt 22
lst -20
max -19
min -25
myHmUART:
avg -29
cnt 3
lst -29
max -28
min -30
shadowReg:
tmpl:
Attributes:
IODev myHmUART
IOgrp VCCU:myHmUART
autoReadReg 5_readMissing
devStateIcon ok:measure_battery_100@green low:measure_battery_0@red
expert allReg
firmware 1.3
group Temperatur
icon temp_outside
model HB-UNI-Sensor1
peerIDs 00000000
room CUL_HM,Wetterstation
serialNr UNISENS001
stateFormat temperature °C humidity % brightness lx pressure hP
battery
subType UniSensor1
2021.03.07 09:34:19.294 3: additional HM config file loaded: ./FHEM/HMConfig_UniSensor1_fw0x12.pm
2021.03.07 09:34:19.302 1: PERL WARNING: Subroutine CUL_HM_ParseUniSensor1 redefined at ./FHEM/HMConfig_UniSensor1.pm line 37, <$fh> line 136.
2021.03.07 09:34:19.303 3: additional HM config file loaded: ./FHEM/HMConfig_UniSensor1.pm
2021.03.07 09:34:19.308 3: additional HM config file loaded: ./FHEM/HMConfig_SenTHPL.pm
gibt es nun 2 unterschiedliche register definitionen für dein device, welches durch die attribute subtype/model beschrieben wird?
Zitat von: frank am 07 März 2021, 11:17:56
gibt es nun 2 unterschiedliche register definitionen für dein device, welches durch die attribute subtype/model beschrieben wird?
Nein subtype/model sind identisch. Habe die beiden Files mal verglichen und die mit "fw0x12"
wieder aus dem FHEM-Verzeichnis entfernt, diese war für Firmwareversionen <= 0x12 und hatte noch keinen Code für weitere Lichtsensoren und noch keine 16bit customData. Scheint also nicht daran zu liegen.
Die Dateien sind hierher:
https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1/FHEM (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1/FHEM)
ein sniff vom lesen und schreiben der register wäre gut.
edit: vermutung gelöscht.
Das Sniffen ergibt (habe getconfig und regset Lichtsensor altitude 83 wechselseitig gesetzt):
Die HM-ID ist A5A501. Dies ist jetzt im Zustand, dass die HMConfig..... wie in Deinem Vorschlag geändert wurde.
[Update: sehe gerade, dass Du die Vermutung zurückgezogen hast]
2021.03.07 18:44:23.788 1: HMUARTLGW myHmUART frame with wrong length received: 50, should: 25: FD0015014C0500003935861044E8810000000AACD90D000038C60015014D05000031978610455B340000000AB0DC0E0F007848
2021.03.07 18:44:24.236 1: HMUARTLGW myHmUART frame with wrong length received: 50, should: 25: FD0015014C0500003935861044E8810000000AACD90D000038C60015014D05000031978610455B340000000AB0DC0E0F007848
2021.03.07 18:46:55.841 0: HMUARTLGW myHmUART send: 01 06A5A501000100
2021.03.07 18:46:55.848 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
2021.03.07 18:46:55.850 0: HMUARTLGW myHmUART send: 01 06A5A501000100
2021.03.07 18:46:55.857 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
2021.03.07 18:46:59.712 0: HMUARTLGW myHmUART recv: 01 05 01 00 12 msg: 07 80 00 A5A501 FF3004 13F103554E4953454E5330303170010101
2021.03.07 18:46:59.810 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 2F A0 01 FF3004 A5A501 00050000000000
2021.03.07 18:46:59.975 0: HMUARTLGW myHmUART recv: 01 04 03 00 12 msg: 2F 80 02 A5A501 FF3004 00
2021.03.07 18:47:00.072 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 30 A0 01 FF3004 A5A501 000824002554
2021.03.07 18:47:00.235 0: HMUARTLGW myHmUART recv: 01 04 03 00 12 msg: 30 80 02 A5A501 FF3004 00
2021.03.07 18:47:00.333 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 31 A0 01 FF3004 A5A501 0006
2021.03.07 18:47:00.495 0: HMUARTLGW myHmUART recv: 01 04 03 00 12 msg: 31 82 02 A5A501 FF3004 00
2021.03.07 18:47:00.593 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 32 A0 01 FF3004 A5A501 010E
2021.03.07 18:47:00.770 0: HMUARTLGW myHmUART recv: 01 05 01 00 12 msg: 32 82 10 A5A501 FF3004 060100001B
2021.03.07 18:47:00.868 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 33 A0 01 FF3004 A5A501 00040000000000
2021.03.07 18:47:01.056 0: HMUARTLGW myHmUART recv: 01 05 01 00 12 msg: 33 A0 10 A5A501 FF3004 020AFF0B300C04054012151406200021B4
2021.03.07 18:47:01.205 0: HMUARTLGW myHmUART recv: 01 05 01 00 12 msg: 33 80 10 A5A501 FF3004 02220023000000
2021.03.07 18:47:01.304 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 34 A0 01 FF3004 A5A501 0103
2021.03.07 18:47:01.482 0: HMUARTLGW myHmUART recv: 01 05 01 00 12 msg: 34 80 10 A5A501 FF3004 0100000000
2021.03.07 18:47:01.489 0: HMUARTLGW myHmUART send: 01 06A5A501000000
2021.03.07 18:47:01.498 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
2021.03.07 18:47:01.501 0: HMUARTLGW myHmUART send: 01 06A5A501000000
2021.03.07 18:47:01.509 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
2021.03.07 18:47:04.754 0: HMUARTLGW myHmUART send: 01 06A5A501000000
2021.03.07 18:47:04.766 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
2021.03.07 18:47:04.770 0: HMUARTLGW myHmUART send: 01 06A5A501000000
2021.03.07 18:47:04.778 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
2021.03.07 18:47:07.652 0: HMUARTLGW myHmUART send: 01 06A5A501000100
2021.03.07 18:47:07.659 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
2021.03.07 18:47:07.661 0: HMUARTLGW myHmUART send: 01 06A5A501000100
2021.03.07 18:47:07.772 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
2021.03.07 18:47:12.784 0: HMUARTLGW myHmUART recv: 01 05 01 00 11 msg: 08 80 00 A5A501 FF3004 13F103554E4953454E5330303170010101
2021.03.07 18:47:12.881 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 30 A0 01 FF3004 A5A501 00040000000000
2021.03.07 18:47:13.145 0: HMUARTLGW myHmUART recv: 01 05 01 00 11 msg: 30 A0 10 A5A501 FF3004 020AFF0B300C04054012151406200021B4
2021.03.07 18:47:13.215 0: HMUARTLGW myHmUART recv: 01 05 01 00 11 msg: 30 80 10 A5A501 FF3004 02220023000000
2021.03.07 18:47:13.312 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 31 A0 01 FF3004 A5A501 0103
2021.03.07 18:47:13.492 0: HMUARTLGW myHmUART recv: 01 05 01 00 12 msg: 31 80 10 A5A501 FF3004 0100000000
2021.03.07 18:47:13.590 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 32 A0 01 FF3004 A5A501 010E
2021.03.07 18:47:13.765 0: HMUARTLGW myHmUART recv: 01 05 01 00 12 msg: 32 82 10 A5A501 FF3004 060100001B
2021.03.07 18:47:13.772 0: HMUARTLGW myHmUART send: 01 06A5A501000000
2021.03.07 18:47:13.780 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
2021.03.07 18:47:13.784 0: HMUARTLGW myHmUART send: 01 06A5A501000000
2021.03.07 18:47:13.793 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
2021.03.07 18:47:17.832 0: HMUARTLGW myHmUART send: 01 06A5A501000000
2021.03.07 18:47:17.844 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
2021.03.07 18:47:17.848 0: HMUARTLGW myHmUART send: 01 06A5A501000000
2021.03.07 18:47:17.856 0: HMUARTLGW myHmUART added peer: A5A501, aesChannels: FFFFFFFFFFFFFFFF
Bis auf die Tatsache das es bei kpwg vor ca. 2 Jahren funktionierte, wie im Zitat angegeben, kann ich leider nichts beitragen, betreibe kein FHEM mehr.
Das Register wo die altitude drinsteht (34/35) hat sich auch die ganze Zeit nicht geändert soweit ich das überblicke.
scheinbar überschreibt FHEM/HMConfig_SenTHPL.pm die definition des register altitude.
dort ist adresse 36,37.
lösche mal FHEM/HMConfig_SenTHPL.pm und starte neu.
ZitatUpdate: sehe gerade, dass Du die Vermutung zurückgezogen hast
das war unüberlegt. :-[
Frank, das war ein Volltreffer:
Kann jetzt altitude setzen, steht auf 83 m!!!! :) :) :)
Aber was mache ich jetzt mit dem anderen Sensor?
2021-03-07 19:39:32 CommandAccepted yes
2021-03-07 10:13:06 D 7.3
2021-03-07 19:39:31 D-firmware 1.3
2021-03-07 19:39:31 D-serialNr UNISENS001
2021-03-07 19:39:34 PairedTo 0xFF3004
2021-03-07 19:39:32 R-altitude 83 m
2021-03-04 16:38:06 R-ledMode undef lit:1
2021-03-04 16:38:06 R-lowBatLimit 2.1 V
2021-03-04 16:38:06 R-pairCentral 0xFF3004
2021-03-05 16:47:45 R-sign off
2021-03-04 16:38:06 R-transmDevTryMax 6
2021-03-07 09:30:06 R-updateIntervall 180 s
am einfachsten ist wohl unterschiedliche registernamen zu nutzen. aber überall in der .pm datei ändern.
also zb altitude => altitudeUS1
eigentlich müssten neue registernamen bei asksin zentral verwaltet werden, wie auch die modelIDs. sonst ist chaos angesagt.
edit:1. die anzeige des registers ledMode passt ja auch noch nicht.
hier sollte eigentlich die überflüssige definition entfallen, da das register bereits genau so definiert ist.
also zeile löschen.
2. das register lowBatLimit muss eigentlich auch umbenannt werden, da es bereits für sirenen existiert und dann dort nicht mehr passt.
also zb lowBatLimit => lowBatLimitUS1
3. in der model definition ist am ende der zeile das komma zu viel und erzeugt bei mir eine warnung.
Zitat$HMConfig::culHmModel{'F103'} = {name => 'HB-UNI-Sensor1', st => 'UniSensor1', cyc => '00:10', rxt => 'l:w:c:f', lst => 'p', chn => '',};
Hallo Frank,
habe jetzt in der HM_ConfigSenTHPL.pm den Registernamen altitude überall geändert -> mein alter Sensor THPL funktioniert wieder!
In HM_Config_UniSensor1.pm die Definition der ledMode auskommentiert, jetzt kommt auch der richtige ledMode (on) an.
Das überflüssige Komma in der Modelldefinition ist auch entfernt.
Jetzt werde ich noch für die Temperatur und die Luftfeuchtigkeit feste Defines für Temperatur- und Luftfeuchtigkeitoffsets in die Arduino-Software reinschreiben.
Scheint jetzt alles prima zu laufen, ich bedanke mich recht herzlich!
Grüße,
Friedhelm
noch zur info:
wenn man eigene register in der homebrew.pm definiert und in der definition "literals" bestimmt, erwartet cul_hm "neuerdings?" auch den hash {litInv}, in dem die keys/values zu {lit} getauscht sind.
beim einlesen der HMConfig.pm wird das am ende automatisch gemacht:
foreach my $rN (keys %culHmRegDefine) {#create literal inverse for fast search
if ($culHmRegDefine{$rN}{lit}){# literal assigned => create inverse
foreach my $lit (keys %{$culHmRegDefine{$rN}{lit}}){
$culHmRegDefine{$rN}{litInv}{$culHmRegDefine{$rN}{lit}{$lit}}=$lit;
}
}
}
für einzelne neue register kann man das ja direkt definieren.
für das (schlechte, weil überflüssige) beispiel mit ledMode dann so:
$HMConfig::culHmRegDefine{'ledMode'} = {a=> 5.6,s=>0.2,l=>0,min=>0 ,max=>1 ,p=>'n',c=>'lit',f=>'',u=>'' ,d=>0,t=>'LED mode',lit=>{off=>0,on=>1}, litInv=>{0=>'off', 1=>'on'}};
Danke!
Mal eine Frage bzgl. Temperatursensoren:
Ich hab bisher nur den BME280 verwendet. Hatte jetzt aber schon bei zwei Exemplaren das Problem, dass nach einigen Monaten die Luftfeuchtigkeit zu hoch (teilweise über längere Zeit 100%) angezeigt wird.
Nun hab ich gesehen, dass der SHT-30 unterstützt wird. Laut Datenblatt hat er eine Genauigkeit von +/- 0,3°C (wenn ich es richtig verstehe). Auf der Projektseite, wird ja empfohlen den DS18B20 anstelle des BME280 zu verwenden. Der DS18B20 ist jedoch nur mit +/- 0,5°C angegeben.
Laut Code hat ja wohl der DS Priorität ggü. dem BME und der SHT-30 wiederum Prio ggü. dem DS?
#ifdef SENSOR_BME280
uint16_t altitude = this->device().getList0().altitude();
bme280.measure(altitude);
temperature10 = bme280.temperature();
airPressure10 = bme280.pressureNN();
humidity = bme280.humidity();
#elif defined SENSOR_BMP180
uint16_t altitude = this->device().getList0().altitude();
bmp180.measure(altitude);
temperature10 = bmp180.temperature();
airPressure10 = bmp180.pressureNN();
#endif
// Falls DS18X20 vorhanden, dessen Temp der BME280/BMP180 Temp vorziehen
#ifdef SENSOR_DS18X20
Sens_DS18X20::measure(ds18x20, ds18x20Count);
temperature10 = ds18x20[0].temperature();
// Beispiel: Hier sind alle DS18B20 Temperaturen im Array falls mehrere DS18B20 an einem Pin/Bus verwendet werden
// Dafür muss DS18X20_COUNT in der Konfigurationsdatei angepasst werden!
// for (uint8_t i = 0; i < DS18X20_COUNT; i++) {
// temp10Array18x20[i] = ds18x20[i].temperature();
//}
#endif
// Feuchte/Temp vom SHT31/21/10 falls kein BME280 vorhanden
#ifndef SENSOR_BME280
#ifdef SENSOR_SHT31
sht31.measure();
temperature10 = sht31.temperature();
humidity = sht31.humidity();
#elif defined SENSOR_SHT21
sht21.measure();
temperature10 = sht21.temperature();
humidity = sht21.humidity();
#elif defined SENSOR_SHT10
sht10.measure();
temperature10 = sht10.temperature();
humidity = sht10.humidity();
#endif
#endif
Also die Frage ist: wenn ich einen SHT-30 verwende, dann macht es keinen Sinn, parallel einen DS18B20 anzuschließen. Erstens, weil der SHT ja höhere Priorität hat und zweitens, weil er eine höhere Genauigkeit hat? Wohl mit dem kleinen Haken, dass er mit einem Breakout-Board etwas träger reagiert als ein freifliegender DS?
Zitat von: vbs am 02 April 2021, 21:59:04
Also die Frage ist: wenn ich einen SHT-30 verwende, dann macht es keinen Sinn, parallel einen DS18B20 anzuschließen. Erstens, weil der SHT ja höhere Priorität hat und zweitens, weil er eine höhere Genauigkeit hat? Wohl mit dem kleinen Haken, dass er mit einem Breakout-Board etwas träger reagiert als ein freifliegender DS?
Das ist wohl so. Bei mir habe ich im Unisensor-Sketch die Temperaturmessung vom SHT stets auskommentiert, weil ich die Temperatur vom DS18B20 bevorzuge. Bei Tom im Github gibt es einige Kurven zur Trägheit der auf die Breakouts aufgelöteten Temperatursensoren. Kann jeder also selbst entscheiden, welche Temperatur er nutzen will.
Zitat von: vbs am 02 April 2021, 21:59:04
Laut Code hat ja wohl der DS Priorität ggü. dem BME und der SHT-30 wiederum Prio ggü. dem DS?
Also die Frage ist: wenn ich einen SHT-30 verwende, dann macht es keinen Sinn, parallel einen DS18B20 anzuschließen. Erstens, weil der SHT ja höhere Priorität hat und zweitens, weil er eine höhere Genauigkeit hat? Wohl mit dem kleinen Haken, dass er mit einem Breakout-Board etwas träger reagiert als ein freifliegender DS?
ja, soll aber nur ein Beispiel mit den ganzen #if/else sein. Du kannst ja jederzeit nicht genutzte Zuweisungen auskommentieren oder verschieben wegen den Prioritäten.
Der SHT-30 auf einem Breakout Board wird prinzipiell ähnliche Trägheitsprobleme wie der BME haben. Allerdings sehe ich beim Amazon Bild eine Art Folie zwischen SHT und Board. Eventuell ist die zur thermischen Isolierung?
Genau wissen wirst du es erst mit eigenen Messreihen. Würde vermuten ein DS18 der frei in der Luft hängt wird kaum zu schlagen sein bzgl. Dynamik, aber wer weiß.
Wenn du 2 Temps gleichzeitig beim UniSensor brauchst könntest du den HB-UNI-Sensor3 nehmen.
https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#benutzerspezifische-sensordaten (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#benutzerspezifische-sensordaten)
Allerdings müsste dafür dann auch das Perl Skript angepasst werden.
Zitat von: vbs am 02 April 2021, 21:59:04
Laut Code hat ja wohl der DS Priorität ggü. dem BME und der SHT-30 wiederum Prio ggü. dem DS?
Also die Frage ist: wenn ich einen SHT-30 verwende, dann macht es keinen Sinn, parallel einen DS18B20 anzuschließen. Erstens, weil der SHT ja höhere Priorität hat und zweitens, weil er eine höhere Genauigkeit hat? Wohl mit dem kleinen Haken, dass er mit einem Breakout-Board etwas träger reagiert als ein freifliegender DS?
ich habe alle 3 Sensoren im Einsatz. Die Steuerung welcher aktiv ist habe ich, wie schon von Gernot und Tom Major schrieb, per Änderung im Sourcecode gemacht.
Kombination BME280 mit DS18B20. Der BME280 war langsam und zeigte zu hohe Temperaturen an. Die SHT30 und DS18B20 waren immer identisch. Der SHT30 nur etwas langsamer. Im Neuzustand kein Problem.
Das Problem mit der Luftfeuchte habe ich nicht, habe 2 Sensoren außen und die hängen da seit 3 oder 4 Jahren. Bildet sich vielleicht Kondenswasser in deinem Gehäuse das nicht ablaufen kann?
Ok, danke euch. Ich werde da mal rumprobieren.
Die Trägheit beim BME280-Breakout ist ja doch beachtlich. Der braucht ja 2 Stunden...
Die schnelle Reaktionszeit beim DS18 bezieht sich sicherlich auf die Variante mit dem kleinen Bauteil hier rechts auf dem Bild oder? Ich hab noch einen mit Kabel und diesem "Kolben" wie links auf dem Bild. Der Kolben wird wohl auch eine ziemlich Trägheit mitbringen, oder?
https://github.com/TomMajor/SmartHome/raw/master/HB-UNI-Sensor1/Images/DS18B20_Pin_Assignment.jpg
Zitat von: kadettilac89 am 03 April 2021, 09:16:23
Das Problem mit der Luftfeuchte habe ich nicht, habe 2 Sensoren außen und die hängen da seit 3 oder 4 Jahren. Bildet sich vielleicht Kondenswasser in deinem Gehäuse das nicht ablaufen kann?
Ja, hab ich schon versucht. Hab den Sensor reingeholt und komplett durchgelüftet. Wurde zwar besser, aber zeigt systematisch z.B. innen ~40% an während mehrere anderen Sensor 32% zeigen. Dann hab ich ihn wieder auf den Balkon gehängt und da war er sofort wieder bei 95-100%...
Hab ihn dann gegen ein anderes Exemplar getauscht und dann war es sofort i.O. Ist mir nicht klar, was das los ist... Werde jetzt auf einen SHT-35 umsteigen probeweise bzw. DS18.
Zitat von: vbs am 03 April 2021, 12:30:57
Die Trägheit beim BME280-Breakout ist ja doch beachtlich. Der braucht ja 2 Stunden...
Die schnelle Reaktionszeit beim DS18 bezieht sich sicherlich auf die Variante mit dem kleinen Bauteil hier rechts auf dem Bild oder? Ich hab noch einen mit Kabel und diesem "Kolben" wie links auf dem Bild. Der Kolben wird wohl auch eine ziemlich Trägheit mitbringen, oder?
https://github.com/TomMajor/SmartHome/raw/master/HB-UNI-Sensor1/Images/DS18B20_Pin_Assignment.jpg
Ja, hab ich schon versucht. Hab den Sensor reingeholt und komplett durchgelüftet. Wurde zwar besser, aber zeigt systematisch z.B. innen ~40% an während mehrere anderen Sensor 32% zeigen. Dann hab ich ihn wieder auf den Balkon gehängt und da war er sofort wieder bei 95-100%...
Hab ihn dann gegen ein anderes Exemplar getauscht und dann war es sofort i.O. Ist mir nicht klar, was das los ist... Werde jetzt auf einen SHT-35 umsteigen probeweise bzw. DS18.
Ja, der DS18B20 steht beim Unisensor zumeist frei an seinen 3 Beinchen auf der Platine und zeigt damit die geringste Trägheit. Diese Teile im Kolben sind m.E. nur für Messungen in Flüssigkeitssonden sinnvoll. Ich verwende ansonsten SHT31/35 auf Breakouts, aber nur für die Feuchtigkeit. Einen BME280 hatte ich auf dem Balkon, wo er nach einigen Monaten ebenfalls gelegentlich auf 100 % ging und letztendlich dort blieb. Zum Schluß zeigte er auch einen positiven Temperaturoffset und Ausfälle auch beim Druck. Vor einiger Zeit habe ich ihn im Backofen bei 120 °C getrocknet, was ihn wohl leidlich "repariert" hat. Er zeigt aber danach immer noch im Innenbereich einen um 5..10 %-Punkte höheren Wert an als die SHT35. Ich bin inzwischen der Meinung daß die BME für den Freilufteinsatz nur bedingt geeignet sind, und wenn, dann an einem sehr gut geschützten Platz bzw. mit einer Goretex-Schutzkappe o.ä. Selbst wenn es draußen Nebel gibt und er in Kontakt mit dem Sensor kommt, übersättigt er und das war es dann.
Die Sensorträgheit kann man mit einer guten Durchströmung des Sensorgehäuses zwar reduzieren, aber am Ende hat man eben immer die Masse des Boards unter dem Sensor, angekoppelt über die Lötpads. Durch entsprechendes Freifräsen kann man die Kopplung reduzieren, oder durch Kontaktierung mit Drähtchen. Beim SHT10 auf der Mikroplatine ging das noch, die SHT35 habe ich bisher nur auf großen Platinen gesehen. Andererseits muß man sich auch fragen, mit welcher Trägheit man in seinem Anwendungsfall leben kann...
Diese Folie hier im Bild meinte ich beim SHT30 Breakout, eventuell ist die zur thermischen Isolierung?
https://www.amazon.de/SHT30-D-Temperature-Humidity-Breakout-Temperatur-Luftfeuchtigkeitssensor/dp/B07S1FLHTC (https://www.amazon.de/SHT30-D-Temperature-Humidity-Breakout-Temperatur-Luftfeuchtigkeitssensor/dp/B07S1FLHTC)
Stimme Gernott zu bzgl. BME280 außen. Meine Erfahrungen nach ca. 2,5 Jahren HB-UNI-Sensor1 außen sind bzgl. BME auch nicht so doll, sowohl Werte für Luftdruck und bes. Feuchtigkeit.
Hauptproblem war bei mir aber immer mal wieder das Nicht mehr Melden des Sensors bei der Zentrale vor allem bei Minusgraden. Spannung war dabei immer ok, brauchte nur einen Reset.
Habe deswegen im Winter einen Prototyp mit extra ATtiny als "Message Watchdog" gebaut, seitdem gibt es keine Probleme mehr.
Deshalb werde wohl ich in den nächsten Monaten noch mal eine neue Revision der HB-UNI-Sensor1 machen, mit Watchdog und dann vlt. gleich ein SHT3x Breakout mit vorsehen.
Bis auf das Winterproblem lief der Sensor aber ziemlich stabil, auch die Batterien musste ich erst nach 2 Jahren wechseln. :)
Zitat von: Tom Major am 03 April 2021, 15:17:15
Diese Folie hier im Bild meinte ich beim SHT30 Breakout, eventuell ist die zur thermischen Isolierung?
https://www.amazon.de/SHT30-D-Temperature-Humidity-Breakout-Temperatur-Luftfeuchtigkeitssensor/dp/B07S1FLHTC (https://www.amazon.de/SHT30-D-Temperature-Humidity-Breakout-Temperatur-Luftfeuchtigkeitssensor/dp/B07S1FLHTC)
Stimme Gernott zu bzgl. BME280 außen. Meine Erfahrungen nach ca. 2,5 Jahren HB-UNI-Sensor1 außen sind bzgl. BME auch nicht so doll, sowohl Werte für Luftdruck und bes. Feuchtigkeit.
Hauptproblem war bei mir aber immer mal wieder das Nicht mehr Melden des Sensors bei der Zentrale vor allem bei Minusgraden. Spannung war dabei immer ok, brauchte nur einen Reset.
Habe deswegen im Winter einen Prototyp mit extra ATtiny als "Message Watchdog" gebaut, seitdem gibt es keine Probleme mehr.
Deshalb werde wohl ich in den nächsten Monaten noch mal eine neue Revision der HB-UNI-Sensor1 machen, mit Watchdog und dann vlt. gleich ein SHT3x Breakout mit vorsehen.
Bis auf das Winterproblem lief der Sensor aber ziemlich stabil, auch die Batterien musste ich erst nach 2 Jahren wechseln. :)
Das in Deinem Link sieht tatsächlich wie eine Art Spacer aus, um den Sensor etwas vom Brett zu separieren. Habe ich bei meinen China-Teilen noch nie gesehen. Ich kann mir aber nicht vorstellen, daß es viel bringt, weil ich ja noch die metallischen Wärmebrücken der Lötstellen habe. Aber, vielleicht ist der Chip ja davon intern durch Bondingdrähte entkoppelt.
Meinen BME hatte ich als Zusatzsensor an einem Feinstaubsensor mit ESP, der immer am Strom hing. Da das Teil aber nicht wirklich gut geschützt war und bei stärkerem Wind eben doch direkt nasse Luft abbekam, habe ich den BME nun wieder entfernt. Den Luftdruck kann man auch im Innenraum messen und fürs Außenklima habe ich noch einen originalen HM-Aussensensor unterm Dachvorsprung hängen, der zuverlässig arbeitet und sich nur nach dem Batteriewechsel etwas zickig anstellt, bis er wieder Daten liefert.
Vielen Dank an euch für die wertvollen Infos. Hilft auf jeden Fall sehr.
Und ja, ansonsten läuft der Sensor absolut top und ich musste bisher keine Batterien wechseln! Vor allem auch die super Dokumentation zum Sensor ist Gold wert und hat erst einem Laien wie mir ermöglicht, den Sensor zu bauen und sich da einzuarbeiten ohne jeden Tag zig Anfängerfragen stellen zu müssen. Also nochmals vielen Dank für die klasse Arbeit!
Zitat von: frank am 08 März 2021, 14:52:05
noch zur info:
wenn man eigene register in der homebrew.pm definiert und in der definition "literals" bestimmt, erwartet cul_hm "neuerdings?" auch den hash {litInv}, in dem die keys/values zu {lit} getauscht sind.
beim einlesen der HMConfig.pm wird das am ende automatisch gemacht:
foreach my $rN (keys %culHmRegDefine) {#create literal inverse for fast search
if ($culHmRegDefine{$rN}{lit}){# literal assigned => create inverse
foreach my $lit (keys %{$culHmRegDefine{$rN}{lit}}){
$culHmRegDefine{$rN}{litInv}{$culHmRegDefine{$rN}{lit}{$lit}}=$lit;
}
}
}
für einzelne neue register kann man das ja direkt definieren.
für das (schlechte, weil überflüssige) beispiel mit ledMode dann so:
$HMConfig::culHmRegDefine{'ledMode'} = {a=> 5.6,s=>0.2,l=>0,min=>0 ,max=>1 ,p=>'n',c=>'lit',f=>'',u=>'' ,d=>0,t=>'LED mode',lit=>{off=>0,on=>1}, litInv=>{0=>'off', 1=>'on'}};
Hi frank,
ich baue gerade an einer neuen Firmware für den HB-UNI-Sensor1 mit eine paar neuen Params, und bei der Gelegenheit könnte ich was im Perl Skript ändern. Muss allerdings dazu sagen dass meine FHEM und Perl Kenntnisse immer mehr verblassen.
- hier muss das letzte Komma ganz hinten weg, richtig? (Vorlage war von Dirk)
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/FHEM/HMConfig_UniSensor1.pm#L7 (https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/FHEM/HMConfig_UniSensor1.pm#L7)
- diese Zeile kann weg weil Reg. 5, die oberen 2 Bit immer/default? für den LEDMode verwendet werden, also ist diese Zeile überflüssig?
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/FHEM/HMConfig_UniSensor1.pm#L11 (https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/FHEM/HMConfig_UniSensor1.pm#L11)
- das mit den altitude habe ich nicht verstanden. Klar sind die Regs dafür unterschiedlich zwischen Dirks altem Sensor (https://github.com/kc-GitHub/Wettersensor/blob/master/Contrib/FHEM/HMConfig_SenTHPL.pm) und meiner Weiterentwicklung. Aber Dirk hatte ja DeviceModel F101/F102 während ich F103 habe, also komplett verschiedenen Geräte, zumindest für RaspberryMatic/CCU.
hallo tom,
Zitathier muss das letzte Komma ganz hinten weg, richtig? (Vorlage war von Dirk)
ja. da kein weiteres listenelement mehr kommt, gab es ein perl warning.
registernach meinem aktuellen verständnis sieht es aktuell so aus:
- register werden in fhem eindeutig über den registernamen definiert und identifiziert (unabhängig von modelID).
- registernamen existieren daher maximal einmal fhemweit.
- bei fhemstart werden zuerst alle register in HMConfig.pm definiert, anschliessend die homebrew addons.
- wird ein registername 2 mal definiert, überschreibt die 2. definition die erste definition.
- unterschiedliche devices, die den selben registernamen verwenden, nutzen die selbe registerdefinition.
Zitat- das mit den altitude habe ich nicht verstanden. Klar sind die Regs dafür unterschiedlich zwischen Dirks altem Sensor und meiner Weiterentwicklung. Aber Dirk hatte ja DeviceModel F101/F102 während ich F103 habe, also komplett verschiedenen Geräte, zumindest für RaspberryMatic/CCU.
je nach reihenfolge der abarbeitung der homebrew addons bei fhemstart "gewinnt" die letzte definition von altitude.
Zitatdiese Zeile kann weg weil Reg. 5, die oberen 2 Bit immer/default? für den LEDMode verwendet werden, also ist diese Zeile überflüssig?
das register ledMode existiert bereits in HMConfig.pm, wodurch diese weitere definition von ledMode gewinnt.
im
prinzip sind beide definitionen identisch.
es gibt aber mittlerweile eine besonderheit bei den definitionen von "literals", erkennbar durch c=>'lit'.
die genaue beschreibung der literals steht dann in lit=>{off=>0,on=>1}.
martin hat irgendwann, scheinbar zum schnelleren durchsuchen, auch eine "inverse" beschreibung der literals in der register definition eingeführt: litInv=>{0=>'off', 1=>'on'}.
in HMConfig.pm hat er es dadurch gelöst, dass er am ende von HMConfig.pm über eine funktion alle registerdefinitionen, die "lit" enthalten, mit der entsprechenden inversen beschreibung "litInv" ergänzt.
die "unvollständige" definition von ledMode im addon gewinnt und daher funktionieren die literals beim register ledMode dann in keinem device.
daher die ledMode definition löschen, denn sie ist überflüssig und kontraproduktiv.
ich denke, grundsätzlich sollte man nach vorhandenen registernamen in HMConfig.pm suchen und diese nutzen, wenn es passt.
kompliziert wird es mit mehreren addons, die zusätzliche register mit selbem namen aber unterschiedlichen definitionen nutzen.
daher gibt es auch in HMConfig.pm mehrere unterschiedliche lowBatLimit register:
lowBatLimit =>{a=> 18.0,s=>1.0,l=>0,min=>"10.0" ,max=>12 ,c=>'' ,p=>'n',f=>10 ,u=>'V' ,d=>1,t=>"low batterie limit, step .1V"},
lowBatLimitBA =>{a=> 18.0,s=>1.0,l=>0,min=>"5.0" ,max=>15 ,c=>'' ,p=>'n',f=>10 ,u=>'V' ,d=>0,t=>"low batterie limit, step .1V"},
lowBatLimitBA2 =>{a=> 18.0,s=>1.0,l=>0,min=>"0.0" ,max=>15 ,c=>'' ,p=>'n',f=>10 ,u=>'V' ,d=>0,t=>"low batterie limit, step .1V"},
lowBatLimitBA3 =>{a=> 18.0,s=>1.0,l=>0,min=>"0.0" ,max=>12 ,c=>'' ,p=>'n',f=>10 ,u=>'V' ,d=>0,t=>"low batterie limit, step .1V"},
lowBatLimitFS =>{a=> 18.0,s=>1.0,l=>0,min=>"2.0" ,max=>3 ,c=>'' ,p=>'n',f=>10 ,u=>'V' ,d=>0,t=>"low batterie limit, step .1V"},
lowBatLimitRT =>{a=> 18.0,s=>1.0,l=>0,min=>"2.0" ,max=>2.5 ,c=>'' ,p=>'n',f=>10 ,u=>'V' ,d=>0,t=>"low batterie limit, step .1V"},
am einfachsten wäre es wohl, wenn jedes homebrew addon bei eigenen register definitionen auch eindeutige registernamen vergibt, damit bei mehreren addons keine doppeldefinitionen entstehen können.
gruss frank
Hi frank,
ich danke dir für deine ausführlichen Erläuterungen.
Habe alles soweit verstanden, wobei mich die Tatsache des Überschreibens von Registerdefinitionen aufgrund eines gleichen Registernamens bei ganz unterschiedlichen Geräten doch sehr erstaunt. Das scheint ein fehleranfälliges Konzept zu sein um es vorsichtig auszudrücken ;)
Die von dir zitierten lowBatLimitXX Stellen zeigen das auch.
Bei Original HM kann man natürlich gleiche Namen haben, die auf unterschiedliche Reg.addr. zeigen können - solange die Geräte über das DeviceModel unterschiedlich sind und ein xml für das Gerät existiert ist alles gut.
Anyway, ich habe den HB-UNI-Sensor1 Skript nach deinen Hinweisen upgedatet, in der Hoffnung damit ein paar weniger Probleme bei FHEM Verwendern dieses Sensors zu haben.
ledMode ist ganz raus, und lowBatLimit sowie altitude haben ein US1 hinten dran bekommen.
https://github.com/TomMajor/SmartHome/commit/897884b09a93cd15507d5040df20aefe0a1dfdc6 (https://github.com/TomMajor/SmartHome/commit/897884b09a93cd15507d5040df20aefe0a1dfdc6)
Danke!
p.s. HMConfig_UniSensor1.pm in HMConfig_UniSensor1_fw0x13.pm umbenannt da es bald ein neues Skript für Firmware 1.4 geben wird.
Hallo Tom Major,
beim laden der HMConfig_UniSensor1_fw0x13.pm leider eine Fehlermeldung
Undefined subroutine &main::HMConfig_UniSensor1_fw0x13_Initialize called at fhem.pl line 2692.
Kennst Du das Problem?
Fehlt dem System noch etwas?
Danke und Gruß
Alex
kein reload, sondern fhem durchstarten.
Das habe ich auch versucht, leider liefert der Sensor keine Daten:
Internals:
DEF 2B635A
FUUID 607d6784-f33f-69d4-ff06-ef98fca4bb27f1a1
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 6
NAME Unisensor_1
NOTIFYDEV global
NR 239
NTFY_ORDER 50-HM_2B635A
STATE ???
TYPE CUL_HM
chanNo 01
lastMsg No:03 - t:10 s:2B635A d:110280 02220023000000
nanoCUL_MSGCNT 6
nanoCUL_RAWMSG A100380102B635A11028002220023000000::-55:nanoCUL
nanoCUL_RSSI -55
nanoCUL_TIME 2021-04-19 20:04:55
protLastRcv 2021-04-19 20:04:55
protRcv 6 last_at:2021-04-19 20:04:55
protResnd 1 last_at:2021-04-19 20:04:45
protSnd 4 last_at:2021-04-19 20:04:55
protState CMDs_done
rssi_at_nanoCUL cnt:6 min:-60 max:-54 avg:-55.5 lst:-55
Helper:
DBLOG:
D-firmware:
logdb:
TIME 1618833885.85173
VALUE 1.3
D-serialNr:
logdb:
TIME 1618833885.85173
VALUE TTO6050078
cfgState:
logdb:
TIME 1618833894.78004
VALUE updating
commState:
logdb:
TIME 1618833895.18057
VALUE CMDs_done
READINGS:
2021-04-19 19:21:46 CommandAccepted yes
2021-04-19 20:04:45 D-firmware 1.3
2021-04-19 20:04:45 D-serialNr TTO6050078
2021-04-19 20:04:55 PairedTo 0x110280
2021-04-19 20:04:55 RegL_00. 00:00 05:40 0A:11 0B:02 0C:80 12:15 14:06 20:02 21:58 22:00 23:00
2021-04-19 20:04:54 cfgState updating
2021-04-19 20:04:55 commState CMDs_done
helper:
HM_CMDNR 3
PONtest 1
cSnd 011102802B635A00040000000000,011102802B635A00040000000000
mId no
supp_Pair_Rep 0
cmds:
TmplKey :no:1618833890.75
TmplTs 1618833890.75
cmdKey 1:1:0::Unisensor_1:no:01:
cmdLst:
clear (readings|all)
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
tplDel -tplDel-
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
listDevice [({all}|alive|unknown|dead|notAlive)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
status noArg
tplInfo noArg
expert:
def 0
det 0
raw 1
tpl 0
io:
flgs 0
newChn +2B635A,00,00,00
nextSend 1618833895.2722
rxt 0
vccu VCCU
p:
2B635A
00
00
00
prefIO:
nanoCUL
mRssi:
mNo 03
io:
nanoCUL:
-49
-49
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rssi:
at_nanoCUL:
avg -55.5
cnt 6
lst -55
max -54
min -60
shadowReg:
tmpl:
Attributes:
IODev nanoCUL
IOgrp VCCU:nanoCUL
autoReadReg 4_reqStatus
expert rawReg
firmware 1.3
model unknown
serialNr TTO6050078
subType no
die attribute model und subType fehlen.
Die Attribute können aber nicht eingetragen werden, ich hätte erwartet dass das Modul es erkennt.
sollte grundsätzlich auch automatisch funktionieren.
aber nur, wenn fhem das model vor dem anlernen kennt.
mir fallen 3 möglichkeiten zum "reparieren" ein:
1. "countdown" am sensor auslösen, oder
2. drüber pairen, oder
3. model und subtype manuell in fhem.cfg schreiben.
Hi Frank,
2 und 3 hat leider nichts gebracht, model und subtype wird leider relativ schnell überschrieben.
Der Sensor hat an einer Raspberrymatic problemlos funktioniert, ich verstehe nicht warum er am nano CUL nicht mehr will.
Gruß
Alex
3. funktioniert immer.
fhem mit der geänderten fhem.cfg durchstarten.
In meinem Fall leider nicht.
ich stoppe FHEM, ändere Model und subtype, danach starte ich wieder FHEM.
Nach dem Start stehen die Attribute auch im Device, aber dda steht auch CMDs pending.
Internals:
DEF 2B635A
FUUID 607d8800-f33f-69d4-d354-90d7f512fa957968
IODev nanoCUL
NAME HM_2B635A
NOTIFYDEV global
NR 239
NTFY_ORDER 50-HM_2B635A
STATE ???
TYPE CUL_HM
chanNo 01
READINGS:
2021-04-19 21:39:45 D-firmware 1.3
2021-04-19 21:39:45 D-serialNr TTO6050078
2021-04-19 21:39:12 commState CMDs_pending
helper:
HM_CMDNR 84
mId F103
peerFriend
peerOpt p:UniSensor1
regLst 0
rxType 156
cmds:
TmplKey :no:1618841634.86788
TmplTs 1618841634.86788
cmdKey 1:1:0::HM_2B635A:F103:01:
cmdLst:
assignHmKey noArg
burstXmit noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate <filename> <bootTime> ...
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getSerial noArg
getVersion noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 <actChn> ... single [set|unset] [actor|remote|both]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
statusRequest noArg
tplDel -tplDel-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 0
det 0
raw 1
tpl 0
io:
flgs 0
newChn +2B635A,00,00,00
rxt 2
vccu VCCU
p:
2B635A
00
00
00
prefIO:
nanoCUL
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf 00
qReqStat 00
role:
chn 1
dev 1
tmpl:
Attributes:
IODev nanoCUL
IOgrp VCCU:nanoCUL
autoReadReg 4_reqStatus
expert rawReg
firmware 1.3
model HB-UNI-Sensor1
serialNr TTO6050078
subType UniSensor1
Drücke ich dann den button am Sensor, werden die Attribute überschrieben.
Internals:
DEF 2B635A
FUUID 607d8800-f33f-69d4-d354-90d7f512fa957968
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 3
NAME HM_2B635A
NOTIFYDEV global
NR 239
NTFY_ORDER 50-HM_2B635A
STATE ???
TYPE CUL_HM
chanNo 01
lastMsg No:30 - t:10 s:2B635A d:110280 02220023000000
nanoCUL_MSGCNT 3
nanoCUL_RAWMSG A103080102B635A11028002220023000000::-55.5:nanoCUL
nanoCUL_RSSI -55.5
nanoCUL_TIME 2021-04-19 22:17:39
protLastRcv 2021-04-19 22:17:39
protRcv 3 last_at:2021-04-19 22:17:39
protSnd 2 last_at:2021-04-19 22:17:39
protState CMDs_done
rssi_at_nanoCUL cnt:3 min:-55.5 max:-55.5 avg:-55.5 lst:-55.5
Helper:
DBLOG:
D-firmware:
logdb:
TIME 1618841850.35531
VALUE 1.3
D-serialNr:
logdb:
TIME 1618841850.35531
VALUE TTO6050078
cfgState:
logdb:
TIME 1618841859.39297
VALUE updating
commState:
logdb:
TIME 1618841859.79933
VALUE CMDs_done
READINGS:
2021-04-19 22:17:30 D-firmware 1.3
2021-04-19 22:17:30 D-serialNr TTO6050078
2021-04-19 22:17:39 PairedTo 0x110280
2021-04-19 22:17:39 RegL_00. 00:00 05:40 0A:11 0B:02 0C:80 12:15 14:06 20:02 21:58 22:00 23:00
2021-04-19 22:17:39 cfgState updating
2021-04-19 22:17:39 commState CMDs_done
helper:
HM_CMDNR 48
cSnd ,011102802B635A00040000000000
mId no
peerFriend
peerOpt p:UniSensor1
regLst 0
supp_Pair_Rep 0
cmds:
TmplKey :no:1618841855.35518
TmplTs 1618841855.35518
cmdKey 1:1:0::HM_2B635A:no:01:
cmdLst:
assignHmKey noArg
clear (readings|all)
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
tplDel -tplDel-
unpair noArg
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
listDevice [({all}|alive|unknown|dead|notAlive)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
status noArg
tplInfo noArg
expert:
def 0
det 0
raw 1
tpl 0
io:
flgs 0
newChn +2B635A,00,00,00
nextSend 1618841859.88836
rxt 0
vccu VCCU
p:
2B635A
00
00
00
prefIO:
nanoCUL
mRssi:
mNo 30
io:
nanoCUL:
-49.5
-49.5
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat 00
regCollect:
role:
chn 1
dev 1
rssi:
at_nanoCUL:
avg -55.5
cnt 3
lst -55.5
max -55.5
min -55.5
shadowReg:
tmpl:
Attributes:
IODev nanoCUL
IOgrp VCCU:nanoCUL
autoReadReg 4_reqStatus
expert rawReg
firmware 1.3
model unknown
serialNr TTO6050078
subType no
ist dein fhem up-to-date?
was passiert, wenn du zusätzlich zu model und subtype noch "attr HM_2B635A .mId F103" in fhem.cfg einfügst?
der punkt ist wichtig.
ich habe am WE die Firmware für den HB-UNI-Sensor1 auf 1.4 aktualisiert. Hauptänderung ist, es können nun Offsetwerte für Temperatur, Luftdruck und Luftfeuchte über das WebUI (CCU) eingestellt werden.
Für FHEM habe ich auch den Skript aktualisiert, allerdings kann ich es nicht testen.
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/FHEM/HMConfig_UniSensor1_fw0x14.pm (https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/FHEM/HMConfig_UniSensor1_fw0x14.pm)
Nach Franks Ausführungen hier letzte Woche ist für die 3 neuen Parameter ein US1 am Namen angehängt um Konflikte mit bereits bestehenden Definitionen aus dem Weg zu gehen.
Hallo Frank,
dank deinem Hinweis auf die ModelID bin ich auf die Lösung gekommen, danke dafür.
Bevor mir mein HM-MOD-UART abgeraucht ist, hatte ich den Sensor mit einer Raspberrymatic genutzt und dafür habe ich den Sensor mit dem Model F112 geflasht, damit kann FHEM mit nanoCUL nichts anfangen. Also kurzerhand mit F103 neu kompiliert und siehe da, es läuft.
@Tom Major
seit der Version 1.4 ist bei mir leider die Luftfeuchtigkeit anscheinend um Faktor 10 zu niedrig, wo müsste ich da etwas anpassen?
Gruß
Alex
ZitatBevor mir mein HM-MOD-UART abgeraucht ist, hatte ich den Sensor mit einer Raspberrymatic genutzt und dafür habe ich den Sensor mit dem Model F112 geflasht, damit kann FHEM mit nanoCUL nichts anfangen.
hättest du rechtzeitig bescheid gesagt, hättest du dir das flashen ersparen können.
eine kleine änderung im fhem addon file hätte genügt. ;)
Das flashen war ja auch schnell gemacht ;)
Hallo Zusammen,
ich nutze hier schon seit ein paar Jahren den Sensor fertig gekauft von Dirk (meine Ich), der funktioniert immer noch einwandfrei. Jetzt würde ich gern einen 2. Sensor für unsere Westseite für die Beschattungsregelgung haben.
Hat zufällig jemand noch einen fertigen Sensor zu verkaufen?
Gruß
Jens
Hm, meine SHTs aus China sind endlich da. Hab mir SHT-31 und SHT-35 bestellt. Der 35 hat ja angeblich eine Temperaturgenauigkeit von +/- 0,1 °C.
Jetzt sehe ich aber in der Software, dass nur der SHT31 unterstützt wird, oder?
//#define SENSOR_DS18X20 // ONEWIRE_PIN define weiter unten muss zur HW passen! DS18X20_COUNT muss definiert sein!
#define SENSOR_BME280 // BME280 Library (finitespace) verwendet I2C Addr. 0x76, für 0x77 die Library anpassen!
//#define SENSOR_BMP180
#define SENSOR_MAX44009 // MAX44009_ADDR define weiter unten muss zur HW passen!
//#define SENSOR_TSL2561 // TSL2561_ADDR define weiter unten muss zur HW passen!
//#define SENSOR_BH1750 // BH1750_ADDR define weiter unten muss zur HW passen!
//#define SENSOR_SHT31 // SHT31_ADDR define weiter unten muss zur HW passen!
//#define SENSOR_SHT21
//#define SENSOR_SHT10 // SHT10_DATAPIN / SHT10_CLKPIN define weiter unten muss zur HW passen!
//#define SENSOR_DIGINPUT // DIGINPUT_PIN define weiter unten muss zur HW passen!
//#define SENSOR_VEML6070
//#define SENSOR_VEML6075
Oder sind die irgendwie kompatibel?
Zitat von: vbs am 04 Mai 2021, 18:47:32
Hm, meine SHTs aus China sind endlich da. Hab mir SHT-31 und SHT-35 bestellt. Der 35 hat ja angeblich eine Temperaturgenauigkeit von +/- 0,1 °C.
Oder sind die irgendwie kompatibel?
Auf den ersten schnellen Blick sieht es für mich so aus als ob der -35 nur in der factory bzgl. Genauigkeit selektiert wird, sonst alles gleich.
Sollte also mit dem -31 define auf Anhieb funktionieren.
Oh Mann, danke, du bist schnell, klappt super! :D
Ich war schon dabei, die Lib von hier einzubinden, aber das kann ich mir ja nun sparen...
https://github.com/Seeed-Studio/Seeed_SHT35
Schon wieder ich:
Ich hab jetzt die Firmware auf den aktuellen Stand gebracht und dabei hat sich der Wertebereich des Helligkeitssensors (MAX44009) irgendwie verschoben:
Mein bisheriger Stand war 30fd9b1db47bcbb553e66099b3f8ac917b025bad vom 5.4.2019, nun bin ich auf 8406d9faa2c2aa61a83938a94858b8e7b7ab8435 vom 18.4.2021.
Mit dem alten Stand liefert der Sensor hier auf dem Schreibtisch Werte bei ca. 5 Lux, der neue Stand ungefähr 500 Lux. Wird aber gerade im Minutentakt dunkler draußen, also nicht zu genau nehmen die Zahlen.
Gab es da eine Änderung beim Auslesen des MAX? Oder mach ich was falsch? Wenn das jetzt so ist, ist das ja erstmal kein Problem. Ich muss dann in FHEM nur meine Schwellwerte für die Lichtsteuerung anpassen.
Danke!
Also der Commit baut offenbar einen Faktor 100 ein, was auch gut im Code zu sehen ist. Ich muss also gucken, ob ich das selbst in FHEM durch 100 teilen muss. Oder evtl. dieses HM-Perl-Script updaten? Ich forsche mal weiter...
Revision: 3422b9d69f7ad2ef3013a3486214508d2b166b78
Author: TomMajor <fake34zg42hwqf@byom.de>
Date: 09.04.2019 19:51:33
Message:
Increase MAX44009 resolution to two decimal places
----
Modified: HB-UNI-Sensor1/CCU_RM/src/addon/firmware/rftypes/hb-uni-sensor1.xml
Added: HB-UNI-Sensor1/CCU_RM/src/addon/firmware/rftypes/hb-uni-sensor1_fw0x12.xml
Modified: HB-UNI-Sensor1/Sensors/Sens_BME280.h
Modified: HB-UNI-Sensor1/Sensors/Sens_MAX44009.h
Modified: HB-UNI-Sensor1/Sensors/Sens_TSL2561.h
Zitat von: vbs am 05 Mai 2021, 21:08:12
Schon wieder ich:
Ich hab jetzt die Firmware auf den aktuellen Stand gebracht und dabei hat sich der Wertebereich des Helligkeitssensors (MAX44009) irgendwie verschoben:
Mein bisheriger Stand war 30fd9b1db47bcbb553e66099b3f8ac917b025bad vom 5.4.2019, nun bin ich auf 8406d9faa2c2aa61a83938a94858b8e7b7ab8435 vom 18.4.2021.
Mit dem alten Stand liefert der Sensor hier auf dem Schreibtisch Werte bei ca. 5 Lux, der neue Stand ungefähr 500 Lux. Wird aber gerade im Minutentakt dunkler draußen, also nicht zu genau nehmen die Zahlen.
Gab es da eine Änderung beim Auslesen des MAX? Oder mach ich was falsch? Wenn das jetzt so ist, ist das ja erstmal kein Problem. Ich muss dann in FHEM nur meine Schwellwerte für die Lichtsteuerung anpassen.
Danke!
Hmm, bin nicht sicher. Der Stand von 2019 ist sehr alt, da ist eine Menge passiert. Das mit Faktor 100 beim Lux klingt nach der Anpassung als ich dem Lux 2 Nachkommastellen spendiert hatte. Das ist aber auch schon ewig her und hat nichts mit den jüngsten Änderungen "Offsetwerte für Temperatur, Luftdruck und Luftfeuchte" zu tun.
Hast du auch das neue HMConfig_UniSensor1_fw0x14.pm geladen? Das wäre das richtige für die aktuelle Firmware 1.4.
Darin wird ja auch der Lux skaliert:
# brightness, int with scaling factor 100 from device to get two decimal places
my $brightness = sprintf('%.2f', $brightness100 / 100);
$stateMsg .= ' B: ' . $brightness;
push (@events, [$shash, 1, 'brightness:' . $brightness]);
Hi Tom, ja genau, das hab ich gerade installiert und jetzt funktioniert es! Danke dir!
Zitat von: vbs am 05 Mai 2021, 23:32:18
Hi Tom, ja genau, das hab ich gerade installiert und jetzt funktioniert es! Danke dir!
Gerne ;)
Hoffe du hast keinen Mischbetrieb aus verschiedenen Firmwares. Das wäre schwierig glaub ich..
Nee nee, nur einen Sensor UNISENSOR ;)
ich habe die letzten Tage die Firmware für den HB-UNI-Sensor1 auf 1.5 aktualisiert. Hauptänderung ist die Unterstützung für die zusätzliche Datenpunkte 'absolute Luftfeuchte' (g/m3) und 'Taupunkt'.
Hintergrund ist das ich mit der Differenz der absoluten Luftfeuchte zwischen innen und außen eine Lüftungssteuerung für die Garage realisiere, siehe auch hier (https://homematic-forum.de/forum/viewtopic.php?f=76&t=67720&start=30#p665926).
Für FHEM habe ich auch den Skript aktualisiert, allerdings kann ich es nicht testen.
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/FHEM/HMConfig_UniSensor1_fw0x15.pm
HB-UNI-Sensor1, Support für Temperatur/Feuchtesensor AHT15 hinzugefügt.
siehe auch AHT15 ...mögliche robuste Alternative zum SHT21/31 (https://homematic-forum.de/forum/viewtopic.php?f=76&t=69004)
Moin zusammen,
nachdem die Hardware jahrelang bei mir rumgelegen war, habe ich nun endlich mal den Sensor zusammengelötet und in Betrieb genommen (nach dieser Anleitung (https://technikkram.net/blog/2018/05/30/homematic-diy-projekt-thermometer-und-hydrometer-fertige-platine-im-eigenbau/), allerdings mit dem Sketch von Jérôme (https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/HM-WDS40-TH-I-BME280/HM-WDS40-TH-I-BME280.ino), da anscheinend mit dem ursprünglichen Sketch auf der Technikkram-Seite der Luftdruck nicht verarbeitet wird.
Im RaspiMatic klappt das Anlernen nach der Installation des AskSin Addons auf Anhieb; in fhem nicht:
2021.11.01 19:38:45 3: CUL_HM set vccu hmPairForSec 120
2021.11.01 19:38:51 1: CUL_HM Unknown device HM_F30701 is now defined
2021.11.01 19:38:51 3: CUL_HM received config CCU:vccu device: HM_F30701. PairForSec: on PairSerial:
2021.11.01 19:38:51 3: CUL_HM pair: HM_F30701 no, model unknown serialNr
2021.11.01 19:38:51 2: HMinfo hm get:configCheck :-f,^(HM_F30701|HM_F30701)$
2021.11.01 19:39:36 3: CUL_HM received config CCU:vccu device: HM_F30701. PairForSec: on PairSerial:
2021.11.01 19:39:36 3: CUL_HM pair: HM_F30701 no, model unknown serialNr JPTHPO0001
2021.11.01 19:39:41 2: HMinfo hm get:configCheck :-f,^(HM_F30701|HM_F30701)$
2021.11.01 19:39:45 3: CUL_HM set HM_F30701 getConfig noArg
2021.11.01 19:39:45 2: HMinfo hm get:configCheck :-f,^(HM_F30701|HM_F30701)$
Habe ich das richtig verstanden (irgendwo in diesem Monster-Thread war die Rede von einem fhem Addon), dass man auch für fhem zusätzlich etwas installieren muss, damit die Devices entsprechend erkannt und angelegt werden? Und wenn ja: Was?
Vielen Dank & viele Grüße
Martin
Ungeduldsgetriebene Selbsthilfe hat funktioniert: pm Files (https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM) kopiert, dann habe ich den HB-UNI-Sensor1-THPD-BME280-Sketch geflashed; beim zweiten Pairing-Versuch ist das dann wie erhofft in fhem aufgetaucht.
Das ist schon eine erstklassige und sehr beeindruckende Arbeit, die Ihr hier mit den Hausbrauerei-Projekten macht. Vielleicht etwas verwirrend für jene, die wie ich nicht so tief in der Materie stecken, wegen der Fülle an Optionen: Auf mein Sensor-Gelöte etwa habe ich nun den dritten Sketch geflashed, alle funktionieren, haben aber unterschiedliche Anforderungen und Nebenwirkungen.
Wenn ich etwas zur Dokumentation (Wiki?) beitragen kann - will keinem zuvorkommen - gerne.
Grüße
Martin
Zitat von: dadoc am 02 November 2021, 19:01:57
Auf mein Sensor-Gelöte etwa habe ich nun den dritten Sketch geflashed, alle funktionieren, haben aber unterschiedliche Anforderungen und Nebenwirkungen.
Wenn ich etwas zur Dokumentation (Wiki?) beitragen kann - will keinem zuvorkommen - gerne.
Grüße
Martin
Falls du meine Weiterentwicklung von Dirks Sensor nicht gesehen haben solltest, das wäre dann der 4. Sketch. Da gibt es etwas Doku und auch einen Abschnitt zur FHEM Installation:
https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1)
Zitat von: Tom Major am 03 November 2021, 12:04:41
Falls du meine Weiterentwicklung von Dirks Sensor nicht gesehen haben solltest, das wäre dann der 4. Sketch.[/url]
Ich hatte es so verstanden, dass HB-UNI-Sensor1-THPD-BME280 von hier (https://github.com/FUEL4EP/HomeAutomation/tree/master/AsksinPP_developments/sketches/HB-UNI-Sensor1-THPD-BME280) wiederum eine Weiterentwicklung Deiner Weiterentwicklung ist, denn dort liest man:
Zitatabgeleitet von Toms (TomMajor) HB-UNI-Sensor1
Aber was weiß ich schon ;-)
Grüße
Martin
Hallo,
ich habe seit Jahren schon einen Sensor von Dirk von 2014. Der hat bis vor kurzem super funktioniert, aber jetzt. Er sendet zwar Daten, aber es wird in Fhem nichts angezeigt. Die RAW Messages sehen so aus
0500003333A270A89B1323A8210000000000006400C81900
Die .pm Datei aus dem Git Hub sind installiert. Das Model wird auch als ,,HB-UW-Sen-THPL-O" erkannt.
Wer kann mir da weiter helfen? Kann ich andere FW aufspielen?
Gruß Christoph
temp und hum melden halt null. luminosity und batVoltage liefern werte.
temp/hum sensor defekt, lötstellen ok?
Ok, das bedeutet also entweder hat die Firmware auf dem Teil einen Schuss oder die Hardware hat die Segel gestrichen. Die Module sind SMD - die kann ich nicht nachlöten. Ich kann das Teil höchstens mal in den Backofen legen und hoffen, das sich die ggf. kalten Lötstellen wieder verbinden. So etwas habe ich schon mal mit einer Grafikkarte gemacht.
Kann mir jemand sagen wo auf dem Board von Dirk (Version 1.1 oder 1.2) die Serielle Schnittstelle ist? Welche Pins muss ich da nehmen?
Kurios - ein wenig drauf rumgedrückt und es geht wieder. Also doch kalte Lötstelle.
Gruß Christoph
Zitat von: Bennemannc am 08 Dezember 2021, 19:22:20
Kann mir jemand sagen wo auf dem Board von Dirk (Version 1.1 oder 1.2) die Serielle Schnittstelle ist? Welche Pins muss ich da nehmen?
Siehe Pinout von Arduino Pro Mini, die RX- und TX-Pins sind die beiden, die einer (runden) Ecke der Platine am nächsten liegen
Hallo zusammen,
ich habe mittlerweile seit Jahren mehrere Aussen-Sensoren von Dirk (mit einem SHT10 und einem TLS2561) mit der Firmware von Tom im Einsatz.
Vor einigen Monaten habe ich zur CCU3 gewechselt, seitdem bekomme ich sehr oft wenn es dunkel ist konstant einen Helligkeitswert von 1000 (in der CCU3 ist der Wert 999,99, das sieht mir irgendwie nach einem Initwert aus).
Leider greift auch der Ansatz, den Wert 1000 mit folgendem DbLogValueFn herauszufiltern nicht:
{
if (($READING eq "brightness") and ($VALUE eq 1000))
{
$IGNORE=1;
}
}
Die Einzige Lösung die ich stand heute habe ist, die Werte in der DB nachträglich zu löschen.
Wie bekomme ich das Problem in den Griff (am liebsten an der Wurzel)?
Gruß
Alex
Zitat von: Nighthawk am 15 Dezember 2021, 09:51:07
Wie bekomme ich das Problem in den Griff (am liebsten an der Wurzel)?
die Wurzel ist hier:
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/Arduino/HB-UNI-Sensor1/Sensors/Sens_TSL2561.h#L108 (https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/Arduino/HB-UNI-Sensor1/Sensors/Sens_TSL2561.h#L108)
entweder dort einen anderen Wert eintragen oder innerhalb der Klasse den letzten gültigen Wert merken und im Fehlerfall zurückgeben etc. pp.
Das ist eine Auto-ranging Funktion die ich mal in grauer Vorzeit gemacht hatte wegen
https://github.com/TomMajor/SmartHome/tree/master/Info/SensorTest_Lux (https://github.com/TomMajor/SmartHome/tree/master/Info/SensorTest_Lux)
hat vermutlich noch Verbesserungspotential für Dunkelheit..
Hallo Tom,
vielen Dank für die Rückmeldung, ich versuche mal den Wert zu verändern.
Dass das Problem erst mit der Umstellung auf die CCU3 auftauchte ist nicht ganz korrekt, denn zeitgleich habe ich von Drks Sketch zu deinem HB-UNI-Sensor1 gewechselt.
Gruß
Alex
Hallo.
Ich hoffe liest noch jemand mit. ;-)
Ich habe aktuell 4 Aussen-Sensoren von Dirk. (nur Helligkeit).
Hier ein List:
Internals:
CFGFN /var/fhem/FHEM/EG_Arbeitszimmer.cfg
DEF 3DF4DE
FUUID 5ef8ba91-f33f-a5a6-78cd-0d1b9029158614b0
IODev LGW2
LASTInputDev LGW2
LGW2_MSGCNT 2694
LGW2_RAWMSG 0501014F3BA2703DF4DEF123FF0000000000000E11DB0960
LGW2_RSSI -79
LGW2_TIME 2023-03-29 13:27:58
MSGCNT 2694
NAME EG_AZ_Helligkeitssensor
NR 499
NTFY_ORDER 48-EG_AZ_Helligkeitssensor
STATE T: 0.0 L: 9221
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
eventCount 820
lastMsg No:3B - t:70 s:3DF4DE d:F123FF 0000000000000E11DB0960
protCondBurst forced_off
protLastRcv 2023-03-29 13:27:58
protRcv 1670 last_at:2023-03-29 13:27:58
protResnd 3 last_at:2023-03-27 18:48:43
protSnd 1155 last_at:2023-03-29 13:27:58
protState CMDs_done
rssi_at_LGW2 cnt:2694 min:-91 max:-63 avg:-84.57 lst:-79
Helper:
DBLOG:
luminosity:
mylogdb:
TIME 1680089278.97016
VALUE 9221
luminosity.avg:
mylogdb:
TIME 1680089152.82347
VALUE 12921.080
READINGS:
2023-03-27 18:59:51 Activity alive
2023-03-27 18:50:25 CommandAccepted yes
2023-03-27 18:57:53 D-firmware 0.15
2023-03-27 18:57:53 D-serialNr JCR8241469
2023-03-29 13:27:58 IODev LGW2
2023-03-27 18:57:55 PairedTo 0xF123FF
2020-06-28 17:44:57 R-burstRx off
2023-03-27 18:57:55 R-pairCentral 0xF123FF
2023-03-27 18:57:55 RegL_00. 00:00 01:00 05:64 0A:F1 0B:23 0C:FF 12:10 14:03 24:00 25:00
2023-03-29 13:27:58 batVoltage 2.40
2023-03-29 13:27:58 battery ok
2023-03-27 18:54:38 cfgState updating
2023-03-29 13:27:58 commState CMDs_done
2023-03-29 13:27:58 luminosity 9221
2023-03-29 13:27:58 luminosity.avg 13033.240
2022-11-12 09:00:05 powerOn 2022-11-12 09:00:05
2023-03-26 14:36:47 recentStateType info
2023-03-29 13:27:58 state T: 0.0 L: 9221
2023-03-29 13:27:58 temperature 0.0
helper:
HM_CMDNR 59
cSnd 01F123FF3DF4DE00040000000000,01F123FF3DF4DE0103
cfgStateUpdt 0
lastMsgTm 1680089278.96124
mId F102
peerFriend peerRecT
peerIDsRaw ,00000000
peerIDsState complete
peerOpt p:THPLSensor
regLst 0
rxType 156
supp_Pair_Rep 0
cmds:
TmplKey :no:1679935829.557
TmplTs 1679935829.557
cmdKey 1:1:0::EG_AZ_Helligkeitssensor:F102:01:
cmdLst:
assignHmKey noArg
burstXmit noArg
clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
deviceRename -newName-
fwUpdate <filename> <bootTime> ...
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getSerial noArg
getVersion noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 <actChn> ... single [set|unset] [actor|remote|both]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
statusRequest noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt EG_AZ_Thermostat_Weather,EG_BZ_Thermostat_Weather,EG_EG_Thermostat_Weather,EG_Kueche_Thermostat_Weather,EG_WZ_Thermostat_Terrasse_Weather,EG_WZ_Thermostat_links_Weather,EG_WZ_Wandthermostat_Weather,OG1_AZ_Thermostat_Weather,OG1_BZ_Thermostat_Weather,OG1_Flur_Thermostat_Weather,OG1_SZ_Thermostat2_Weather,OG1_SZ_Thermostat_Weather,OG1_SZ_Wandthermostat_Weather,OG2_KZ_Thermostat_Weather,OG2_KZ_Wandthermostat_Weather
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
history:
ARRAY(0x555816b907f8)
ARRAY(0x555816c8d260)
ARRAY(0x555815e94338)
ARRAY(0x555817758e28)
ARRAY(0x5558165b8e98)
ARRAY(0x555815a0d1f0)
ARRAY(0x555816fd7620)
ARRAY(0x555815513a58)
ARRAY(0x5558162a3078)
ARRAY(0x55581503b900)
ARRAY(0x555817195860)
ARRAY(0x5558155c5bd0)
ARRAY(0x555814e4f0d8)
ARRAY(0x55581665f540)
ARRAY(0x5558169c8f98)
ARRAY(0x555816ccb3c8)
ARRAY(0x5558170c4888)
ARRAY(0x555817fe4cf8)
ARRAY(0x5558164d8858)
ARRAY(0x5558172e36b0)
ARRAY(0x555814eac1a0)
ARRAY(0x555812d15090)
ARRAY(0x555816c13300)
ARRAY(0x555816e84f68)
ARRAY(0x555817003c90)
io:
flgs 0
newChn +3DF4DE,00,01,00
nextSend 1680089279.25586
rxt 2
vccu vccu
p:
3DF4DE
00
01
00
prefIO:
LGW2
mRssi:
mNo 3B
io:
LGW2:
-77
-77
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
tryMsg:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rpt:
IO LGW2
flg A
ts 1680089278.96124
ack:
HASH(0x555812c5bb28)
3B8002F123FF3DF4DE00
rssi:
at_LGW2:
avg -84.5734966592425
cnt 2694
lst -79
max -63
min -91
shadowReg:
shadowRegChn:
RegL_00. 00
tmpl:
Attributes:
IOgrp vccu:LGW2
actCycle 000:20
actStatus alive
autoReadReg 4_reqStatus
event-min-interval luminosity:600,luminosity.avg:600
event-on-change-reading luminosity:100,luminosity.avg:100
expert defReg,rawReg
firmware 0.15
model HB-UW-Sen-THPL-O
peerIDs 00000000
room Erdgeschoss->Arbeitszimmer,Zentralsysteme->Rolladen,Zentralsysteme->Wetter
serialNr JCR8241469
subType THPLSensor
userReadings luminosity.avg {movingAverage("EG_AZ_Helligkeitssensor","luminosity",600)}
Ich steige aktuell schrittweise von CUL_HM auf HMCCU um.
Unter debmatic werden die Sensoren leider nicht unterstützt.
Die Universalsensor HB-UNI-Sensor1 aber schon.
Gibt es eine Möglichkeit die umzuflashen?
Wenn ja, gibt es hier auch jemanden der das für mich tun würde?
Gruß
Daniel
Zitat von: WhyTea am 29 März 2023, 13:35:23Gibt es eine Möglichkeit die umzuflashen?
Normalerweise sollte das per OTA gehen, siehe Wiki zum Universalsensor.
Wenn es so einfach wäre würde mir das sehr gefallen aber ich finde nirgends eine eq3 Datei die flashen könnte.
Zitat von: WhyTea am 30 März 2023, 13:51:46Wenn es so einfach wäre würde mir das sehr gefallen aber ich finde nirgends eine eq3 Datei die flashen könnte.
Man kann sich die eq3-Datei aus einer selbst kompilierten hex-Datei selbst erstellen. Siehe z.B. hier: https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware
Zitat von: WhyTea am 29 März 2023, 13:35:23Unter debmatic werden die Sensoren leider nicht unterstützt.
Die Universalsensor HB-UNI-Sensor1 aber schon.
dirk hat den notwendigen code zum erweitern der ccu in seinem github, denke ich.
https://github.com/kc-GitHub/Wettersensor/tree/master/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon-src/firmware/rftypes (https://github.com/kc-GitHub/Wettersensor/tree/master/Contrib/CCU/HB-UW-Sen-THPL_CCU-addon-src/firmware/rftypes)
wie man das einer ccu beibringt, muss ein anderer erklären.
Hallo nochmal.
Wie ich schon geschriebenhabe habe ich seit einigen Jahren 4 Sensoren (von dirk).
Da mir leider sowohl das know how als auch die Ausrüstung fehlt diese mit einer debmatic kompatiblen Firmware zu flashen frage ich einfach mal ganz direkt ob es hier jemanden gibt der mir die Sensoren umflashen könnte/würde.
Bei interesse bitte einfach per PN bei mir melden.
Gruß
Daniel
Servus,
ich habe gerade meine Universalsensor von Dirk wiederentdeckt den ich vor vielen Jahren mal gekauft hatte.
Das Modul HB-UW-Sen-THPL Addon ist immer noch auf der CCU installiert.
Jetzt wollte ich ihn wieder anlernen. Hatte ich beim Umzug mal aus der RaspMatic gelöscht.
Leider kann ich den Reset nicht machen, da die LED nicht auf Tastendruck reagiert.
Ab und zu blinkt die LED mal.
Wenn ich die Batterien neu einsetze kommen diese Blinkcodes:
6 mal ganz schnell
kurze Pause
3 mal ganz schnell
kurze Pause
3 mal schnell
Hat jemand eine Idee, wie man da Problem lösen könnte ?
Zitat von: Afterburner am 09 November 2023, 12:14:52Leider kann ich den Reset nicht machen, da die LED nicht auf Tastendruck reagiert.
welche fw ist drauf?
wie lange drückst du?
1. lange drücken, bis es blinkt => loslassen
2. dann erneut lange drücken, bis es schnell blinkt => loslassen, fertig.
FW weiß ich nicht, muss von 2020 oder früher sein. Nutze auch kein FHEM mehr, sondern IPSYMCON und da kann ich es nicht auslesen.
Habe das Problem aber jetzt identifiziert.
Der Taster ist defekt, Sensor war immer draußen.
Habe diesen mit einem Draht überbrückt und dann ging es.
Allerdings hat wohl das installierte Addon HB-UW-Sen-THPL 1.0 in der RaspMatic (Charly) nicht mehr funktioniert.
Musste dazu dieses nehmen:
https://github.com/jp112sdl/Wettersensor/tree/master/Contrib/CCURM
K.A. ob es da auch noch was originales gibt.
Jetzt funktioniert es jedenfalls wieder.