#gelöst#HTTPMOD set Befehl funktioniert nicht mehr Bitte Hilfe von HTTPMOD

Begonnen von Helmi55, 06 April 2022, 10:09:55

Vorheriges Thema - Nächstes Thema

frank

im log stand der fehler übrigens auch ziehmlich deutlich:
2022.04.09 16:50:21 5: Ofen: ExtractReading for context reading, num 99 - no individual parse definition
2022.04.09 16:50:21 4: Ofen: Read response matched 158, unmatch 1 Reading(s)
2022.04.09 16:50:21 5: Ofen: Read response to get09 matched controls_heatingTimeFri2 controls_convectionFan2Level sensors_parameterDebug4 stoveFeatures_insertionMotor controls_debug3 controls_convectionFan1Level sensors_parameterErrorCount15 sensors_statusSubState controls_heatingTimeMon2 sensors_statusWifiStrength sensors_statusError sensors_parameterFeedRateService sensors_parameterErrorCount18 sensors_parameterErrorCount16 controls_convectionFan2Active sensors_parameterErrorCount5 sensors_parameterOnOffCycleCount sensors_inputGridContact controls_heatingTimeTue1 controls_heatingTimeSat2 stoveFeatures_logRuntime sensors_parameterErrorCount1 sensors_parameterVersionMainBoardBootLoader sensors_parameterStoveTypeNumber sensors_parameterRuntimePellets controls_RoomPowerRequest sensors_inputBurnBackFlapSwitch sensors_parameterErrorCount9 sensors_parameterErrorCount7 controls_ecoMode sensors_inputTargetStagePID sensors_inputFlameTemperature sensors_parameterVersionMainBoardSub sensors_outputBurnBackFlapMagnet sensors_inputCurrentStage controls_debug1 controls_heatingTimeWed1 sensors_parameterErrorCount4 sensors_parameterFeedRateTotal controls_heatingTimeThu1 sensors_parameterErrorCount13 sensors_parameterErrorCount0 sensors_outputAirFlapsTargetPosition controls_heatingTimeSun2 sensors_parameterErrorCount11 sensors_parameterKgTillCleaning sensors_parameterErrorCount10 sensors_outputGridMotor sensors_inputPressureSwitch sensors_parameterErrorCount17 sensors_parameterVersionWiFi sensors_statusHeatingTimesNotProgrammed stoveFeatures_bakeMode name sensors_outputDischargeCurrent sensors_parameterServiceCountdownKg controls_setBackTemperature sensors_outputDischargeMotor sensors_inputDoor sensors_parameterIDFanTuning sensors_parameterLanguageNumber sensors_parameterCleanIntervalBig sensors_statusSubError controls_debug2 sensors_parameterDebug2 sensors_inputUpperTemperatureLimiter controls_operatingMode sensors_parameterVersionTFTSub controls_heatingTimeSat1 sensors_inputFlueGasFlapSwitch sensors_inputBoardTemperature controls_heatingTimeTue2 controls_convectionFan1Active controls_bakeTemperature sensors_parameterEcoModePossible controls_convectionFan1Area sensors_statusWarning sensors_parameterServiceCountdownTime controls_convectionFan2Area sensors_inputCover controls_heatingPower sensors_parameterSpiralMotorsTuning sensors_parameterDebug0 controls_heatingTimeFri1 sensors_parameterErrorCount14 controls_debug0 sensors_parameterDebug3 sensors_parameterErrorCount6 sensors_parameterDebug1 sensors_inputPressureSensor sensors_outputInsertionCurrent sensors_parameterErrorCount12 stoveFeatures_airFlaps controls_onOff sensors_outputIgnition controls_temperatureOffset sensors_parameterErrorCount8 controls_heatingTimeMon1 sensors_parameterVersionMainBoard sensors_outputInsertionMotor lastConfirmedRevision stoveID sensors_outputAirFlaps controls_frostProtectionActive sensors_outputIDFan sensors_inputCurrentStagePID lastSeenMinutes sensors_parameterVersionWiFiSub sensors_parameterPressureSensorOffset controls_frostProtectionTemperature sensors_statusFrostStarted stoveFeatures_multiAir1 sensors_inputExternalRequest sensors_parameterRuntimeLogs sensors_parameterFabricationNumber controls_heatingTimesActiveForComfort sensors_parameterIgnitionCount controls_revision stoveType sensors_outputIDFanTarget sensors_statusMainState oem sensors_parameterFlameSensorOffset stoveFeatures_multiAir2 controls_targetTemperature sensors_parameterVersionWiFiBootLoader controls_heatingTimeWed2 controls_heatingTimeSun1 sensors_parameterErrorCount2 controls_heatingTimeThu2 controls_debug4 sensors_parameterErrorCount19 sensors_inputRoomTemperature sensors_inputBakeTemperature sensors_parameterVersionTFT sensors_parameterVersionTFTBootLoader sensors_statusService sensors_parameterErrorCount3 RaumTemp SollTemp Betriebsart BrennTemp Pellets Zustand HZ Mo 1 HZ Mo 2 HZ Di 1 HZ Di 2 HZ Mi 1 HZ Mi 2 HZ Do1 HZ Do2 HZ Fr1 HZ Fr2 HZ Sa1 HZ Sa2 HZ So1 HZ So2
2022.04.09 16:50:21 5: Ofen: Read response to get09 did not match controlsJSON


httpmod bietet auch spezielle readings zur kontrolle an, die über die attribute showError und showMatched aktiviert werden.
UNMATCHED_READINGS mit event-on-update hätte hier zb immer ein event geworfen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Helmi55

Hallo frank

Danke für den Hinweis. Werde ich mir ansehen um etwas in Zukunft zu vermeiden
Aber wie gesagt HTTPMOD und ich sind keine Freunde  ;D
Da wurde mir bei dem Ofen sehr stark vom Forum unter die Arme gegriffen!!!

Gruß
Helmut
System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

Vize

Zitat von: Beta-User am 12 April 2022, 14:13:25
und mit 5.32 (bullseye, 2021) ist dann eben FHEM proaktiv eingesprungen...

Ahoi,

hmmmm
perl --version

This is perl 5, version 32, subversion 1 (v5.32.1) built for arm-linux-gnueabihf-thread-multi-64int
(with 47 registered patches, see perl -V for more detail)


cat /etc/debian_version
11.2


Ich habe vor kurzem mein FHEM von einem RasPi 2 mit Debian stretch auf einen RasPi 3 B+ mit frischem Raspberry OS (bullseye) "umgezogen".
Dabei habe ich viel aus der alten Config einfach "rüberkopiert". Dabei gab's in diesem Zusammenhang nur den Hinweis im Log mit den unescaped braces.
Die Attribute sind - wie gesagt - alle da und es funktioniert. Werd's aber mal nach Beta-Users Hinweis anpassen.

Bezüglich attrTemplate für den RIKA Ofen muss ich mal schauen, ob und wann ich Zeit dafür finde.
Für das Device muss ja auch eine Funktion aus der 99_myUtils aufgerufen werden, aber da hat Beta-User mich auch schon auf den passenden Weg geführt...  ;)

In meinem Ofen-Device nutze ich außerdem
set storeKeyValue
mit
replacement02Mode key
replacement02Regex %%password%%
replacement02Value password

damit das Passwort nicht im Klartext im Device steht.
Gibt es dazu noch etwas zu beachten für das Anfertigen des attrTemplates?

Außerdem nutze ich aus der JSON-Antwort der Webseite nur einen sehr geringen Teil.
Was ein extractAllJSON auswirft, sieht man ja sehr schön im list von Helmut.  ;)
Richtigerweise müsste das ja alles in das attrTemplate gepackt werden...

Schaun mer mal...

VG
Andreas



Beta-User

Zitat von: Vize am 13 April 2022, 18:33:12
perl --version

This is perl 5, version 32, subversion 1 (v5.32.1) built for arm-linux-gnueabihf-thread-multi-64int
(with 47 registered patches, see perl -V for more detail)

Hmm, "angekündigt" war mal gewesen, dass 5.32 "unsecaped braces" nicht mehr goutiert - ich hab's sowohl modulseitig wie in der Installation versucht proaktiv rauszunehmen, von daher weiß ich auch nicht, ob/was ggf. Perl selbst und/oder Debian bzw. Pi-OS an der Stelle ggf. abweichend zur Ankündigung umgesetzt haben. Ist jedenfalls definitiv kein Fehler, das zukunftssicher zu notieren...

FHEM (bzw. das Modul?) beitet jedenfalls Möglichkeiten, sowas ("kaputtes attr") aus der cfg heraus zu akzeptieren, aber nicht per FHEMWEB-Eingabe ;) .

Zitat
set storeKeyValue
mit
replacement02Mode key
replacement02Regex %%password%%
replacement02Value password

damit das Passwort nicht im Klartext im Device steht.
Gibt es dazu noch etwas zu beachten für das Anfertigen des attrTemplates?
Nicht wirklich. Das Passwort kann per "par:"-Anweisung (z.B. als "PASSWD") abgefragt werden und dann per "set DEVICE storeKeyValue PASSWD"-Zeile im attrTemplate an die richtige Stelle in FHEM verfrachtet werden. Dann sollte das ohne weiteres passen :) .

Zitat
Außerdem nutze ich aus der JSON-Antwort der Webseite nur einen sehr geringen Teil.
Prinzipiell finde ich - ganz allgemein gesprochen - "datensparende" Varianten als Vorschlag immer auch gut (immer vorausgesetzt, das Device läßt sich dann sinnvoll bedienen).

ZitatWas ein extractAllJSON auswirft, sieht man ja sehr schön im list von Helmut.  ;)
Ich habe mich mit funktionalen Fragen nicht beschäftigt, fand die liste aber auch "beeindruckend"...

Zitat
Richtigerweise müsste das ja alles in das attrTemplate gepackt werden...
Ja, vielleicht, nein, ...

Das "eigentliche Problem" ist meistens, irgendwie einen "guten" Standard zu finden, mit dem "Otto Normaluser" "gut bedient" ist. Von daher würde ich erst mal die "eingeschränkte" hier zur Diskussion stellen, dann sieht man, ob das ggf. schon den Bedarf deckt oder eben für verschiedene Modelle irgendwie abgewandelt werden muss/kann.
Was auch geht, wäre z.B. eine "radio"-Option reinzubasteln, mit der der User entscheiden kann, ob er die "kleine" oder die "extract all"-Variante haben will...
Dto. für "mache ohne Passwort weiter". Ein Beispiel dazu ist in tasmota_NSPanel_split (mqtt2) zu finden. Das ist aber eigentlich ein Thema für "Fortgeschrittene" ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Vielleicht noch wegen https://forum.fhem.de/index.php/topic,127126.0.html:

Wenn ich die verstreuten Infos richtig zusammenpuzzle, steht lt.https://forum.fhem.de/index.php/topic,76220.msg700295.html#msg700295 aktuell noch in den Einstellungen folgendes drin:
reading04Name SollTemp
set12Name  targetTemperature

Beides bezieht sich aber nach meinem Verständnis auf denselben "Datenpunkt" auf dem Ofen, nämlich dem, was ich als "desired-temp" bezeichen würde.
Falls das zutreffend ist, würde ich dringlich anraten, diesen Infokreis auch "irgendwie" zu schließen, optimalerweise unter einer internationalisierten Bezeichnung (siehe dazu auch https://forum.fhem.de/index.php/topic,117933.0.html). Ist das halbwegs in sich konsistent, sollte auch das Steuern (von wo aus auch immer) einfacher werden...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Helmi55

Hallo Beta-User,

Ui da habe ich eine Lawine losgetreten......
Mit dem Soll Temp und targetTemperature hast du vollkommen recht.

Mir wurde damals im Forum geholfen, da ich damals und auch heute keine Ahnung von HTTPMOD hatte/habe.
Ich wollte schon einiges umsetzen aber keine Chance - aber alles muß man nicht können - oder?

Soll ich den Thread wieder öffnen? Oder vielleicht auch umbenennen
ich werde auf jedenfall, sofern ich die Berechtigung habe, im Wiki die Änderung eintragen

Frohe Ostern
Helmut
System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

Beta-User

"Lawine" finde ich etwas übertrieben, hier aber nochmal im "Klartext", was _vermutlich_ funktionieren würde (genericDeviceType allerdings nur dann, wenn du eine Sprachsteuerung im Einsatz hast), vorausgesetzt, das, was bisher "targetTemperature" genannt wurde ist sowas wie die "Soll-Raumtemperatur":
attr Ofen reading04Name desired-temp
attr Ofen set12Name  desired-temp
attr Ofen genericDeviceType thermostat
attr Ofen appOptions { "template": "thermostat" }


Und die "gemessene (Raum-) Temperatur" sollte auch einen "guten Namen" bekommen (z.B.: "measured-temp")...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Helmi55

Servus
das reading04Name kommt vom reading04JSON = Sensors_inputFlameTemperature.
Das ist die Temperatur im Brennraum. Die darf ich nicht auf desired-temp ändern
Das sollte die "02" sein statt der SollTemp? Oder verstehe ich was falsch?

Warum brauche ich dann noch set12Name?
set10Name ist in meinem Fall die targetTemperature - oder erfolgt damit auch eine Umbenennung

Danke für deine Mühe
und ein frohes Osterfest, gesund bleiben

Gruß
Helmut
System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

Beta-User

Na ja, war ein (offenbar unpassender) Versuch...

Hatte halt irgendwo die "22" (Grad) als zu setzende Temp gesehen und mir da offenbar was falsch zusammengereimt. Na ja, da das anscheinend jetzt mehr oder weniger so geht, wie du dir das vorstellst, ist da ja im Moment kein dringlicher Handlungsbedarf gegeben.

Jedenfalls auch allen ein schönes Osterfest!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files