Kleine Ergänzung:
Ich habe jetzt auf ALLE BLE-Beobachter, auch die shelly-Plugs, das Script zur Meldung an IOBroker (https://github.com/iobroker-commu…/ble-devices.md) installiert. Seitdem scheint auch Ruhe zu sein. Dieses scheint ebenfalls dafür zu sorgen, dass nicht mehr so viel überhört wird. Dabei habe ich den Schalter für die Gateway-Funktion angelassen!
Ok ... dann müssen die FW ja nur angepasst werden. Der Strommehrverbrauch dürfte sich ja bei Netzgekoppelten Geräten im Rahmen halten.
Die WD scheinen für die Tickets ja kein Problem zu sein. Wenn ich alle Meine BLE-HT nur über die WD abhören lasse, sind mir nämlich noch keine Aussetzer aufgefallen. Allerdings kann man die WD aber nicht nutzen um die Meldungen auf IOBroker umzuleiten ... und man hat natürlich auch nicht überalle ein WD in der Nähe, wo man die BLE-HT einsetzen möchte.
Kurzanalyse meinerseits: es liegt am Plug-Plus. Ich habe einen BLU-HT, der nicht senden wollte. Habe diesen an einen anderen Standort verbracht. Dort hat er ebenfalls Verbindung mit einem Plug Plus. Dort geht er. Der BLU-HT, den ich dann von dort geholt habe, hat am alten Standort ebenfalls Aussetzer. Mit einem Plus1 an der Seite sind die Aussetzer per Meldung über den Plus1 weg. Also sind manche Plug Plus die Tatverdächtigen.
Der kleine Unterschied ist halt, dass man mit dem HT-GEN1 durch das WLAN weiterkommt als mit dem HT-BLU, der zusätzlich noch einen Shelly mit BT nebenan braucht ... aber ansonsten zeigt meine Testreihe ein ähnliches Ergebnis (der GEN1 läuft inkl. Korrektur der RF parallel zum BLU)
Nochmal: wenn die Spannung im Nachkommabereich abweicht, ist das wurscht ... es war nur erwähneswert ...
Viel interessanter ist, dass einer meiner 1PM+ 225 Volt meldet und stattdessen aber 236V anliegen ....
Das ist die selbe Spannung, aber ein Rundungseffekt der App macht scheinbar zwei daraus. Du misst selten mit digitalen Meßgeräten, oder? Die kleinste angezeigte Stelle darf man getrost vergessen…
Mich wundert eher, dass die Cloud zwei draus macht. Es kommt vom 2PM+ ja nur eine und die wird in der Cloud verschieden zerlegt .... ist aber auch wurscht ... ist ja nur ne Randerscheinung ... Und ich messe oft genug mit digitalen Messgeräten um den Effekt zu kennen ... allerdings, dass EINE Datenbank dann zwei Werte draus macht, ist mir neu ...
Ich habe mal probiert den AM2302 direkt auf das Addon+ zu setzen. Die Reihenfolge der Anschlüsse schreien ja förmlich danach.
Eine weniger Gute Idee. Abweichungen von etlichen Kelvin, je nach Shelly. Und dabei liegen die offen auf dem Schreibtisch. Es muss also zwingend eine größere räumliche Trennung zwischen Shelly und DHTXX geben, da hier die Abstrahlungswärme des Shellys die Werte versaut.
Shelly1: 6 Kelvin
Shelly 1PM 9 Kelvin
Shelly 2PM: 10 Kelvin
Raumtemperatur 18,5°C (nach WD und externem kalibrierten Messgerät - die beiden habe ich zumindest Syncron und jedesmal bei einem Softwareupdate Angst, dass mir das wieder um die Ohren fliegt)
Was noch verwundert: der 2PM wird ja in 2 Geräte aufgegliedert. Diese zeigen ohne eine Last an den Ausgängen (nix dran) zwei unterschiedliche Spannungen an. Spannend.
Wenn ich doof fragen darf: wo befinden sich die Klimadaten, wenn das Ding im Sleep-Modus ist? Und wie frage ich die per Skript ab? Da bin ich grade ein wenig Vorstellungsfrei.
Falsch, kann man prima machen. Sowohl für alle Shelly BLE, als auch für Ruuvi.
Ruuvi bietet dabei mehr Messwerte.
Und Teilweise hast du Recht, was das Abfragen anbelangt. Abfragen muss man die nicht, die senden ihre Daten autonom über BT.
Verarbeiten per Skript geht aber wunderbar.
Ähm ... wenn ich die Klimadaten benutzen möchte um eine im Haus befindliche Aktion auszulösen, dann muss ich die Daten beim BLU abgreifen, was nur geht, wenn der auch antwortet. Das tut er nicht. Er sendet maximal ... umgekehrt wäre eine Abarbeitung des Skriptes auf dem BLU denkbar, was aber konkurriert mit langer Akkulaufzeit ...
Wäre (k)eine Möglichkeit. Du kannst dann allerdings die Daten nicht per Script abfragen und verarbeiten. Du musst die ganze Sache dann über ein übergeordnetes System laufen lassen um bspw. eine Lüftersteuerung. Also wiedermal nur halbgut. Wir werden noch eine Weile mit den DHTXX leben müssen.
Alles klar ... ich dachte nur, dss hier shonmal was aufgetaucht ist und es schon eine Lösung gibt.
Ich nehme nicht 11 TRV aus der Cloud und binde die wieder ein - LEbenszeitvergeudung. Das sollte seitens der Cloud gelöst werden und nicht seitens des Nutzers. Die Dinger tun ja, was sie sollen .... nur eben dieser Fehler. Ich habe in einem anderen Netz auch noch 4 Stück, deren Ereignisprotokoll ist auch leer. Allerdings ohne Fehler.
Ich habe eben festgestellt, dass 11/11 TRV ohne Aktivitätsprotokoll sind. Ansteuern (z.B. händisches Kalibrieren und Änderung der Temperatur) alssen sich alle. Wo ist das Aktivitätenprotokoll hin?
Da muss ich nochmal reinkrätschen ... Ich habe einen 1pm+, der mir 225V anzeigt. Gemessen sined 236V .... wie kann man das korrigieren .... FW ist 20240223-141842/1.2.2-g7c39781 .... also an meiner Vekabelung liegt es nicht. Es ist der Shelly selbst. Wenn er nun die flasche Spannung nimmt, kann er auch nicht richtig messen ... Denke ich ...
Ich fasse zusammen: mit ordentlichen Sensoren, die keine China-Knaller sind, gehen die DHTXX am Addon und Addon+ ....
Das liegt aber an der von dir auf dem ESP32 benutzten Bibliothek. Ich habe mit der Arduino-ATMEGA-Bib auch immer ein NAN bekommen.
Ich gehe davon aus, dass auch der Baustein des Shelly, das könnte. Es ist aber nur eine Busleitung im Design (entweder im Paltinendesign oder in der Software). Das ist also kein Mangel -- das ist ein Feauture. Dazu kommt das verkrüppelte 1Wire-Protokoll des DHT, das keine Adressen kennt.Und schon gilt der Satz: Du sollst nichts neben einem DHT haben.
Wie gesagt, ich werde die Tage mal je einen meiner DHT22 und AM2320 schlachten (die sind nämlich verschweißt)
Ich denke, es macht ein Unterschied, ob es ein ASAIR ist oder nicht. Das hier ist KEINER. Der tut nur so ... mit dem Ergebnis, kleiner Null geht nicht. Es ist mit dem China-Schrott langsam zum heulen.
Originale sind von Sonoff oder Aosong.
Ich habe eben nochmal in das Datasheet des DHT22/21 geschaut (der AM2301 ist eben ein DHTT mit Kabel - hier ist nur Bauform anders ...). Das muss passen mit der Bbliothek. wenns nicht passt, ist der Sonsor nicht das, was er verspricht.
Hier ist das Datenblatt, wobei das auch wieder irgendeine Copy einer Third-Party-Studie ist. Das Ding spricht nur I2C mit einer Adresse. Damit kann am Bus, der von 1Wire (18B20) auf I2C (DHT) wechselt nur eines der Teile sitzen. die elktrische Charakteristik ist zumindest lt. Datenblatt mit dem der anderen DHT identisch. Sollte also deswegen gehen. Das Ding ist frostfest (der Luftfeuchtesensor wird bei Frost nicht zersört, wie beim DHT11).
