Mein Sensor gibt folgenden Wert heraus:
temp=74.0'C
Mittels regex101.com habe ich folgende regex gefunden die mir den Zahlenwert gibt:
temp=([0-9\.]+)
Im FHEM habe ich folgendes UserReadings definiert:
temp { ReadingsVal("Sarastro_RPI_cam1","RPI_Cam1_temp",0) =~ m/ temp=([0-9\.]+) /; $1}
Leider gibt mir nun FHEM als Reading für temp den Wert 4 anstatt 74.0
Was habe ich da wohl falsch gemacht?
Wie wäre es hiermit
temp=(-?[\d\.]+)
Wenn du im userReadings-Eintrag dann ein Leerzeichen reinmachst, ist das "komisch".
Bei mir klappt jedenfalls anscheinend das hier:
attr dmTst2 userReadings temp:RPI_Cam1_temp.* { ReadingsVal($name,'RPI_Cam1_temp',0) =~ m{temp=([0-9.]+)}x;; $1}
Partly OT: Wieso es immer noch Leute gibt, die nicht mitbekommen haben, dass ein userReadings-Eintrag sauber getriggert werden sollte ist mir unbegreiflich...
Ich habe jetzt:
temp { ReadingsVal("Sarastro_RPI_cam1","RPI_Cam1_temp",0) =~ m/ temp=(-?[\d\.]+)/; $1}
Was seltsam ist dass das Reading immer noch "temp" heisst anstelle von "RPI_Cam1_temp".
Ausserdem ist der Wert jetzt temp=75.0'C aber ausgegeben wird immer noch 4!
Internals:
BUSY 0
CFGFN
DEF http://127.0.0.1/html/getState_RPI_cam1.json 600
FUUID 62bab1f7-f33f-521d-c140-913019bd224ad6eb
Interval 600
MainURL http://127.0.0.1/html/getState_RPI_cam1.json
ModuleVersion 4.1.12 - 19.4.2022
NAME Sarastro_RPI_cam1
NOTIFYDEV global
NR 38590
NTFY_ORDER 50-Sarastro_RPI_cam1
STATE ???
TYPE HTTPMOD
eventCount 114
value
HttpUtils:
NAME
addr http://127.0.0.1:80
auth 0
buf
code 200
compress 1
conn
data
displayurl http://127.0.0.1/html/getState_RPI_cam1.json
header
host 127.0.0.1
httpheader HTTP/1.1 200 OK
Date: Tue, 28 Jun 2022 13:05:06 GMT
Server: Apache
Last-Modified: Tue, 28 Jun 2022 13:04:02 GMT
ETag: "105-5e281ababd0b6"
Accept-Ranges: bytes
Content-Length: 261
Connection: close
Content-Type: application/json
httpversion 1.0
hu_blocking 0
hu_filecount 1
hu_port 80
hu_portSfx
ignoreredirects 1
loglevel 4
path /html/getState_RPI_cam1.json
protocol http
redirects 0
timeout 2
url http://127.0.0.1/html/getState_RPI_cam1.json
sslargs:
OLDREADINGS:
QUEUE:
READINGS:
2022-06-28 15:05:06 boot 2022-06-28 12:48:47
2022-06-28 15:05:06 date 2022-06-28T13:00:01+00:00
2022-06-28 15:05:06 freq frequency(48)=1500398464
2022-06-28 15:05:06 load 15:00:01 up 2:11, 0 users, load average: 0.41, 0.51, 0.53
2022-06-28 15:05:06 powerLed 255
2022-06-28 15:05:06 temp temp=75.0'C
2022-06-28 15:05:06 throttled throttled=0x0
2022-06-28 15:05:06 volt volt=0.8438V
REQUEST:
context reading
data
header
ignoreredirects 0
num unknown
retryCount 0
type update
url http://127.0.0.1/html/getState_RPI_cam1.json
defptr:
readingBase:
boot reading
date reading
freq reading
load reading
powerLed reading
temp reading
throttled reading
volt reading
readingNum:
boot unknown
date unknown
freq unknown
load unknown
powerLed unknown
temp unknown
throttled unknown
volt unknown
readingOutdated:
requestReadings:
update:
boot reading unknown
date reading unknown
freq reading unknown
load reading unknown
powerLed reading unknown
temp reading unknown
throttled reading unknown
volt reading unknown
hmccu:
Attributes:
devStateStyle style="text-align:right"
enableCookies 1
extractAllJSON 1
room RPI
userReadings temp { ReadingsVal("Sarastro_RPI_cam1","RPI_Cam1_temp",0) =~ m/ temp=(-?[\d\.]+)/; $1}
userattr
verbose 5
Das ist nicht seltsam - es gibt ja auch kein Ausgangsreading mit dem Namen "RPI_Cam1_temp", oder?
Das heißt "temp", also darf das userReadings nicht so heißen (dafür gabe es readingsChange, was man aber bei HTTPMOD vermutlich nicht braucht, wenn man den Wert mit Bordmitteln nachbearbeitet...!?!).
Bitte mit den Grundlagen beschäftigen, so macht das keinen Spaß!
Ok - das mit der anderen Bezeichung für "temp" kann ich tatsächlich beim Speichern der JSON-Dateien steuern.
attr Sarastro_RPI_cam1 userReadings temp:RPI_Cam1_temp.* { ReadingsVal($name,'RPI_Cam1_temp',0) =~ m{temp=([0-9.]+)}x;; $1}
gibt mir allerdings immer noch Wert temp=73.5'C anstelle von 73.5
Zitat von: Beta-User am 28 Juni 2022, 15:14:12
es gibt ja auch kein Ausgangsreading mit dem Namen "RPI_Cam1_temp", oder?
Gibt es das denn jetzt?!?
Wenn nein, wird nicht getriggert und es die ReadingsVal-Abfrage liefe auch ins Leere... Wenn du das Ausgangsreading jetzt z.B. in "temp_raw" umbenannt hast, mußt du das entsprechend ändern... Ansonsten ist das immer noch ein dusseliges Rumgerate.
Nach dem Umbenennen des Readings in der JSON-Datei hat es funktioniert.
Besten Dank für die Unterstützung und die Geduld!