Bme280 an D1mini mit espeasy

Begonnen von dihe85, 31 August 2020, 20:36:20

Vorheriges Thema - Nächstes Thema

dihe85

Hallo zusammen
Nach meinem 2 stündigem Versuch einen bme280 über tasmota einzubinden habe ich espeasy geflasht.
2min später hatte ich Daten in espeasy.

Nun zu meiner Frage.
In Fhem habe einen Mqtt2-server laufen.
Hohl ich die Daten am besten über mqtt oder über eine andere Schnittstelle?
Sollte ich mqtt verwende werde ich doch auch ein template setzten müssen. Aber welches?

Danke schon mal vorab
Dirk

Beta-User

Für ESPEasy gibt es ein separates Modul; damit scheinen die meisten User dieser firmware zu arbeiten.

Ein paar wenige Male haben sich auch MQTT(2)-User gemeldet, da war das in der Regel kein größeres Problem mit den Meßwerten, die werden auch ganz ohne attrTemplate sauber übertragen (Schalten war nach meiner Erinnerung etwas spezieller).

Überhaupt ist attrTemplate ein Hilfsmittel und kein "Muß" ;) . Man kann dasselbe Ergebnis auch händisch erreichen, indem man die passenden Attribute setzt (bzw. - bei Tasmota - teils dann die Konfiguration der firmware entsprechend anpaßt).
Grundsätzlich ist es nach meiner Erfahrung bei "unbekannten" MQTT2-Geräten am einfachsten, MQTT2_SERVER mit autocreate simple erst mal machen zu lassen und dann ggf. dieses Zwischenergebnis zu verbessern... Also: Nur Mut!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

dihe85

Ich hab jetzt für jeden Wert ein device angelegt.
Gibt es eine möglichkeit das ein gdevice gleichzeitig mehrer statuse haben kann?
Temperatur Feuchte Luftdruck

Gruß
Dirk

Beta-User

Zitat von: dihe85 am 01 September 2020, 17:26:43
Ich hab jetzt für jeden Wert ein device angelegt.
TYPE=....?

ZitatGibt es eine möglichkeit das ein gdevice gleichzeitig mehrer statuse haben kann?Temperatur Feuchte Luftdruck

Gruß
Dirk
Geht (abgesehen davon, dass es nur ein "state" Reading geben kann und die Mehrzahl von Status korrekterweise Status mit anderer Aussprache ist) mit TYPE=MQTT2_DEVICE ziemlich sicher.
Da wäre das Stichwort stateFormat.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Nobbynews

#4
Ich habe hier einen BME280 mit dem Modul ESPEsy eingebunden.
Hier die Raw:

ESPEasy_ESP_01_BME280 ESPEasy 192.168.2.220 80 ESP ESP_01_BME280
attr ESPEasy_ESP_01_BME280 IODev ESP
attr ESPEasy_ESP_01_BME280 Interval 300
attr ESPEasy_ESP_01_BME280 group ESPEasy Device
attr ESPEasy_ESP_01_BME280 presenceCheck 1
attr ESPEasy_ESP_01_BME280 readingSwitchText 1
attr ESPEasy_ESP_01_BME280 room ESPEasy
attr ESPEasy_ESP_01_BME280 setState 3

setstate ESPEasy_ESP_01_BME280 Hum: 41.5 Pre: 1014.0 Tem: 24.3
setstate ESPEasy_ESP_01_BME280 2020-09-01 18:25:13 Humidity 41.5
setstate ESPEasy_ESP_01_BME280 2020-09-01 18:25:13 Pressure 1014.0
setstate ESPEasy_ESP_01_BME280 2020-09-01 18:25:13 Temperature 24.3
setstate ESPEasy_ESP_01_BME280 2020-09-01 18:21:38 presence present
setstate ESPEasy_ESP_01_BME280 2020-09-01 18:25:13 state Hum: 41.5 Pre: 1014.0 Tem: 24.3


Als Controller natürlich FHEM HTTP definiert.
In ESPEasy habe ich eingestellt, dass der Sensor alle 60s die Daten schickt.
Läuft bestens.

dihe85

TYPE=....?
MQTT2_device

jap die mit stateFormat einfach zu listen hätte man drauf kommen könne.


@Nobbynews
Cool Danke guck ich mir mal an.
Ist wahrscheinlich die sauberer Variante an der Stelle.

Gruß
Dirk

Beta-User

Schön, dass das geklappt hat.

Warum meinst du dass das andere die sauberere Variante ist?

Nichts gegen das ESPEasy-Modul, aber wenn man sowieso eine MQTT-Implementierung am Laufen hat, ist es mAn. kein großer Unterschied, wenn man mal davon absieht, dass man mit MQTT flexibler ist, was die Readingbenennung angeht, andererseits aber erst noch etwas "groundbreeding" erforderlich wäre, um v.a. Relays schaltbar zu machen bzw. generell irgendwelche Outputs zu konfigurieren.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

dihe85

Die Aussage bezieht sich darauf, das relays die an dem einem Board evtl noch dran kommen, laut den ganzen einträgen hier im forum, mit dem esp tool zu schalten sind.

Beta-User

Ah, ok.

Es gibt hier einen Beitrag mit einem list von einem ESPEasy-Relay:
https://forum.fhem.de/index.php/topic,107965.msg1019579.html#msg1019579

Wenn ich das richtig deute, ist es kein Hexenwerk. Man braucht entweder Rudis Vorschlag oder eben eine etwas spezielle readingList-Auswertung, aber was ähnliches dürfte bereits vorhanden sein ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CBSnake

Hi,

ich klink mich mal ein da ich einige D1mini mit ESPeasy am laufen haben. Eingebunden sind eigentlich alle mit dem ESPeasy Modul.
Zum Testen habe ich mal einen davon auf den, auch laufenden, MQTT2 geholt. Klappt auch sehr gut, wurde sofort mit dem passenden Reading vom autocreate angelegt.
Was ich allerdings noch vermisse ist ein presence check. Das bringt das ESPeasy Modul von Haus aus mit, hier beim MQTT2 muss ich wohl was basteln oder nochmal tiefer suchen ob ich doch noch was im Modul oder im D1 finde.
Hintergrund: Das Teil hängt in der Garage im Hof und soll später mal das Tor überwachen ;-) Allerdings bin ich mit nem RSSI von -80 schon grenzwertig weit weg. Daher läuft das Teil aktuell nur um zu sehen wie oft es nicht erreichbar ist. Und da fällt mir halt auch auf:
ESPeasy Modul und die kleine D1 Armee fallen immer dann aus/verlieren ihre Verbindung zu FHEM wenn FHEM ordentlich was zu tun hat. Evtl klappt das per MQTT2 besser.
FHEM auf Debian 10, HM-Wlan, JeeLink-Wlan, Wlanduino, ConBee, TP-Link Steckdose, GHoma Steckdosen, Shelly Steckdosen

Beta-User

#10
Na ja, ESPEasy scheint auch eine LWT-Funktionalität zu haben (in der aktuellen pre-Release wurde da was gefixt: https://github.com/letscontrolit/ESPEasy/releases/tag/mega-20200608). Das sollte die Presence-Erkennung auf dem MQTT-way ermöglichen.

Mit MQTT wird die Funkverbindung auch nicht besser, es reduziert sich ggf. nur die Datenlast (k.A., welches TCP/IP Protokoll das ESPEasy-Modul im Hintergrund nutzt; MQTT ist eigentlich auf geringe Datenlast ausgelegt (was aber teilweise von den Client-Implementierungen nicht unbedingt beachtet wird). Evtl. würde eine Antenne helfen (den Hinweis auf alternative andere Eigenbau-Funklösungen verkneife ich mir fast :P ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CBSnake

naja die funkverbindung steht, oder halt auch nicht, da kann weder ESPeasy noch das Modul noch FHEM was dazu :-) aber zu 99% steht die Verbindung ausreichend.
ich meinte eher den Fakt:
Ist FHEM ausgelastet, den Verursacher such ich noch ich vermute aber Richtung MQTT/ESPeasy, dann gehen nacheinander alle D1 auf absent (im ESPEasy Modul) und ich bekomm für jeden D1 die Absent-Info per Telegram die ich eigentlich für den D1 in der Garage programmiert hatte. Sprich im minutentakt "fallen" die D1 aus und kurz darauf ist wieder alles gut :-) Wie wenn die D1 nimmer zu FHEM durchkommen oder eben die Events auflaufen. Da gehts z.B. um 2 PIR Sensoren an je einem D1 und ohne Event in FHEM bleibts dunkel :-)
Wenn ich das ganze auf MQTT2 bekommen würde und mit damit das ESPeasy Modul sparen kann wäre sicher etwas weniger Last auf dem System. Notfalls prüfe ich halt regelmäßig die Aktualität der Readings und wenn das zu alt ist kommt die Meldung.
FHEM auf Debian 10, HM-Wlan, JeeLink-Wlan, Wlanduino, ConBee, TP-Link Steckdose, GHoma Steckdosen, Shelly Steckdosen

Beta-User

"...oder halt auch nicht...", was wohl bei den ESP's leider gar nicht so selten vorkommt.

Na jedenfalls löst das nicht die aktuelle Frage des TE, erinnert mich aber mal wieder daran, dass meine skeptische Grundhaltung gegenüber WLAN ind er Hausautomatisierung im Allgemeinen und die ESP8266 im Speziellen "gewisse Gründe" hat. Wer also plant, die Dinger "als Armee" einzusetzen, sollte mind. prüfen, ob auch seine sonstige WLAN-Infrastruktur dazu paßt.
(Zur Analsye der tieferen Ursachen bitte ggf. einen eigenen Thread aufmachen, es sei denn, der TE will dieses Problemfeld hier beackern ;) ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

dihe85

Bei mir passt sie ;)
Ich hab ein mesh mit 5 accesspoints
Da mach ich mir um meine wlan-auslastung weniger gedanken wie um meinen netzbereich (clas C netz)