... irgendwie bin ich zu doof dafür, obwohl es ja nun wirklich nicht mein erstes Logfile ist ...
Ein ESP (ESPEasy) sendet alle 5 Minuten einen Datensatz an FHEM. Das funktioniert so weit wirklich sehr gut. der Haken daran ist allerdings, das der ESP die Daten nicht nur einmal sendet, sondern einen ganzen Satz der selben Daten in bunter Mischung. Als Beispiel hier mal solch ein Datensatz:
2019-07-08_00:20:15 ESPEasy_ESP_test presence: present
2019-07-08_00:20:15 ESPEasy_ESP_test B: 0.23 H: 64.52 P: 1012.55 T: 13.40 V: 4.44
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.52 P: 1012.55 T: 13.40 V: 4.44
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.52 P: 1012.55 T: 13.40 V: 4.44
2019-07-08_00:20:39 ESPEasy_ESP_test V: 4.45
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.52 P: 1012.55 T: 13.40 V: 4.45
2019-07-08_00:20:39 ESPEasy_ESP_test T: 13.27
2019-07-08_00:20:39 ESPEasy_ESP_test P: 1012.57
2019-07-08_00:20:39 ESPEasy_ESP_test H: 64.79
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.79 P: 1012.57 T: 13.27 V: 4.45
2019-07-08_00:20:40 ESPEasy_ESP_test B: 0.23
2019-07-08_00:20:40 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.45
2019-07-08_00:20:40 ESPEasy_ESP_test V: 4.44
2019-07-08_00:20:40 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.44
2019-07-08_00:20:43 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.44
2019-07-08_00:20:44 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.44
B = Brightness in LUX
H = Humidity in %
P = Pressure in mBar
T = Temperature in °C
V = Cell- Voltage in V
Für mich interessant sind natürlich nur die zusammengefassten Werte in "state", die ich gerne loggen möchte. "Ist ja ganz easy" dachte ich mir, aber weit gefehlt... Ich bekomme es einfach nicht gebacken...
Wenn ich ...
define ESP_test_log FileLog ./log/%Y-%m_ESP_Test.log ESP_test:state:.*
definiere, passiert mal gar nix (leeres Log). auch andere Varianten ergeben ein leeres Log. Definiere ich hingegen ...
define ESP_test_log FileLog ./log/%Y-%m_ESP_Test.log ESP_test
... oder auch ...
define ESP_test_log FileLog ./log/%Y-%m_ESP_Test.log ESP_test:.*
... dann erhalte ich obige Datenmenge im Logfile.
Was zur Hölle übersehe ich dabei?
Anbei noch das Listing des ESP:
Internals:
.AttrList IODev Interval adjustValue colorpicker:RGB,HSV,HSVp deepsleep:0,1 disable:1,0 disableRiskyCmds disabledForIntervals displayTextEncode:1,0 displayTextWidth do_not_notify:0,1 event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading mapLightCmds:lights,nfx maxCmdDuration:slider,0,0.25,15,1 parseCmdResponse pollGPIOs presenceCheck:1,0 readingPrefixGPIO readingSuffixGPIOState readingSwitchText:1,0,2 rgbGPIOs setState:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,25,50,100 useSetExtensions:0,1 userSetCmds:textField-long wwcwGPIOs
DEF 192.168.1.221 80 espBridge ESP_test
ESP_BUILD 20103
ESP_BUILD_GIT mega-20190630
ESP_BUILD_NOTES - Mega
ESP_NODE_TYPE_ID ESP Easy Mega
ESP_SLEEP RPI Easy
ESP_UNIT 20
ESP_VERSION 2
FUUID 5d220290-f33f-a7b8-75b7-605c50a9e5fa7ac0
HOST 192.168.1.221
IDENT ESP_test
INTERVAL 300
IODev espBridge
LASTInputDev espBridge
MAX_CMD_DURATION 1
MSGCNT 28
NAME ESP_test
NOTIFYDEV global
NR 2668
NTFY_ORDER 50-ESP_test
PORT 80
STATE B: 1787.50 H: 42.04 P: 1013.43 T: 22.53 V: 4.42
SUBTYPE device
TYPE ESPEasy
VERSION 2.18
espBridge_MSGCNT 28
espBridge_TIME 2019-07-08 12:28:27
.attraggr:
.attrminint:
READINGS:
2019-07-08 12:28:22 B 1787.50
2019-07-08 12:28:17 H 42.04
2019-07-08 12:28:17 P 1013.43
2019-07-08 12:28:17 T 22.53
2019-07-08 12:28:17 V 4.42
2019-07-08 12:28:56 presence present
2019-07-08 12:28:27 sleepState sleeping
2019-07-08 12:28:56 state B: 1787.50 H: 42.04 P: 1013.43 T: 22.53 V: 4.42
helper:
fpc 1562581130
pm:
Encode 1
JSON 1
received:
B 1562581702
H 1562581697
P 1562581697
T 1562581697
V 1562581697
sec:
admpwd
Attributes:
IODev espBridge
Interval 300
group ESPEasy Device
presenceCheck 1
readingSwitchText 1
room ESPEasy
setState 3
Zitat von: M_I_B am 08 Juli 2019, 12:31:04
Was zur Hölle übersehe ich dabei?
http://www.fhem.de/commandref.html#addStateEvent
... nope ... addStateEvent ist in einem ESP- Device nicht zugelassen ... (ich unterstelle jetzt mal, das Du dieses Attribut meintest mit Deinem unkommentierten Link)
ESP_test: unknown attribute addStateEvent. Type 'attr ESP_test ?' for a detailed list.
ESP_test: unknown attribute ?, choose one of alias comment eventMap group room suppressReading userReadings verbose IODev Interval adjustValue colorpicker deepsleep disable disableRiskyCmds disabledForIntervals displayTextEncode displayTextWidth do_not_notify event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat timestamp-on-change-reading mapLightCmds maxCmdDuration parseCmdResponse pollGPIOs presenceCheck readingPrefixGPIO readingSuffixGPIOState readingSwitchText rgbGPIOs setState useSetExtensions userSetCmds wwcwGPIOs alarmDevice alarmSettings cmdIcon devStateIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel widgetOverride userattr
Nur zum Verständnis. Hast du einen Dummy auf dem ESP konfiguriert der die Daten zusammenfasst?
... nein ...
Die beiden Sensoren (BME280 & BH1750) werden beim Aufwachen über einen Portpin eingeschaltet, melden dann ihre Werte direkt an den FHEM-Controller (Send to Controller). Dann schläft der ESP wieder für 5 Minuten, bis das Spiel von vorn beginnt.
EDIT: Das Ganze ist noch im Versuchsstadium um festzustellen, in wie weit die Sache mit einer 18650-Zelle und Sleepmode realisierbar ist. Final sollen dann insg. 4 Stück dieser Sensoren zum Einsatz kommen, die dann jeweils unter dem Dachüberhang auf allen 4 Hausseiten montiert werden und in FHEM dann jeweils ein gleitender Mittelwert gebildet wird.
OK
Ich selbst mach das immer über einen Dummy der die gesammelten Daten sendet und als einziger "Send to Controller" hat.
Ich denke das ist in deinem Fall auch die einfachste Lösung. Zumal sich Fhem nicht mit unnötigen Sachen beschäftigen muss ;)
Gruß
... hmmm ... Da hast Du wohl recht: Ursachenbekämpfung ist immer besser als Sympthombekämpfung ...
Leider bin ich in Sachen ESPEasy noch nicht fit genug; bin froh, das ich diese Sache hinbekommen habe. Magst Du mir mal Deinen Dummy als Beispiel zukommen lassen, damit ich lernen kann, wie man sowas macht?
Zitat von: M_I_B am 08 Juli 2019, 12:54:11
(ich unterstelle jetzt mal, das Du dieses Attribut meintest mit Deinem unkommentierten Link)
nein, ich meine das addStateEvent bei FileLog , btw. die Commandref hat da auch einen Fehler, da der Anker nicht beim FileLog sitzt sondern beim DbLog.
Aber anyway , man sollte langsam wissen das state eine Sonderrolle hat und wenn man es unbedingt haben will in der Ausgabe es halt selbst einschalten muß :)
... wenn man sich ständig und jeden Tag damit beschäftigt, dann sollte man das wissen; da gebe ich Dir unumwunden recht. Nur ich beschäftige mich eben nicht jeden Tag damit. Es vergehen schon mal Monate, in denen ich das System nicht anfasse (warum auch, wenn alles läuft?). Da vergisst man schon mal was oder kann bestimmte Zusammenhänge schlicht nicht herstellen... woi?! :P
Ich bin zZ. nicht zu Hause, sonst hätte ich dir meine Configs angeboten ;)
Hier im Link ist das sehr gut nachvollziehbar. Auch die Rules sind sehr leicht verständlich, denke ich.
https://diyprojects.io/esp-easydht22bmp180-create-virtual-bme280-barometer/ (https://diyprojects.io/esp-easydht22bmp180-create-virtual-bme280-barometer/)
... danke Dir! Ziehe ich mir mal rein. Mal sehen, ob ich das gebacken bekomme. Wenn nicht, gehe ich Dir noch mal auf die Nerven ;D
... bekomme ich auch nicht hin ... :-[ :-[ :-[
Generic Dummy erzeugt als Quad. Das ist Device/Task 5. Darin in den 4 Feldern die Value-Namen eingetragen, das Ganze eingeschaltet und folgende Regel eingetragen:
on Clock#Time=All,**:01 do
TaskValueSet 5,1,[THP#T]
TaskValueSet 5,2,[THP#H]
TaskValueSet 5,3,[THP#P]
TaskValueSet 5,4,[LUM#B]
endon
Wenn ich das richtig verstanden habe, soll hier der Timer jede Minute die Befehle ausführen. Jeder Befehl bezieht sich auf die Task- Nummer, damit er weiß wohin damit. DIe Ziffer hinter dem Komma gibt das Feld im Dummy an,l dahinter in eckigen Klammern das Gerät nebst "reading"...
Bleibt alles auf 0,00...
Guck mal in das Logfile vom ESPEasy.
Da habe ich schon oft die Ursache von Problemen erkannt.
Besonders schauen, ob das Clock-event triggert oder es überhaupt clock-events gibt.
Ist die Clock gesetzt / per NTP gesynct?
.. ja, ich schaue mal... Und ja, die Uhr läuft und bekommt die Zeit von einem lokalen NTPd ...
Du hast da noch nen kleinen Denkfehler...
deie Zeitdefinition "on Clock#Time=All,**:01 do" läuft immer dann, wenn die Stunden:minuten-Kombi auf 01 endet.
Also jede Stunde eine Minute nach voll.
Anbei noch meine Definition meines Watchdog, da bei gestörtem WLAN/MQTT oft nur ein Reboot hilft.
//on Clock#Time=All,**:30 do //will run half past every hour
on Clock#Time=All,**:*9 do //will run alle 10 minuten
//on Clock#Time=All,**:** do //will run alle 1 minuten
TaskValueSet 12,1,%uptime%-[MQTT-IN#uptimePong]
if [Dummy#Watchdog] > 60
reboot
endif
endon
AHHH! Danke! Ich bin davon ausgegangen, das meine Def eben jede Minute läuft... Jetzt wird mir alles klar!
Wieso spendest du alles an den Controller?
... wie meinst Du das? Sorry, aber ich verstehe gerade die Frage nicht ...
Fu** Autokorrektur ;)
Ich meinte natürlich, warum sendest du alles an den Controller?
Deine devices haben zum einen ein Zeitintervall (5sec), wann sie senden und vermutlich dein Controller auch. Dazu dann noch die Meldungen durch trigger (wenn sich der Wert verändert).
Deswegen kommen da soviel logmeldungen bei dir.
Würd ich gänzlich anders machen.
Alles per rule
On System#Boot do
Publish %sysname%/ip,%ip%
timerSet,1,60
endon
On Rules#Timer=1 do
Publish %sysname%/uptime,%c_m2dhm%(%uptime%)
Publish %sysname%/h,[DHT22#h]
Publish %sysname%/t,[DHT22#t]
Publish %sysname%/ip,%ip%
timerSet,1,600
endon
On Clock#Time=All,06:00 do
Gpio,12,0
Endon
On Clock#Time=All,20:00 do
Gpio,12,1
Endon
Oder
On System#Boot do
Publish %sysname%/ip,%ip%
timerSet,1,60
endon
// aufruf ---> http://192.168.1.164/control?cmd=event,vu_on_off
On vu_on_off do
IRSEND,RAW2,UE57575F5FFF*757AFAF57AG9F57AF*757A75F575,38,90,57
endon
On Pioneer_on_off do
IRSEND,PIONEER,A55A38C7A55A38C7,64
endon
On Lauter do
IRSEND,PIONEER,A55A50AFA55A50AF,64
endon
On Leiser do
IRSEND,PIONEER,A55AD02FA55AD02F,64
endon
On Rules#Timer=1 do
Publish %sysname%/uptime,%c_m2dhm%(%uptime%)
Publish %sysname%/BMP280/DruckBMP280,[BMP280#DruckBMP280]
Publish %sysname%/BMP280/TempBMP280,[BMP280#TempBMP280]
Publish %sysname%/BMP280/FeuchteBMP280,[BMP280#FeuchteBMP280]
Publish %sysname%/DHT11/TempDHT11,[DHT11#TempDHT11]
Publish %sysname%/DHT11/FeuchteDHT11,[DHT11#FeuchteDHT11]
Publish %sysname%/ip,%ip%
timerSet,1,600
endon
... ach so meinst Du das ...
Das was ich hier getestet habe ist nicht das, was letztlich am Dach hängt (da hängt ja schon ein Versuchsgerät).
Das Versuchsgerät macht ja zwischendurch immer für 295sec ein Nickerchen, wacht für 5 sec auf, schaltet die Sensoren ein und feuert die Daten per WLAN zum FHEM-Server. Was mich daran irritiert hat ist eben, warum viele der Daten doppelt und dreifach erscheinen, obwohl der Intervall der einzelnen Tasks auf 10 Minuten gestellt ist. Von daher sollten alle Task also nur ein mal Daten preisgeben; tun sie aber nicht.
Das was ich hier beschrieben habe, kommt aber hauptsächlich von dem zweiten ESP. Der liegt hier auf dem Tisch mit identischer Sensorik und dem Unterschied, das der nicht schlafen geht, damit ich da Sachen ausprobieren kann.
Zwischenzeitlich scheine ich aber eine Lösung zu haben (für den Einschlafenden):
on System#Boot do
GPIO,12,1
endon
on WiFi#Connected do
TaskValueSet 4,1,[THP#T]
TaskValueSet 4,2,[THP#H]
TaskValueSet 4,3,[THP#P]
TaskValueSet 5,1,[LUM#B]
TaskValueSet 5,2,[VCC#V]
endon
on System#Sleep do
GPIO,12,0
endon
Eigentlich wollte ich das alles in einer Zeile haben, also like " ...TaskValueSet 4,1,V:[VCC#V] - T:[THP#T] - H:[THP#H] - ...", quasi als String, der übermittelt wird, aber das ist so wohl nicht möglich leider ...
... tja, auch das klappt nicht wirklich :-\ Das hat ein paar mal so getan wie es soll, aber nun taucht wieder folgendes im LOG auf:
2019-07-09_12:19:00 ESP_test state: H: 47.45 P: 1015.91 T: 23.15
2019-07-09_12:19:00 ESP_test state: H: 47.45 P: 1015.91 T: 23.15
2019-07-09_12:19:00 ESP_test state: B: 32.92 H: 47.45 P: 1015.91 T: 23.15 V: 4.35
2019-07-09_12:19:04 ESP_test state: B: 32.92 H: 47.45 P: 1015.91 T: 23.15 V: 4.35
2019-07-09_12:19:05 ESP_test state: B: 32.92 H: 47.45 P: 1015.91 T: 23.15 V: 4.35
P, H und T tauchen nun 5 mal auf, B und V zwei mal... Harry Hirsch ??? :( >:( Was'n das für eine Grütze zum Donnerwetter noch mal >:( >:( >:(
Tipp 1 : dem FileLog beibringen erst ab state: B zu loggen statt ab state, dann fallen schon mal die ersten beiden Einträge raus.
Tipp 2 : event-on-change-reading am ESP_test dein Freund um doppelte identische Log Einträge zu vermeiden
Tipp 1 ist gut und notiert!
Tipp 2 hatte ich schon drin, aber ich möchte ja erreichen, das der ESP eben nur einen Datensatz sendet. Das erkenne ich ja nicht, wenn ich das aktiv habe ...
Wie schon gesagt, warum sendest du alles an den Controller?
Mach einfach die hacken raus ...
... wie schon gesagt: Ich sende NICHT alles. Ausschließlich die beiden Dummys senden Daten. Und das sollten sie theoretisch nur ein einziges mal tun, nämlich dann, sobald das WLAN verfügbar ist...
Und das Theorie und Praxis hier unterschiedliche Dinge machen, ist nicht zu übersehen, auch wenn man an Stelle des Hacken den Haken raus macht ;D
Hast du es mal mit einem Delay/Intervall in den Dummy-Devices versucht?
... ja, hatte ich auch schon im WIFI- Zweig. Da muss man aber aufpassen: Der darf ja nicht zu groß werden bei insg. 5sec ON-time. Ich hatte da 2sec versucht, hat aber nichts geändert.
Ich habe gerade mal die beiden Dummys umgestellt: den Single als ersten Dummy, den Quad als zweiten; ich beobachte gerade ...
Mhhh, normalerweise sollte sogar 60 oder so funktionieren. Es heißt nicht mehr, als das er nach der Übermittlung so lange warten soll! Er wird ja dann eh herunter gefahren. Oder?
Ich habe aber noch "nie" mit DeepStby gearbeitet ;)
Im Grunde könnt's mir ja jetzt egal sein, beim mir geht's ja, aber Zeig mal bitte deine Configuration von den devices und dem Controller, aus espeasy.
... klar, kein Problem ...
on System#Boot do
GPIO,12,1
endon
on WiFi#Connected do
TaskValueSet 4,1,[THP#T]
TaskValueSet 4,2,[THP#H]
TaskValueSet 4,3,[THP#P]
TaskValueSet 4,4,[LUM#B]
TaskValueSet 5,1,[VCC#V]
endon
on System#Sleep do
GPIO,12,0
endon
sicherlich liegt es daran, wie/wann der Dummy die Daten sendet.
Wenn er eine Datenänderung erhalten hat, kann er ja nicht wissen, ob noch was nachkommt. Das Intervall von 0 ist da sicher nicht sehr hilfreich.
Sammle doch die Daten im Dummy und sende sie aus den Rules heraus (evtl. mit nem Timer).
PS: und schau dir mal MQTT an. Das ist für den Datenaustausch meiner Meinung nach besser geeignet.
... mit dem Interval habe ich auch schon gespielt. Das hat keinerlei Einfluß auf das Ergebnis... leider...
Wie sende ich denn die Daten aus den Rules heraus? Ich nutze ja im ESP die FHEM- Schnittstelle; da muss es ja dann hin, oder?
MQTT nutze ich in anderen Zusammenhängen, i.d.R. für die Kommunikation der Hauptinstanz mit den untergeordneten Geräten. Darüber hatte ich auch schon nachgedacht, macht die Sache aber deutlich unübersichtlicher auf beiden Seiten. Daher dachte ich, ich versuche es lieber erst mal mit der nativen Funktion und versuche erst mal, die Sache irgendwie ans Laufen zu bringen. Wenn alle Stricke reißen, wird wohl nichts anderes übrig bleiben... ABer irgendwie hat mich der Ehrgeiz gepackt, dsa mit dem FHEM-Teil zu bewerkstelligen.
Im Übrigen bringt auch eine Umstellung der Dummys nichts, ebensowenig wie die Umkehrung der Reihenfolge in den Rules ... Nur so nebenbei ...
doch hat es.
mir fehlt zwar noch der controller aber die 0 im interval ist es.
es sendet einmal on connect und direkt danach die 0
... hmmm, ich hatte hier keine Unterschiede ... Probiere es aber gleich noch mal aus. Dann müsste das Intervall theoretisch deutlich über den 5 Sekunden Wachzeit liegen, sagen wir mal bei (um die Mitte zu nehmen) 150sec... oder?!
... hat sich nichts geändert ...
Was aber etwas gebracht hat ist eine Anpassung des Timing, also kurze Delays jeweils vor dem Laden eines Dummy. Außer nach dem Start des Ganzen hatte ich jetzt über die ganze Nacht hinweg in Zusammenarbeit mit event-on-change-reading=state ein sauberes Logfile. Lediglich ein einziges mal fehlte der Wert des ADC; da ist das Timing wohl noch etwas zu eng, so das der gelegentlich noch nicht fertig ist...
Aber ganz ehrlich? Wirklich befriedigend ist die ganze Nummer nicht. Das ist alles krampfhafte Symptom- Bekämpfung...
Ich werde es dann noch mal mit MQTT versuchen. Muss ich mich aber erst mal wieder einlesen, da ich dsa seit bestimmt 2-3 Jahren nicht mehr gemacht habe. Seit dem laufen die ehemals installierten "Nachrichtenkanäle" problemlos, so das keine Notwendigkeit bestand, das anzufassen.
Hat sich da bei FHEM bezgl. MQTT in dieser Zeit was wesentliches verändert und wenn ja was und wo kann ich das nachlesen resp. aktuelle Beispiele resp. HowTo's studieren?
Komisch..... Ich gehe davon aus das da immer noch ein Bug drin ist. Bei mir laufen und übermitteln die sehr zuverlässig. Ich kann es leider nicht testen, da immer noch unterwegs.
Unabhängig davon, denke ich, wirst du auf Dauer nicht wirklich glücklich mit den ESP an einem 18650- AKKU.
Hast du dir schonmal dieses batteriebetriebene Projekt angesehen? Scheint zumindest recht weit fortgeschritten und beinhaltet die Sensoren Helligkeit, Luftdruck, Temperatur und Luftfeuchtigkeit.https://forum.fhem.de/index.php/topic,20620.msg946499.html#msg946499 (https://forum.fhem.de/index.php/topic,20620.msg946499.html#msg946499)
Gruß
... naja, ich will ja zeitnah eine funktionierende Sensorik hier haben (müssen), da die IT- Sensoren fast alle den Geist gemacht haben... Daher kann ich auf dieses Projekt nicht wirklich warten...
Mal was anderes:
Ich kann ja aus den Rules direkt HTTP senden. Das wollte ich jetzt mal als Alternative probieren, komme aber nicht so ganz dahinter, wie's geht...
Ich habe einen Dummy ESP_20 angelegt ohne weitere Attribute. Nun versuche ich aus den Rules des ESP mit folgender Zeile die Daten an FHEM zu senden:
SendToHTTP 192.168.1.10,8083,fhem?cmd=setreading%20ESP_20%20state%20VCC%20[VCC#VCC]%20TMP%20[THP#TMP]%20HUM%20[THP#HUM]%20BRI%20[LUM#BRI]%20PRS%20[THP#BRS]%20RSSI%20[SYS#RSSI*-1]%20LOAD%20[SYS#LOAD]
Da tut sich aber nischt... Gibt es da ein HowTo zu oder ist der Fehler so simpel, das Du mir da auf die Sprünge helfen kannst?
Nee, sorry 8)
Ich mach alles ausschließlich mit dem ESPEasy-Modul in Fhem! Daher hab ich mich nie damit beschäftigt. Warum auch.