Hallo zusammen,
ich habe einige Devices, bei denen ich zeitgesteuert einige Werte ermittle und diese in die Datenbank schreibe. z.B.
prg_Daily_PVStat()
{
#
# Wert vom Tag auslesen
$data{DPval2} = ReadingsVal("STP4","Tagesertrag",0);
# Tagesertrag in TageserstragStat speichern
fhem ("setreading STP4 TagesertragStat $data{DPval2}");
}
Im Device habe ich event-on-change-reading für TagesertragStat gesetzt, um zu vermeiden, dass bei jeder Änderung Einträge in die DB geschrieben werden.
Soweit erstmal ok und funktioniert auch.
Nun zum Problem: Wenn die Funktion ausgeführt wird, löst das den Trigger aus, offenbar wird das aber zeitgleich vom Device auch getriggert, so dass ich in der Datenbank 2x den Selben Eintrag mit dem selben Timestamp habe. Kann ich das verhindern (ohne Index in der DB)?
VG
F.
Ich glaube die Antwort hab ich mir grad selbst gegeben. Ich hatte die Funktion per notify gescheduled, wenn ich auf AT umstelle, sollte das denke ich erledigt sein...
Update: War doch schon ein AT, der Name war nur falsch :( Hatte es notify genannt. Hmm, damit wieder zurück auf Anfang...
event-on-change-reading alleine ist kein Garant dafuer, dass Events gefiltert werden, dass haengt auch von anderen Attributen (event-on-update-reading, event-min-interval, etc) ab. Dass das gleiche Event von einem at und von dem Geraet glaichzeitig erzeugt wird, ist moeglich, aber unwahrscheinlich.
Ich vermute, dass die Ursache anderswo liegt, und fuer konkrete Hilfe muss man mehr wissen, als diesen kleinen Ausschnitt.
Hier die Definition vom Device:
nternals:
DEF 3 30 192.168.1.171:502 TCP
DeviceName 192.168.1.171:502
EXPECT idle
FD 21
FUUID 638d30b2-f33f-1a0c-ce3d-639131a7a1738e5e
IODev STP4
Interval 30
LASTOPEN 1671753391.58586
MODBUSID 3
MODE master
MODULEVERSION Modbus 4.4.11 - 5.10.2022
NAME STP4
NOTIFYDEV global
NR 850
NTFY_ORDER 50-STP4
PARTIAL
PROTOCOL TCP
STATE 0: Watt Aktuelle Leistung
TCPConn 1
TYPE ModbusAttr
devioLoglevel 3
eventCount 1
nextOpenDelay 60
Helper:
DBLOG:
state:
DBLog_DailyPVPower:
TIME 1671753402.06143
VALUE CONNECTED
logdb:
TIME 1671753402.11401
VALUE CONNECTED
QUEUE:
READ:
BUFFER
READINGS:
2022-12-23 20:14:01 Gesamtertrag 299687
2022-12-23 20:14:00 Status OK
2022-12-23 20:14:02 Tagesertrag 1435
2022-12-22 22:27:44 TagesertragStat 0
2022-12-23 20:14:02 Temperatur 0
2022-12-23 20:14:02 Wirkleistung 0
2022-12-23 00:56:42 state opened
REMEMBER:
lid 3
lname STP4
lrecv 1671822842.69568
lsend 1671822842.66598
defptr:
STP4 3
gotReadings:
Temperatur 0
lastRead:
h30201 1671822840.92121
h30529 1671822841.05193
h30535 1671822842.41459
h30775 1671822842.56331
h30953 1671822842.69783
Attributes:
DbLogExclude Status, Temperatur, Wirkleistung, state, Gesamtertrag
alias SUNNY TRIPOWER 4.0
dev-h-defExpr $val & 0x1FFFFFFF
dev-h-defLen 2
dev-h-defPoll 1
dev-h-defUnpack N
event-on-change-reading TagesertragStat
group 4: Energie
icon measure_photovoltaic_inst
obj-h30201-map 35:Fehler, 303:Aus, 307:OK, 455:Warnung
obj-h30201-reading Status
obj-h30529-reading Gesamtertrag
obj-h30535-reading Tagesertrag
obj-h30775-reading Wirkleistung
obj-h30953-reading Temperatur
room Energie
stateFormat Wirkleistung: Watt Aktuelle Leistung
userReadings TagesertragStat
verbose 0
Und hier noch das AT:
Internals:
COMMAND { prg_Daily_PVStat() }
DEF *21:59 { prg_Daily_PVStat() }
FUUID 63a2eeab-f33f-1a0c-ba0b-d401334af55bcfb3
NAME DailyPVStatSet
NR 854
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 21:59:00
TIMESPEC 21:59
TRIGGERTIME 1671829140
TRIGGERTIME_FMT 2022-12-23 21:59:00
TYPE at
READINGS:
2022-12-23 00:56:26 state Next: 21:59:00
Attributes:
group Stromzaehler
room Energie
Falls Du noch was brauchst, gib Bescheid...
lösche das zusätzliche userreadings attr für "TagesertragStat".
Ich hab es gelöscht, daran dürfte es aber nicht liegen. Bei einem anderen Device sieht das so aus:
Internals:
FUUID 5d59ab9b-f33f-1a0c-d502-b97c0d24b62eb3ac
NAME DailyPower
NR 687
STATE 11.0782
TYPE dummy
READINGS:
2022-12-22 23:59:00 state 11.0782
Attributes:
event-on-change-reading state
group Stromzaehler
room Energie
Und hier hab ich auch die doppelten Einträge.
Der aktuelle AT LAuf hat das bestätigt - wieder 2 Einträge.
Kann das Problem nicht nachstellen, und sehe auch keinen Grund fuer doppelten Eintrag.
Was sieht man im EventMonitor nach einem "set DailyPVStatSet execNow" ?
Womoeglich ist DbLog falsch konfiguriert?
ergänze deine funktion mal mit dem setzen eines zusätzlichen readings, das noch keiner in deinem fhem kennen kann wie zb:
fhem ("setreading STP4 weihnachtsmann help_me");
anschliessend ebenfalls execNow.
edit: wird die funktion noch irgendwo in fhem aufgerufen?
Hier erstmal die Config der logdb:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db.conf
DEF ./db.conf .*:.*
FUUID 5d432355-f33f-1a0c-d082-1a5bb20efc8d3279
FVERSION 93_DbLog.pm:v4.13.3-s26750/2022-11-26
MODE asynchronous
MODEL MYSQL
NAME logdb
NR 20
NTFY_ORDER 50-logdb
PID 24851
REGEXP .*:.*
STATE connected
TYPE DbLog
UTF8 1
dbconn mysql:database=fhem;host=192.168.1.103;port=3306
dbuser fhemuser
eventCount 1
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
PACKAGE main
READINGCOL 64
TC current
TH history
TYPECOL 64
UNITCOL 32
VALUECOL 128
VERSION 4.13.3
Helper:
DBLOG:
state:
logdb:
TIME 1671753393.30694
VALUE connected
READINGS:
2022-12-24 12:56:08 CacheOverflowLastNum 0
2022-10-02 10:33:25 CacheOverflowLastState normal
2022-12-24 12:56:08 CacheUsage 0
2022-12-24 12:56:08 NextSync 2022-12-24 12:56:38 or if CacheUsage 500 reached
2022-12-24 12:56:08 state connected
Attributes:
asyncMode 1
bulkInsert 1
commitMode basic_ta:on
event-on-change-reading state
group Logeinträge
room System
useCharfilter 1
Die sonstigen Logeinträge sehen ok aus, da ist nichts doppelt. Die Funktion wird nur über AT aufgerufen, so wie konfiguriert, sonst nirgends.
Beim manuellen Ausführen "set DailyPVStatSet execNow" sehe ich folgendes:
2022-12-24 13:04:14 ModbusAttr STP4 TagesertragStat: 1736
2022-12-24 13:04:14 at DailyPVStatSet execNow
und in der Datenbank hab ich danach nur einen Eintrag. Das funktioniert also komischerweise.