Hi,
ich habe mein FHEM umgezogen auf einen neuen Raspberry, dabei habe ich natürlich auch geupdated.
Mir ist aufgefallen dass:
DbLogInclude cur_power:60:force
nicht mehr funktioniert.
Bin ziemlich ratlos was das angeht. Alles andere scheint zu gehen.
Das Device logged, aber nur wenn Werte kommen.
Leider nicht alle 60 Sekunden wenn keine Werte kommen.
Hab nun auch mit Verbose 5 geschaut.
Beim Device nichts zu sehen.
Bei LogDb steht zwar etwas drin zu den Devices.
Das Force wird aber nicht beachtet.
Weder beschränkt es bei vielen Events das wegschreiben,
noch schreibt es bei keinem Event alle 60 sek etwas.
Log sieht so aus:
2023.02.11 17:28:16 4: DbLog logdb - ################################################################
2023.02.11 17:28:16 4: DbLog logdb - ### start of new Logcycle ###
2023.02.11 17:28:16 4: DbLog logdb - ################################################################
2023.02.11 17:28:16 4: DbLog logdb - number of events received: 7 of device: stefan.stromzaehler
2023.02.11 17:28:16 4: DbLog logdb - check Device: stefan.stromzaehler , Event: total_consumption: 4973939.4
2023.02.11 17:28:16 5: DbLog logdb - parsed Event: stefan.stromzaehler , Event: total_consumption: 4973939.4
2023.02.11 17:28:16 5: DbLog logdb - DbLogInclude of "stefan.stromzaehler": power:60:force,total_consumption:300:force
2023.02.11 17:28:16 4: DbLog logdb - check Device: stefan.stromzaehler , Event: power_L2: 186
2023.02.11 17:28:16 5: DbLog logdb - parsed Event: stefan.stromzaehler , Event: power_L2: 186
2023.02.11 17:28:16 5: DbLog logdb - DbLogInclude of "stefan.stromzaehler": power:60:force,total_consumption:300:force
2023.02.11 17:28:16 4: DbLog logdb - check Device: stefan.stromzaehler , Event: power: 194
2023.02.11 17:28:16 5: DbLog logdb - parsed Event: stefan.stromzaehler , Event: power: 194
2023.02.11 17:28:16 5: DbLog logdb - DbLogInclude of "stefan.stromzaehler": power:60:force,total_consumption:300:force
2023.02.11 17:28:16 4: DbLog logdb - check Device: stefan.stromzaehler , Event: statTotal_consumption: Hour: 87.4 Day: 2345.9 Month: 35801.8 Year: 139354.3
2023.02.11 17:28:16 5: DbLog logdb - parsed Event: stefan.stromzaehler , Event: statTotal_consumption: Hour: 87.4 Day: 2345.9 Month: 35801.8 Year: 139354.3
2023.02.11 17:28:16 5: DbLog logdb - DbLogInclude of "stefan.stromzaehler": power:60:force,total_consumption:300:force
2023.02.11 17:28:16 4: DbLog logdb - check Device: stefan.stromzaehler , Event: statTotal_consumptionDay: 2345.9
2023.02.11 17:28:16 5: DbLog logdb - parsed Event: stefan.stromzaehler , Event: statTotal_consumptionDay: 2345.9
2023.02.11 17:28:16 5: DbLog logdb - DbLogInclude of "stefan.stromzaehler": power:60:force,total_consumption:300:force
2023.02.11 17:28:16 4: DbLog logdb - check Device: stefan.stromzaehler , Event: statTotal_consumptionMonth: 35801.8
2023.02.11 17:28:16 5: DbLog logdb - parsed Event: stefan.stromzaehler , Event: statTotal_consumptionMonth: 35801.8
2023.02.11 17:28:16 5: DbLog logdb - DbLogInclude of "stefan.stromzaehler": power:60:force,total_consumption:300:force
2023.02.11 17:28:16 4: DbLog logdb - check Device: stefan.stromzaehler , Event: statTotal_consumptionYear: 139354.3
2023.02.11 17:28:16 5: DbLog logdb - parsed Event: stefan.stromzaehler , Event: statTotal_consumptionYear: 139354.3
2023.02.11 17:28:16 5: DbLog logdb - DbLogInclude of "stefan.stromzaehler": power:60:force,total_consumption:300:force
Gibt es da irgendeine Einstellung die ich vergessen habe?
Oder ist etwas in der Version kaputt?
Wie könnte ich mehr Infos bekommen?
Hier mal die Infos zu DBLog und zum Device:
DBLog:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db.conf
DEF ./db.conf .*:.*
FD 5
FUUID 5c4ba0dd-f33f-0c45-254e-2422492fda428fa1
FVERSION 93_DbLog.pm:v5.8.0-s27165/2023-02-01
MODE asynchronous
MODEL SQLITE
NAME logdb
NR 2
NTFY_ORDER 50-logdb
PID 10508
REGEXP .*:.*
SBP_PID 10511
SBP_STATE running
STATE connected
TYPE DbLog
dbconn SQLite:dbname=/opt/fhem/fhem.db
dbuser
eventCount 1566
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
PACKAGE main
READINGCOL 64
TC current
TH history
TYPECOL 64
UNITCOL 32
VALUECOL 128
VERSION 5.8.0
OLDREADINGS:
READINGS:
2023-02-11 16:49:53 CacheOverflowLastNum 0
2021-03-06 19:28:16 CacheOverflowLastState normal
2023-02-11 16:50:00 CacheUsage 6
2023-02-11 16:49:53 NextSync 2023-02-11 16:50:53 or when CacheUsage 500 is reached
2023-02-11 16:49:53 background_processing_time 0.0059
2023-02-11 16:49:53 sql_processing_time 0.0032
2023-02-11 16:49:53 state connected
2019-05-26 19:09:51 userCommand SELECT value FROM "history" WHERE "DEVICE" = 'Heizoel_Abstands_Sensor' and "TIMESTAMP" = '2018-05-30 12:20:12'
Attributes:
DbLogSelectionMode Include
DbLogType History
asyncMode 1
cacheEvents 2
cacheLimit 500
insertMode 0
showproctime 1
syncInterval 60
verbose 2
`
Device
Internals:
DEF tuya_cloud tuya_cloud_connector XXX
DEVICEID XXX
FHEMPYTYPE tuya_cloud
FUUID 61a90b30-f33f-0c45-5517-9cbb59d124d39fec
IODev local_pybinding
NAME Sybille_Tablet_bf68d9b41c16be3713vcc1
NR 2022
PYTHONTYPE tuya_cloud
STATE off </br>
</br>230.0 V
</br>0.0 W
</br>0.0 mA
TYPE fhempy
eventCount 2936
Helper:
DBLOG:
cur_power:
logdb:
TIME 1676122110.02238
VALUE 11.9
READINGS:
2023-02-11 08:09:25 active_time 1638468323
2023-02-11 14:34:32 add_ele 0.005
2023-02-11 08:09:25 biz_type 0
2023-02-11 08:09:25 category cz
2023-02-11 08:09:35 child_lock off
2023-02-11 08:09:35 countdown_1 0.0
2023-02-11 08:09:25 create_time 1638468323
2023-02-11 14:29:17 cur_current 0.0
2023-02-11 14:29:17 cur_power 0.0
2023-02-11 16:50:46 cur_voltage 230.0
2023-02-11 08:09:35 cycle_time
2023-02-11 08:09:25 icon https://images.tuyaeu.com/smart/icon/ay15148582002916nitB/c58a91c23c2e2b5309c7c5d776871390.png
2023-02-11 08:09:25 id bf68d9b41c16be3713vcc1
2023-02-11 08:09:25 ip 87.158.205.193
2023-02-11 08:09:25 lat 49.6104
2023-02-11 08:09:35 light_mode relay
2023-02-11 08:09:25 local_key 68c71bfc9491dabc
2023-02-11 08:09:25 lon 8.7261
2023-02-11 08:09:25 model BSD34BP
2023-02-11 08:09:25 name Sybille Tablet
2023-02-11 08:09:25 online on
2023-02-11 08:09:35 overcharge_switch off
2023-02-11 08:09:25 owner_id 39691875
2023-02-11 08:09:25 product_id apszn7k8yhgsin28
2023-02-11 08:09:25 product_name WIFI 插座
2023-02-11 08:09:35 random_time
2023-02-11 08:09:35 relay_status last
2023-02-11 14:29:11 state off
2023-02-11 08:09:25 sub off
2023-02-10 23:12:53 switch_1 off
2023-02-11 08:09:35 switch_inching
2023-02-11 08:09:25 time_zone +01:00
2023-02-11 08:09:25 uid eu1634560510538qIss1
2023-02-11 08:09:25 update_time 1640052275
2023-02-11 08:09:25 uuid 12958095a839e231
args:
Sybille_Tablet_bf68d9b41c16be3713vcc1
fhempy
tuya_cloud
tuya_cloud_connector
bf68d9b41c16be3713vcc1
argsh:
Attributes:
DbLogInclude cur_power:60:force
alias Sybille Tablet
group Steckdosen_Tuya
room OG,fhempy
stateFormat state </br>
</br>cur_voltage V
</br>cur_power W
</br>cur_current mA
Ok, nach etwas rumspielen habe ich nun herausgefunden das wohl
cur_power, state:60:force
sich nur auf state auswirkt, aber nicht auf curr_power.
Sobald ich nur curr_power:60:force schreibe scheint er es zu begrenzen und schreibt nur alle 60 Sekunden einen Wert.
Das andere scheine ich falsch zu verstehen.
So wie ich das sehe wirkt ein
cur_power:60:force, nicht so dass wenn es kein Event gibt trotzdem nach 60 sekunden geschrieben wird.
Da brauche ich wohl ein add_log.
Seltsam das es vorher ging, aber eventuell hat sich da etwas an fhempy geändert und früher kam da ab und zu ein Event.
Dominik hat da viel geschraubt, die Vermutung liegt nahe.
Kann mir jemand das beschriebene bestätigen, passt eigentlich zu Doku.
Gruß und Danke,
Stefan
Zitat
So wie ich das sehe wirkt ein
cur_power:60:force, nicht so dass wenn es kein Event gibt trotzdem nach 60 sekunden geschrieben wird.
Da brauche ich wohl ein add_log.
Ja das ist so. DbLogInclude erzwingt seinerseits keine Events wenn keine kommen, sondern behandelt sie nur entsprechend.
Um regelmäßig einen Log-Eintrag zu erzeugen benutzt man "set <name> addLog ..." im DbLog.
Dieses Verfahren ist auch nicht neu.
Hi, danke.
Da hat sich wohl was am verhalten von fhempy geändert.
Habe addLogs eingebaut und alles ist gut.
:60:force
gilt auch immer nur hinter dem jeweiligen Reading?
Also DBLogInclude aaa,bbb:60:force würde nur bbb mit 60 und force behandeln.
aaa wäre einfach nur included?
Dann passt alles zu meinen Beobachtungen und ich kann damit umgehen.
Danke und Gruß,
Stefan
Zitat
:60:force
gilt auch immer nur hinter dem jeweiligen Reading?
Also DBLogInclude aaa,bbb:60:force würde nur bbb mit 60 und force behandeln.
aaa wäre einfach nur included?
So ist es.
Perfekt, dann hat sich alles geklärt und es lag an den fixen in fhempy.
Bin ich froh dass alles umgezogen ist und wieder läuft ;-)
Ich dank dir vielmals!
Gruß,
Stefan
Zitat von: DS_Starter am 11 Februar 2023, 21:33:01
Ja das ist so. DbLogInclude erzwingt seinerseits keine Events wenn keine kommen, sondern behandelt sie nur entsprechend.
Um regelmäßig einen Log-Eintrag zu erzeugen benutzt man "set <name> addLog ..." im DbLog.
Dieses Verfahren ist auch nicht neu.
Hallo Heiko,
Stefanru hat mich auf diesen Hinweiszu addlog aufmersam gemacht.
Ich habe gestern folgendes AT erzeugt:
[code]define DbLog_addlog_fhempy_energy at +*01:00:00 set dblog_THB addlog TYPE=fhempy:energy
attr DbLog_addlog_fhempy_energy DbLogExclude .*
attr DbLog_addlog_fhempy_energy alias addlog fhempy:energy
attr DbLog_addlog_fhempy_energy disable 0
attr DbLog_addlog_fhempy_energy group - addlogs
attr DbLog_addlog_fhempy_energy icon clock
attr DbLog_addlog_fhempy_energy room Datenbank->At
attr DbLog_addlog_fhempy_energy verbose 5
# COMMAND set dblog_THB addlog TYPE=fhempy:energy
# DEF +*01:00:00 set dblog_THB addlog TYPE=fhempy:energy
# FUUID 63fb9fb8-f33f-fd5f-9d48-7a570aebba78d6be
# NAME DbLog_addlog_fhempy_energy
# NR 2561
# NTM 16:46:58
# PERIODIC yes
# RELATIVE yes
# REP -1
# STATE Next: 16:46:58
# TIMESPEC 01:00:00
# TRIGGERTIME 1677512818.00786
# TRIGGERTIME_FMT 2023-02-27 16:46:58
# TYPE at
# eventCount 1
# READINGS:
# 2023-02-27 15:46:58 state Next: 16:46:58
#
setstate DbLog_addlog_fhempy_energy Next: 16:46:58
setstate DbLog_addlog_fhempy_energy 2023-02-27 15:46:58 state Next: 16:46:58
[/code]
daraufhin wurden wunderschön aalle TUYA-readings in die DB geschrieben .
Das hörte nach 1mal ausführen dann auf.
Soeben habe ich es manuell (executenow) gestartet:
Fehler im logfile:
023.02.27 15:39:55 3: DbLog dblog_THB - SubProcess connected to fhem
2023.02.27 15:47:34 3: DbLog_addlog_fhempy_energy: Unknown argument, choose one of addCacheLine addLog clearReadings:noArg count:noArg configCheck:noArg countNbl:noArg deleteOldDays deleteOldDaysNbl eraseReadings:noArg listCache:noArg reduceLog reduceLogNbl rereadcfg:noArg reopen stopSubProcess:noArg userCommand commitCache:noArg exportCache:nopurge,purgecache purgeCache:noArg importCachefile
gestern gegen späten Abend funktionierte das noch (einmalig)
es ging auch manchmal der direkte Befehl
set dblog_THB addlog TYPE=fhempy:energy
das ging nun auch momentan:
2023.02.27 15:56:10 3: DbLog dblog_THB - addLog created - TS: 2023-02-27 15:56:10, Device: TUYA_SP01, Type: FHEMPY, Event: addLog, Reading: energy, Value: 0.664, Unit:
2023.02.27 15:56:10 3: DbLog dblog_THB - addLog created - TS: 2023-02-27 15:56:10, Device: TUYA_SP02, Type: FHEMPY, Event: addLog, Reading: energy, Value: 9.932, Unit:
2023.02.27 15:56:10 3: DbLog dblog_THB - addLog created - TS: 2023-02-27 15:56:10, Device: TUYA_SP03, Type: FHEMPY, Event: addLog, Reading: energy, Value: 2.029, Unit:
2023.02.27 15:56:10 3: DbLog dblog_THB - addLog created - TS: 2023-02-27 15:56:10, Device: TUYA_SP04, Type: FHEMPY, Event: addLog, Reading: energy, Value: 1.0, Unit:
2023.02.27 15:56:10 3: DbLog dblog_THB - addLog created - TS: 2023-02-27 15:56:10, Device: TUYA_SP05, Type: FHEMPY, Event: addLog, Reading: energy, Value: 0.54, Unit:
2023.02.27 15:56:10 3: DbLog dblog_THB - addLog created - TS: 2023-02-27 15:56:10, Device: TUYA_SP06, Type: FHEMPY, Event: addLog, Reading: energy, Value: 4.141, Unit:
Woran kann das liegen, dass dieser Befehl nur manchmal tut?
vg
Thomas
ansonsten ist das mit addlog eine feine Sache, da es ja schön mit TYPE=
maskierbar ist.
Es hat mir das manuelle Bearbeiten von ca. 80 TUYA-Devices mit "event-min-interval" "change on" "update on" erspart.
Ich brauche ja in der Tat nur einmal am Tag die energy-Werte.
Zitat
Woran kann das liegen, dass dieser Befehl nur manchmal tut?
Das kann ich mir nicht vorstellen und konnte es bisher bei mir auch nicht nachvollziehen.
Poste bitte noch ein List vom DbLog Device. Vllt. kann ich dann etwas nachstellen.
Zitat von: DS_Starter am 27 Februar 2023, 20:31:03
Das kann ich mir nicht vorstellen und konnte es bisher bei mir auch nicht nachvollziehen.
Poste bitte noch ein List vom DbLog Device. Vllt. kann ich dann etwas nachstellen.
gerne:
[code]define dblog_THB DbLog ./configDB.conf .*:.*
attr dblog_THB DbLogInclude energy,cur_power,countHistory,countCurrent,temperature,temperature2,humidity,va_humidity,humidity_value,desiredTemperature,valveposition,power
attr dblog_THB DbLogSelectionMode Exclude/Include
attr dblog_THB DbLogType Current/History
attr dblog_THB alias DbLog THB
attr dblog_THB asyncMode 1
attr dblog_THB cacheLimit 5000
attr dblog_THB comment ./configDB.conf .*:(state|temperature|power|humidity|va_temperature|va_humidity|humidity_value|desiredTemperature|valveposition|\\
\/buderus:heatSources\/systemPressure|CHpumpModulation|actualDHWPower|actualCHPower|flameStatus|\\
applianceSupplyTemperature|actualSupplyTemperature|supplyTemperatureSetpoint|outdoor_t1|supply_t1|supply_t1_setpoint|\\
actualTemp|currentSetpoint|charge|chargeDuration|setpoint|singleChargeSetpoint|workingTime|oilfox_metering_liters).*
attr dblog_THB commitMode ac:on_ta:off
attr dblog_THB excludeDevs global,Log.*,HUE.*,hue.*,TUYA_S.*,TUYA_C.*,TUYA_E.*, TUYA_B.*,MAX_0022b6.*,.*#.*dp_.*,*#.*RSSI.*
attr dblog_THB insertMode 1
attr dblog_THB room Datenbank->Produktiv
attr dblog_THB stateFormat History: [$name:countHistory] , Current: [$name:countCurrent] , Update: [$name:countHistory:t],
attr dblog_THB syncInterval 30
attr dblog_THB useCharfilter 1
attr dblog_THB verbose 3
# COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
# CONFIGURATION ./configDB.conf
# DEF ./configDB.conf .*:.*
# FD 5
# FUUID 63a33b3f-f33f-fd5f-7f81-5787629cdd49cde5
# FVERSION 93_DbLog.pm:v5.8.4-s27271/2023-02-25
# MODE asynchronous
# MODEL MYSQL
# NAME dblog_THB
# NR 2
# NTFY_ORDER 50-dblog_THB
# PID 14619
# REGEXP .*:.*
# SBP_PID 14620
# SBP_STATE running
# STATE History: [dblog_THB:countHistory] , Current: [dblog_THB:countCurrent] , Update: [dblog_THB:countHistory:t],
# TYPE DbLog
# UTF8 1
# dbconn mysql:database=fhem;host=localhost;port=3306
# dbuser fhemuser
# eventCount 473
# HELPER:
# COLSET 1
# DEVICECOL 64
# EVENTCOL 512
# OLDSTATE connected
# PACKAGE main
# READINGCOL 64
# TC current
# TH history
# TYPECOL 64
# UNITCOL 32
# VALUECOL 128
# VERSION 5.8.4
# Helper:
# DBLOG:
# CacheOverflowLastNum:
# dblog_THB:
# TIME 1677532142.36293
# VALUE 0
# state:
# dblog_THB:
# TIME 1677517983.59281
# VALUE connected
# OLDREADINGS:
# READINGS:
# 2023-02-27 22:09:02 CacheOverflowLastNum 0
# 2022-12-31 19:49:09 CacheOverflowLastState normal
# 2023-02-27 22:09:14 CacheUsage 49
# 2023-02-27 22:09:02 NextSync 2023-02-27 22:09:32 or when CacheUsage 5000 is reached
# 2023-02-27 22:09:03 state connected
#
setstate dblog_THB History: [dblog_THB:countHistory] , Current: [dblog_THB:countCurrent] , Update: [dblog_THB:countHistory:t],
setstate dblog_THB 2023-02-27 22:09:02 CacheOverflowLastNum 0
setstate dblog_THB 2022-12-31 19:49:09 CacheOverflowLastState normal
setstate dblog_THB 2023-02-27 22:09:14 CacheUsage 49
setstate dblog_THB 2023-02-27 22:09:02 NextSync 2023-02-27 22:09:32 or when CacheUsage 5000 is reached
setstate dblog_THB 2023-02-27 22:09:03 state connected
[/code]
Es ist nichts ungewöhnliches zu entdecken.
Führe im DbLog ein
set dblog_THB addlog TYPE=fhempy:energy
mehrfach manuell aus. Das dient nur dem Check ob das Problem im DbLog zu suchen ist oder in der AT-Definition.
Zitat von: DS_Starter am 27 Februar 2023, 22:26:55
Es ist nichts ungewöhnliches zu entdecken.
Führe im DbLog ein
set dblog_THB addlog TYPE=fhempy:energy
mehrfach manuell aus. Das dient nur dem Check ob das Problem im DbLog zu suchen ist oder in der AT-Definition.
ok gemacht ... direkt mehrfach geht nun
und auch mit exedNow :_)
sehe allerdings vom stündlichen AT nichts im log
das ist das AT DEF:
[code]define DbLog_addlog_fhempy_energy at +*01:00:00 set dblog_THB addlog TYPE=fhempy:energy
attr DbLog_addlog_fhempy_energy DbLogExclude .*
attr DbLog_addlog_fhempy_energy alias addlog fhempy:energy
attr DbLog_addlog_fhempy_energy disable 0
attr DbLog_addlog_fhempy_energy group - addlogs
attr DbLog_addlog_fhempy_energy icon clock
attr DbLog_addlog_fhempy_energy room Datenbank->At
attr DbLog_addlog_fhempy_energy verbose 5
# COMMAND set dblog_THB addlog TYPE=fhempy:energy
# DEF +*01:00:00 set dblog_THB addlog TYPE=fhempy:energy
# FUUID 63fb9fb8-f33f-fd5f-9d48-7a570aebba78d6be
# NAME DbLog_addlog_fhempy_energy
# NR 2560
# NTM 23:12:26
# PERIODIC yes
# RELATIVE yes
# REP -1
# STATE Next: 23:12:26
# TIMESPEC 01:00:00
# TRIGGERTIME 1677535946.84554
# TRIGGERTIME_FMT 2023-02-27 23:12:26
# TYPE at
# eventCount 4
# READINGS:
# 2023-02-27 22:12:27 state Next: 23:12:26
#
setstate DbLog_addlog_fhempy_energy Next: 23:12:26
setstate DbLog_addlog_fhempy_energy 2023-02-27 22:12:27 state Next: 23:12:26
[/code]
Zitat
sehe allerdings vom stündlichen AT nichts im log
Genauer .... nichts in der Datenbank oder kein Eintrag im Logfile ?
Zitat von: DS_Starter am 27 Februar 2023, 23:03:14
Genauer .... nichts in der Datenbank oder kein Eintrag im Logfile ?
muss mich korrigieren , das execNow schlug wohl doch fehl:
2023.02.27 22:41:18 3: DbLog_addlog_fhempy_energy: Unknown argument, choose one of addCacheLine addLog clearReadings:noArg count:noArg configCheck:noArg countNbl:noArg deleteOldDays deleteOldDaysNbl eraseReadings:noArg listCache:noArg reduceLog reduceLogNbl rereadcfg:noArg reopen stopSubProcess:noArg userCommand commitCache:noArg exportCache:nopurge,purgecache purgeCache:noArg importCachefile
2023.02.27 23:07:33 1: PERL WARNING: Argument "xxxx xxxx" isn't numeric in numeric eq (==) at ./FHEM/33_readingsGroup.pm line 1177.
in der DB kam nur das directCommand an
Guten Morgen habe nun erwartungsgemäß alle 2 Stunden eine Eintrag im log:2023.02.28 02:12:27 3: DbLog_addlog_fhempy_energy: Unknown argument, choose one of addCacheLine addLog clearReadings:noArg count:noArg configCheck:noArg countNbl:noArg deleteOldDays deleteOldDaysNbl eraseReadings:noArg listCache:noArg reduceLog reduceLogNbl rereadcfg:noArg reopen stopSubProcess:noArg userCommand commitCache:noArg exportCache:nopurge,purgecache purgeCache:noArg importCachefile
2023.02.28 02:12:27 5: redefine at command DbLog_addlog_fhempy_energy as +*01:00:00 set dblog_THB addlog TYPE=fhempy:energy
und das nochmals da zugehörige AT :
[code]define DbLog_addlog_fhempy_energy at +*01:00:00 set dblog_THB addlog TYPE=fhempy:energy
attr DbLog_addlog_fhempy_energy DbLogExclude .*
attr DbLog_addlog_fhempy_energy alias addlog fhempy:energy
attr DbLog_addlog_fhempy_energy disable 0
attr DbLog_addlog_fhempy_energy group - addlogs
attr DbLog_addlog_fhempy_energy icon clock
attr DbLog_addlog_fhempy_energy room Datenbank->At
attr DbLog_addlog_fhempy_energy verbose 5
# COMMAND set dblog_THB addlog TYPE=fhempy:energy
# DEF +*01:00:00 set dblog_THB addlog TYPE=fhempy:energy
# FUUID 63fb9fb8-f33f-fd5f-9d48-7a570aebba78d6be
# NAME DbLog_addlog_fhempy_energy
# NR 2560
# NTM 09:12:26
# PERIODIC yes
# RELATIVE yes
# REP -1
# STATE Next: 09:12:26
# TIMESPEC 01:00:00
# TRIGGERTIME 1677571946.84554
# TRIGGERTIME_FMT 2023-02-28 09:12:26
# TYPE at
# eventCount 15
# READINGS:
# 2023-02-28 08:12:27 state Next: 09:12:26
#
setstate DbLog_addlog_fhempy_energy Next: 09:12:26
setstate DbLog_addlog_fhempy_energy 2023-02-28 08:12:27 state Next: 09:12:26
[/code]
was stimmt daran nicht?
lg Thomas
addlog -> addLog
Zitat von: DS_Starter am 28 Februar 2023, 09:23:13
addlog -> addLog
oh wie peinlich :'( danke schön
was anderes:
über statistics bekomme zwar readings wie:
statdayEnergy
Hour: 0.000 Day: 2.408 Month: 2.408 Year: 2.408 (since: 2023-02-28 )
dies obswohl ich als period nur day gesetzt hat.
Ich finde auch keine Möglichkeit, das Reading anders zu formatieren
kann ich ins dblog nur den Teil day also
2.408
extrahieren ? und wie?
Zitat
kann ich ins dblog nur den Teil day also
Code: [Auswählen]
2.408
extrahieren ? und wie?
Ja, ich sehe die Möglichkeit ein userReading zu erzeugen und dieses zu loggen oder valueFn in Dblog zu nutzen.
Beides würde mit der Extraktion über ein Regex funktionieren.
Hier als Beispiel für valueFn (ungetestet):
{
if ($DEVICE eq '<Device>' && $READING eq 'statdayEnergy') {
$VALUE =~ /Day:.(\d+(.\d+)?)/;
$VALUE = $1;
}
}
(Fehler korrigiert)
ich kriege das TUYA-Device
[code]define TUYA_SP12 fhempy tuya IGzCi97RpN2Lf9cu 00673231e09806cb13b0 192.168.9.57 b5614e736a41adec 3.3 ea845
attr TUYA_SP12 DbLogExclude .*
attr TUYA_SP12 DbLogInclude energy,cur_power
attr TUYA_SP12 alias SP12 TH Sued1
attr TUYA_SP12 dp_01 switch_1
attr TUYA_SP12 dp_09 countdown_1
attr TUYA_SP12 dp_17 add_ele
attr TUYA_SP12 dp_18 cur_current
attr TUYA_SP12 dp_19 cur_power
attr TUYA_SP12 dp_20 cur_voltage
attr TUYA_SP12 event-min-interval energy:3600,cur_power:600
attr TUYA_SP12 group Schalter (T),Schalter Strang,Schalter Strommessung
attr TUYA_SP12 room - Raum -> Thomas,-TUYA,TUYA Stromverbrauch
attr TUYA_SP12 stateFormat Verbrauch: [$name:energy] kWh, cPower [$name:cur_power] W, cVoltage [$name:cur_voltage] V, Time: [$name:cur_power:t]
attr TUYA_SP12 tuya_spec_functions [{'code': 'switch_1', 'dp_id': 1, 'type': 'Boolean', 'values': {}, 'desc': 'switch 1'}, {'code': 'countdown_1', 'dp_id': 9, 'type': 'Integer', 'values': {'unit': 's', 'min': 0, 'max': 86400, 'scale': 0, 'step': 1}, 'desc': 'countdown 1'}]
attr TUYA_SP12 tuya_spec_status [{'code': 'switch_1', 'dp_id': 1, 'type': 'Boolean', 'values': {}}, {'code': 'countdown_1', 'dp_id': 9, 'type': 'Integer', 'values': {'unit': 's', 'min': 0, 'max': 86400, 'scale': 0, 'step': 1}}, {'code': 'add_ele', 'dp_id': 17, 'type': 'Integer', 'values': {'unit': '', 'min': 0, 'max': 50000, 'scale': 3, 'step': 100}}, {'code': 'cur_current', 'dp_id': 18, 'type': 'Integer', 'values': {'unit': 'mA', 'min': 0, 'max': 30000, 'scale': 0, 'step': 1}}, {'code': 'cur_power', 'dp_id': 19, 'type': 'Integer', 'values': {'unit': 'W', 'min': 0, 'max': 50000, 'scale': 1, 'step': 1}}, {'code': 'cur_voltage', 'dp_id': 20, 'type': 'Integer', 'values': {'unit': 'V', 'min': 0, 'max': 5000, 'scale': 1, 'step': 1}}]
# DEF tuya IGzCi97RpN2Lf9cu 00673231e09806cb13b0 192.168.9.57 b5614e736a41adec 3.3 ea8453wdazquzfl08l0e 8a4b27dd759d4c6a9456aa8155d2a0ea
# DEVICEID 00673231e09806cb13b0
# FHEMPYTYPE tuya
# FUUID 63a35f57-f33f-fd5f-d28c-f30c68bc093a1f03
# IODev local_pybinding
# NAME TUYA_SP12
# NR 1753
# PYTHONTYPE tuya
# STATE Verbrauch: 7.566 kWh, cPower 18.0 W, cVoltage 225.9 V, Time: 2023-03-14 19:50:24
# TYPE fhempy
# eventCount 779
# READINGS:
# 2023-01-30 07:59:14 countdown_1 0.0
# 2023-03-14 19:47:02 cur_current 134.0
# 2023-03-14 19:50:24 cur_power 18.0
# 2023-03-14 19:45:31 cur_voltage 225.9
# 2023-01-30 07:59:14 dp_21 1
# 2023-01-30 07:59:14 dp_22 721
# 2023-01-30 07:59:14 dp_23 30787
# 2023-01-30 07:59:14 dp_24 20947
# 2023-01-30 07:59:14 dp_25 995
# 2023-03-14 19:48:26 energy 7.566
# 2023-02-28 16:26:01 energy2212 0
# 2023-03-14 09:47:18 online 1
# 2023-03-14 19:50:24 statEnergy Hour: 0.014 Day: 0.170 Month: 4.106 Year: 4.120 (since: 2023-02-28 )
# 2023-03-14 18:59:57 statEnergyLast Hour: 0.018 Day: 0.151 Month: 0.014 Year: - (since: 2023-02-28 )
# 2023-02-28 21:18:13 statdayEnergy Hour: 0.005 Day: 0.050 Month: 0.050 Year: 0.050 (since: )
# 2023-02-28 21:00:02 statdayEnergyLast Hour: 0.001 Day: - Month: - Year: -
# 2023-03-14 09:48:25 state on
# 2023-01-30 07:59:14 switch_1 on
# args:
# TUYA_SP12
# fhempy
# tuya
# IGzCi97RpN2Lf9cu
# 00673231e09806cb13b0
# 192.168.9.57
# b5614e736a41adec
# 3.3
# ea8453wdazquzfl08l0e
# 8a4b27dd759d4c6a9456aa8155d2a0ea
# argsh:
# helper:
# _98_statistics statistics_TUYA_SP_all
#
setstate TUYA_SP12 Verbrauch: 7.566 kWh, cPower 18.0 W, cVoltage 225.9 V, Time: 2023-03-14 19:50:24
setstate TUYA_SP12 2023-01-30 07:59:14 countdown_1 0.0
setstate TUYA_SP12 2023-03-14 19:47:02 cur_current 134.0
setstate TUYA_SP12 2023-03-14 19:50:24 cur_power 18.0
setstate TUYA_SP12 2023-03-14 19:45:31 cur_voltage 225.9
setstate TUYA_SP12 2023-01-30 07:59:14 dp_21 1
setstate TUYA_SP12 2023-01-30 07:59:14 dp_22 721
setstate TUYA_SP12 2023-01-30 07:59:14 dp_23 30787
setstate TUYA_SP12 2023-01-30 07:59:14 dp_24 20947
setstate TUYA_SP12 2023-01-30 07:59:14 dp_25 995
setstate TUYA_SP12 2023-03-14 19:48:26 energy 7.566
setstate TUYA_SP12 2023-02-28 16:26:01 energy2212 0
setstate TUYA_SP12 2023-03-14 09:47:18 online 1
setstate TUYA_SP12 2023-03-14 19:50:24 statEnergy Hour: 0.014 Day: 0.170 Month: 4.106 Year: 4.120 (since: 2023-02-28 )
setstate TUYA_SP12 2023-03-14 18:59:57 statEnergyLast Hour: 0.018 Day: 0.151 Month: 0.014 Year: - (since: 2023-02-28 )
setstate TUYA_SP12 2023-02-28 21:18:13 statdayEnergy Hour: 0.005 Day: 0.050 Month: 0.050 Year: 0.050 (since: )
setstate TUYA_SP12 2023-02-28 21:00:02 statdayEnergyLast Hour: 0.001 Day: - Month: - Year: -
setstate TUYA_SP12 2023-03-14 09:48:25 state on
setstate TUYA_SP12 2023-01-30 07:59:14 switch_1 on
[/code]
nicht dazu, cur_power Events zu erzeugen. Mit energy gehts über addlog.
Woran kann es liegen ?
Beste Grüße
Thomas