geeignete Temperatursensoren

Begonnen von gehrt, 19 Januar 2022, 18:02:45

Vorheriges Thema - Nächstes Thema

gehrt

Hallo Leute!

Seit einigen Jahren läuft bei mir FHEM mit den TX29-DTH IT Temperatursensoren in Homematic Thermostaten. Alles super soweit. Problematisch ist an den TX29 nur, dass das absolut nicht Laien-geeignet ist. Wenn meine Tochter oder meine Frau mal so ein Ding runter werfen und die Batterien rausfallen, bemerke ich das zunächst erstens nicht und zweitens muss ich dann wieder das Dingen neu anmelden, bis meine ID erzeugt wurde, die es noch nicht gibt. Und dann dauert es manchmal bis ich in FHEM sehe, dass die Kommunikation wieder klappt. Alles im Grunde sehr umständlich.
Jetzt habe ich gerade in Youtube ein Zigbee-Sensoren-Video gesehen und mich gefragt, ob es nicht mittlerweile etwas "besseres" pflegeleichteres gibt, was auch ohne Nerd-Zutun funktioniert.
Das Problem an den ganzen Zigbee-Sensoren waren in fast allen Fällen Knopfzellen. Das widerstrebt mir schon enorm. Ersten werden die nicht lange halten, zweitens gibt es keine Akkus. Man produziert also jede Menge Sondermüll.

Ich habe natürlich versucht, meine Frage per Suchmaschine zu beantworten. Leider bin ich nicht auf eine befriedigende Lösung gekommen. Es scheint, als wenn TX29 mit den Nachteilen immer noch das Optimum darstellt. Ich wäre also für ein paar Tipps dankbar.

Viele Grüße
Gehrt


gehrt

Die Liste kenne ich natürlich, gibt aber keine Antwort auf meine Frage. Was da in der Liste steht ist entweder alt oder zu teuer für den Zweck.
Ok, also gibt es wohl nichts.

Beta-User

Doch, ich mache das z.B. via Bluetooth (Xiaomi) iVm. OpenMQTTGateway....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

det.

Ich mach das seit weit über 10 Jahren mit 1-wire. Die Sensoren sind nun wirklich billig und brauchen auch nie wieder Batterien.
LG
det.

Pfriemler

#5
Als erstes würde ich die Familie dazu erziehen, keine Gegenstände ohne Not herunterzuwerfen  ;D...

Ich habe ein Rudel Homematic-Sensoren (ein Differenztemperaturgeber liefert auch zwei Absoluttemperaturen (allerdings eben über Kabel an der Box verbunden) für ~15 Euro pro Sensor als Bausatz), dem traue ich zu, dass er Temperaturen sogar per Direktverknüpfung anliefert, und ein Wandthermostat kostet als Bausatz auch nicht die Welt. Das funktioniert dann auch wieder ohne Zutun von FHEM.
Dann habe ich daneben diverses altes eher unzuverlässiges Zeugs und bin vor einer Weile auf die LaCrosse umgestiegen, die - hier allerdings nicht regelmäßig misshandelt) wunderbar zuverlässig und vor allem sehr aktuell Daten liefern, bis sie sich mit lowbatt melden und ich über replaceBatteryForSec angemeldet die Batterien wechsele, was in der Regel frühestens alle zwei Jahre passiert und sich Akkus daher über die Lebensdauer der Geräte schlicht nicht rechnen. Und selbst wenn das vorab fehlgeschlägt: zeigen die Dinger beim Einstromen nicht ihre ID an und man trägt die einfach in der DEF in FHEM ein? Oder hast Du so viele am Start? Ich betreibe hier etwa ein Dutzend.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

gehrt

Bluetooth - ich frage mich immer, wer auf die Idee gekommen ist, das mit Smarthome in Verbindung zu bringen.
1-wire - wie soll man damit ein Haus ausstatten? Geht wohl kaum.
Homematic Wandthermostate wären natürlich das Beste. Aber 35€ pro Stück ist viel Geld für die reine Temperaturfunktion.
Außerdem will ich nicht 350€ in alte Technik investieren. Auch wenn Homematic bei mir bis jetzt perfekt funktioniert.
Der Smarthome-Markt ist meiner Meinung nach völlig kaputt. Lauter bescheidene Systeme auf dem Markt, die dann oft auch noch viel zu teuer sind. Homematic ist da noch mit das beste, was man kaufen kann. Wenn die wenigstens ein mesh-fähiges Funkprotokoll auf Zigbee-Basis einsetzen würden. Das wäre mal vernünftig.

Damian

Es hängt davon ab wozu man die nutzt:

Mein Zoo an Temp/Hum-Sensoren:

-Homematic-Wandthermostate in jedem Zimmer, ziemlich genau - steuern FB-Heizung auch ohne FHEM (pro Bausatz ca 40 Euro) auf Stromnetz umgebaut.

-1-Wire am esp8266 (2 Euro pro Stück plus 5 für esp) braucht Stromnetz

-zwei alte ELV-Sensoren (868 Mhz)

-alte Aldi Sensoren aus Stationen über Signalduino 433 MHz eingebunden (max. drei Kanäle)

-neuerdings 3 Sensoren mit Auriol-Station über Signalduino 433 MHz eingebunden, (max. drei Kanäle), war aber mit 20 Euro für alles spottbillig mit guter Sendeleistung

Die TX29-DTH habe ich erst gar nicht eingebunden, da sie mir mit 4 Sekunden Sendeintervall nur den Äther verseuchen würden.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Pfriemler

Zitat von: Damian am 19 Januar 2022, 21:25:20
Mein Zoo an Temp/Hum-Sensoren: ...
Die TX29-DTH habe ich erst gar nicht eingebunden, da sie mir mit 4 Sekunden Sendeintervall nur den Äther verseuchen würden.
Das ist ja mal ein Mix, Gratulation dass das alles so läuft ...
Es ist richtig, dass die LaCrosse so häufig senden, aber wenn ich meinem SDR-Radio-Stick am PC Gehör schenke, ist das immer ein ausgesprochen kurzes fröhliches Gezwitschere (sonst kämen die sicher auch nicht auf ihren duty cycle, es ist für mich sogar ein Wunder, dass die Batterien trotzdem so lange halten wie in allen anderen minutenweise sendenden Geräten auch), während andere Sender zwar nur alle zwei Minuten, dafür doch deutlich länger brüllen. Und Homematic repeatet ja auch stur einige Male oder bis zur Quittung.
Seit der Einführung meines Rudels LaCrosse habe ich jedenfalls keine Verschlechterung des Empfangs anderer Dienste wahrnehmen können.

Und klar: Die HM-Thermostate sind vglw. teuer - aber es sind eben auch Thermostate mit Bedienmöglichkeit. Ich nutze nur einen im Bad - den RT-DN fasse ich nur noch zum Batteriewechsel an.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Beta-User

Zitat von: gehrt am 19 Januar 2022, 20:54:31
Bluetooth - ich frage mich immer, wer auf die Idee gekommen ist, das mit Smarthome in Verbindung zu bringen.
;D ... das war auch mein erster Gedanke...

Im Ernst: von den Funk-gebundenen Kauf-Lösungen, die ich im Haus habe (daneben noch: ZigBee/Xiaomi, Homematic-classic, ZWave) finde ich die Xiaomi-BT-Geschichte zwischenzeitlich für reine Sensorik die Beste! (Vorausgesetzt, dass es nur um temp/hum geht... Nebenbei ist sie auch noch sehr günstigst).

Gab mal einen ähnlichen Thread: https://forum.fhem.de/index.php/topic,122674.0.html, und irgendwo gab es auch einen zu den ZigBee-Xiaomi (ich habe da einen, der immer mal wieder die Verbindung verliert).

Argumente dafür: Die Dinger haben ein Display,  sind - je nach Ausführung - winzig/"optisch vermittelbar", sie haben eine eindeutige Adresse, und die Batterien halten auch ewig (es gibt "eckige" mit CR2032 und "runde" mit AAA, ich habe dei LCD-Versionenen, vermutlich ist es mit e-Paper nochmal deutlich mehr wie die 12+Monate, die ich mind. feststellen konnte). Die funken (bei den eckigen: nach einem mit einem Handy durchzuführenden firmware-Update) auch "einfach so" vor sich hin, das einzige, was ggf. ausfallen kann, ist das Gateway (was aber seit 0.9.6 oder so nicht mehr vorgekommen ist).

Zwischenzeitlich kann auch Tasmota "nebenbei" BTLE auf den ESP32-basierten Geräten, von daher braucht man uU. nicht mal mehr gesonderte Hardware als GW....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Pfriemler

OK. Mit dem E-Ink-Display habt Ihr mich juckig gemacht. Also doch mal in BT einlesen, Reichweite etc. Habe nur leider noch keinen ESP32 mit Tasmota am Start.
Nur der Smilie geht mal gar nicht. Kann man den wegkonfigurieren?
Ob E-Inks länger halten als LCD, wäre für mich aber fraglich: LCD-Uhren laufen mit CR2032 schon mal locker 4-5 Jahre, das braucht ja auch nicht viel Strom. E-Ink zieht bei Displaywechsel auch. Da das hier nur alle paar Minuten sein sollte, aber sicher kein Problem.
Knopfzellengeräte kommen mir aber nur noch wenn's gar nicht anders geht ins Haus.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Beta-User

...weiß auch nicht, ob sich e-ink lohnt...

Wie gesagt: ich bin mit den (umgeflashten) Eckigen@LCD sehr zufrieden, die kosten bei Ali ca. 5 Euro/Stück, und man braucht halt (sinnvollerweise) einen ESP32 "irgendwo" ("nackig" für <5 Euro/Stück) - mir reicht einer (recht zentral platziert) pro Stockwerk.
Tasmota ist etwas langsamer, was die Einbindung der diversen Varianten angeht, und in FHEM haben wir noch keinen Tester (oder seit neuestem einen?) für die Sensoren (es gab aber im englischen Forumsbereich einen, der die equiva-Thermostate via Tasmota-BT "nebenbei" steuert!), aber das ist nur eine Frage der Zeit...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wernieman

ZitatHomematic-.... auf Stromnetz umgebaut.
Darf man fragen wie?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

MadMax-FHEM

FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Wernieman

Muß gestehen, das ich das gerne "basteln" würde ... kommt irgendwie der Spieltrieb rüber ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Damian

#15
Zitat von: Wernieman am 20 Januar 2022, 10:53:30
Darf man fragen wie?

Ganz einfach. Wer eine FB-Heizung hat, der hat normalerweise pro Raum ein Dose neben der Tür für ein Wandthermostat eingebaut bekommen. Diese ist für das Schalten der Stellantriebe über 230V ausgelegt. Nun habe ich aber die 1.75 m2-Adern nicht an die 230V-Antriebe angeschlossen. Stattdessen habe ich zentral am Verteiler ein 3V-Netzteil angeschlossen. Damit kann ich alle Wandthermostatdosen statt mit 230V zum Schalten der Antriebe mit 3V versorgen. Im Wandthermostat habe ich Drähte angelötet, die ich statt Batterien mit der externen Stromversorgung von 3V verbinden kann. Der Vorteil: nur ein Netzteil für 6 Euro pro Etage und nicht etwas überteuertes (27 Euro) für jedes Wandthermostat. Auf jeden Fall spare ich mir bei 8 Wandthermostaten den ständigen Wechsel der Batterien - ein Jahr ist schneller um, als man denkt.

Für das Schalten der Stellantriebe werden natürlich noch entsprechende mehrfach-Aktoren benötigt, die man über Funk jeweils mit den Wandthermostaten koppelt.

Die anderen Vorteile solcher Lösungen liegen auf der Hand: Visualisierung der Temperaturen/Feuchte pro Raum, zeitliche Steuerung der Solltemperatur über FHEM, Antriebe werden gesteuert auch wenn FHEM nicht läuft
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Wernieman

Also "stink Normales 3V Netzteil?" ... kriegt man bestimmt auch selber gebaut ;o)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Damian

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Wernieman

Prinzipiell hast Du Recht, aber ..
- Bei mir liegt bei einigen in der Nähe 5V .....
- Wie ich ein paar Beiträger vorher schrieb: "Muß gestehen, das ich das gerne "basteln" würde ... kommt irgendwie der Spieltrieb rüber ..."
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Damian

Zitat von: Wernieman am 20 Januar 2022, 14:32:26
Prinzipiell hast Du Recht, aber ..
- Bei mir liegt bei einigen in der Nähe 5V .....
- Wie ich ein paar Beiträger vorher schrieb: "Muß gestehen, das ich das gerne "basteln" würde ... kommt irgendwie der Spieltrieb rüber ..."

Dann klemmst du einen Step-Down-Spannungswandler dazwischen. Bei dem verlinkten Netzteil (eco-friendly) geht die Leistungsaufnahme gegen Null.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

kadettilac89

Hast du irgend wo einen Kondensator mit drin? Bei einem Stromausfall musst du sonst alle Thermostate, wie bei einem Batteriewechsel (INS drücken). Oder ist das etwas das akzepiert wird?

Damian

Ich habe keinen Kondensator drin. Ich muss auch nichts drücken, wenn Strom wieder da ist.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Wernieman

#22
Ein Thermostatventiel hat auch das Problem, das der Motor deutlich mehr zieht als die Elektronik. Kurzfristig können Batterien einiges liefern ... wenn die Stromversorgung dafür nicht eingerichtet wurde, hat die Elektronik bei der Ventilarbeit auf ein mal kein Strom. Blöde nur, das eine Stromversorgung, die mehr "Saft" liefern kann, auch mehr "Ruhestrom" verbrät. Und meistens arbeiten die Ventile nicht, d.h. der Ruheverbrauch ist wichtig ...

Warum wird eigentlich bei HM von Akkus als Batterieersatz abgeraten?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Damian

Zitat von: Wernieman am 21 Januar 2022, 15:24:25
Ein Thermostat hat auch das Problem, das der Motor deutlich mehr zieht als die Elektronik. Kurzfristig können Batterien einiges liefern ... wenn die Stromversorgung dafür nicht eingerichtet wurde, hat die Elektronik bei der Ventilarbeit auf ein mal kein Strom. Blöde nur, das eine Stromversorgung, die mehr "Saft" liefern kann, auch mehr "Ruhestrom" verbrät. Und meistens arbeiten die Ventile nicht, d.h. der Ruheverbrauch ist wichtig ...

Warum wird eigentlich bei HM von Akkus als Batterieersatz abgeraten?

Also ein HM-Wandthermostat, und davon sprach ich, hat so gut wie kein Stromverbrauch - es hat ja keinen Motor dran.

Batterien haben höhere Spannung und geringere Selbstentladung.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Wernieman

Sorry mein Fehler ... meinte Thermostatventil

Kann nur zur Entschuldigung sagen: Woche war schwer und heute Freitag ....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

kadettilac89

Zitat von: Wernieman am 21 Januar 2022, 15:24:25
Warum wird eigentlich bei HM von Akkus als Batterieersatz abgeraten?

Vermutlich weil Akku nur 1.2 V Spannung haben. 2.4 V bei zwei würde immer Batteriewarnung geben.

Panik

@Beta-User
hast du einen Kauftip für solche Xiaomi Mi Temperatur-und Feuchtigkeitssensoren auf Bluetooth-Basis?
Wie ist die Reichweite?
Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW

Beta-User

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

kadettilac89

Zitat von: Beta-User am 01 Februar 2022, 16:26:51
Ich habe v.a. die: https://compatible.openmqttgateway.com/index.php/product/xiaomi-mi-jia-ble-lywsd03mmc-indoor-mini-weather-station/ und zwei https://compatible.openmqttgateway.com/index.php/product/xiaomi-mi-jia-ble-indoor-weather-station/

Reichweite ist nicht berauschend, aber ein GW pro Stock reicht bei mir (man kann/könnte den ESP auch mit einer externen Antenne aufrüsten).
Welches GW hast du da? Wie ist das in Fhem eingebunden? Gibt es dafür ein Modul oder musstest du GW / Temperatur sensor irgendwie flashen damit es über MQTT o. ä. geht?

Die Sensoren sind ja günstig.

Beta-User

Zitat von: kadettilac89 am 04 Februar 2022, 10:09:55
Welches GW hast du da? Wie ist das in Fhem eingebunden? Gibt es dafür ein Modul oder musstest du GW / Temperatur sensor irgendwie flashen damit es über MQTT o. ä. geht?
Hier läuft das über OpenMQTTGateway - habe dazu zwei ESP32 im Einsatz (pro Stockwert einen, da gibt es binaries, die man draufflashen muss, meine haben eine Micro-USB-Schnittstelle, da ist das schnell erledigt), Tasmota-ESP32 sollte aber auch gehen (afaik sogar "nebenbei", wenn man "sowieso" einen "normalen" ESP32-basierten Tasmota-Aktor hat: https://forum.fhem.de/index.php/topic,123411.0.html). Für die OpenMQTTGateway-Geschichte gibt es attrTemplate für MQTT2, bei Tasmota fehlt mir noch ein Tester, die Basics könnten aber schon passen (ein erstes "Gateway-template" ist vorhanden, aber bisher ohne Rückmeldung...).

Die "eckigen" habe ich (mit dem Handy) umgeflasht (noch via https://github.com/atc1441/ATC_MiThermometer, aktuellere Fassung wohl unter https://github.com/pvvx/ATC_MiThermometer).
Zitat
Die Sensoren sind ja günstig.
Jo. Und soweit erkennbar auch recht genau.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

kadettilac89


Panik

Dank auch von mir.
Hab mir jetzt mal 4 Sensoren bestellt ...
Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW

Panik

Hallo Beta-User, ich habe jetzt einen Lolin32 in Fhem eingebunden und nun auch mal einen der eckigen Sensoren geflasht. In Fhem hab ich auch autocreate aktiviert. Das Globale, als auch das am Gateway. Dennoch wird kein Device angelegt. Gibt es da noch nen Trick?
Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW

Beta-User

Bis zu welchem Punkt hat es denn geklappt? Eine Anleitung wäre in https://wiki.fhem.de/wiki/OpenMQTTGateway zu finden.

Die Sensoren selbst muss/kann man via attrTemplate "manuell" anlegen lassen, indem man das jeweils passende template mit einer BT-Adresse aufruft (pures autocreate für jede BT-Adresse würde zu viele unnütze Devices anlegen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Panik

Aha, das manuelle Anlegen war der entscheidende Hinweis.
Man sollte das Wiki lesen.
Gut.
Aber nun gebe ich
set MQTT2_OpenMQTTGateway attrTemplate OpenMQTTGateway_BT_temp_hum_sensor [bt-id]
ein
Doch an der BT-ID scheitere ich.
Ob ich da ATC_38xxxx, blt.3.129vaxxxx, oder 4A:4C:F3:xxxxx eingebe
es kommen keine Readings rein.
Nur bei MQTT2_oMQTTgw_BT sehe ich das Device , aber da gibt es das Reading bt-id nicht.  :-\
Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW

Beta-User

#35
Das ist einfach nur die Adresse ohne Doppelpunkte.

Wenn du also im "BT-Sammel-Device" sowas als Reading hast:
0475CF951EA3_id 04:75:CF:95:1E:A3
ist es einfach "0475CF951EA3".

(Dachte, ich müßte ggf. was an der Doku verbessern, aber das steht auch genau so in der Beschreibung, die angezeigt werden sollte, wenn man das template in dem dropdown auswählt).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wernieman

Als Verbesserungvorschlag:
Kann man dem Modul nicht beibringen, bei BT-Adressen einfach die ":" wegzulassen, falls angegeben? Schließlich hat eine gültige BT Adresse keine ":" ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Beta-User

Zitat von: Wernieman am 15 Februar 2022, 10:52:32
Als Verbesserungvorschlag:
Kann man dem Modul nicht beibringen, bei BT-Adressen einfach die ":" wegzulassen, falls angegeben? Schließlich hat eine gültige BT Adresse keine ":" ...
Nun ja, es ist nicht unbedingt ein "Modul", sondern ein MQTT2_DEVICE, das über attrTemplate konfiguriert wird. Konkret besteht das Problem, dass der Input an dieser Stelle eigentlich bereits die Auswertung einer Perl-Anweisung ist, die "undef" zurückgegeben hat (sonst bekommt man kein Dialogfeld). Das nochmal auszuwerten ist nicht vorgesehen (und eigentlich auch unnötig, wenn der User das angezeigte "manual" gelesen hat).

Falls jemand eine in Code umsetzbare bessere Variante hat, baue ich die aber gerne ein...

(Das hier mit OpenMQTTGateway@BT ist eine etwas spezielle Ecke, die zugegebenermaßen etwas anders "tickt" als die meisten anderen Lösungen im MQTT-Umfeld).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Panik

Hallo Beta-User,

habe jetzt alle diese günstigen, geeigneten Temperatursensoren so in FHEM hineinbekommen.


Ich sehe eigentlich immer in die Hilfe unter dem Device "Device specific help"
Da fand ich nichts zu den Doppelpunkten

Jetzt wollte ich mal das Template ansehen, um zu lesen, was da drin steht nach deiner dort hinterlegten Doku.
Dieses Template taucht aber nicht mehr auf.
Kann es sein, dass das Device eben durch das Template so umgebogen wird, dass es nun ein MQTT2_DEVICE ist und eben nur deren Templates angezeigt werden, aber keine eines BT-Devices?

Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW

Beta-User

Schön, dass jetzt geklappt hat.

Wegen der Doku - ist hier eigentlich OT, aber ggf. für den einen oder anderen interessant:
- "help" kann nur anzeigen, was es an commandref zu einem Thema gibt. Da im Zusammenhang mit OpenMQTTGateway kein ergänzender Code nachgeladen wird, steht dieser Weg hier nicht zur Verfügung (z.B. zu den ebus-attrTemplate gibt es über diesen Weg einige Infos zu den intern verwendeten Funktionen)
- es bleibt daher nur der Weg über die Anzeige, wenn man das betr. attrTemplate in der dropdown-Liste anwählt. Der setzt aber voraus, dass das betr. template zum einen überhaupt geladen wurde und zum anderen der "filter" paßt, siehe https://wiki.fhem.de/wiki/AttrTemplate#Warum_finde_ich_das_Template_xyz_nicht.3F

Hier kann ich mangels Info, wo was genau ausprobiert wurde, nur raten: Der Filter schlägt zu, weil im Device-Topic nicht mehr das auftaucht, was früher mal üblich war, nämlich irgendeine Form von "OpenMQTTGateway" oder "OMG_xy" in der readingList...

(Dass ein attrTemplate wegen "filter" nicht angezeigt wird, bedeutet nicht, dass man es nicht ausführen könnte, man bekommt nur uU. eine Reihe weiterer Rückfragen zu den erforderlichen Parametern, wenn das automatische Ermitteln nicht klappt...)

Notfalls muss  man im Quelltext nachsehen, da steht manchmal auch etwas mehr an Info, wo was herkam usw.. Zu finden u.a. unter https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Zitat von: gehrt am 19 Januar 2022, 18:02:45
Jetzt habe ich gerade in Youtube ein Zigbee-Sensoren-Video gesehen und mich gefragt, ob es nicht mittlerweile etwas "besseres" pflegeleichteres gibt, was auch ohne Nerd-Zutun funktioniert.
Das Problem an den ganzen Zigbee-Sensoren waren in fast allen Fällen Knopfzellen. Das widerstrebt mir schon enorm. Ersten werden die nicht lange halten, zweitens gibt es keine Akkus. Man produziert also jede Menge Sondermüll.

Geht's dir nur um Temperatur/Luftfeuchte Senoren? Ohne irgendwelche Displays oder Stellmöglichkeiten?
Ich hab da auf EnOcean gebaut. Die hier z.B.: https://www.enocean-alliance.org/product/nodon-indoor-temperature-humidity-sensor/
Funktioniert zuverlässig und braucht v.a. keine Batterien.

Panik

Hallo Beta-User

im Zuge der Zeitumstellung fiel mir auf, dass die Sensoren noch auf der alten Zeit beharren und man mit dem Telink Flasher for Mi Thermostat die Zeiten korrigieren muss.

Ist es denkbar, dass das irgendwann mal zentral über FHEM und das rOpenMQTTGateway auf ESP-Basis möglich sein wird?
Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW

Beta-User

Bin etwas ratlos, meine Mi-Temp-Sensoren haben gar keine eigene Uhr - jedenfalls ergibt sich nichts dahingehendes aus den Readings, die ich hier so sehe (habe beide alternative firmware-Varianten für die "eckigen" im Einsatz).

Prinzipiell lassen sich aus über das "neue" OMG-MCU-attrTemplate (und der aktuellen Firmware) aber auch beliebige BT-Befehle senden, von daher würde ich annehmen, dass man auch den Datenpunkt "Uhrzeit/Datum" beschreiben kann, der dürfte sogar standardisiert sein. Bitte dazu aber ggf. entweder an den "support"-Thread anhängen oder ein eigenes Thema aufmachen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Panik

Doch, doch ,
du musst den Link nehmen:
https://pvvx.github.io/ATC_MiThermometer/TelinkMiFlasher.html
und connecten.
Am  Ende des oberen Drittels ist dann die Zeile: Smiley: , Comfort: , Show batt: , Clock:  Set Time Get Time
Wenn  du die entsprechende Checkboxen anhakst, wechselt sich Anzeige der Temp, Batt. und Uhrzeit ab.

Ich schau mal in die Template-Abteilung ...
Raspberry3+,  CUL USB V3 mit V 1.66 CUL868, TRXRFX433, HM-MOD-UART, Phoscon-GW