3M CT50 Radio Thermostat HTTPMOD

Begonnen von mgmino, 21 Mai 2020, 03:08:01

Vorheriges Thema - Nächstes Thema

mgmino

The CT50 thermostat is accessible with a simple REST interface. I can enter a command from the address line of a browser (Chrome) like http://192.168.1.117/tstat and get the following response

{"temp":73.50,"tmode":1,"fmode":0,"override":1,"hold":1,"t_heat":73.00,"tstate":0,"fstate":0,"time":{"day":2,"hour":21,"minute":0},"t_type_post":0}

This same request from HTTPMOD is

HTTP/1.1 505 HTTP Version Not Supported
Server: Marvell 8688WM
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain

A guess is that HTTPMOD is sending a header the server doesn't like?

StefanStrobel

Probably :-)
If you set the attribute verbose of your HTTPMOD-device to 5 then you will see all the details of the communication as well as a lot of debug messages in the fhem logfile.
This helps to fix problems.

HTTPMOD uses HTTP version 1.0 by default. If you want to change this then you can set the attribute httpVersion to 1.1
maybe this helps.

regards,
    Stefan

mgmino

Thank you, The version change fixed the problem. I will submit a 3M CT50 implementation after I have it all worked out.

herrmannj

If the payload is pure JSON, JsonMod may be worth a try

Br, joerg

Beta-User

Zitat von: mgmino am 21 Mai 2020, 21:50:20
Thank you, The version change fixed the problem. I will submit a 3M CT50 implementation after I have it all worked out.

If you like, we could try to provide that as a attrTemplate to other users?
As this seems to be a heating type thing, I suggest using "well-known" setters if possible? E.g. with "desired-temp" would allow flawless integration to things like WeekdayTimer/weekprofile...

[OT @herrmannj: are there still plans to enable the attrTemplate feature to jsonMod as well?]
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

yersinia

Zitat von: herrmannj am 21 Mai 2020, 23:28:30If the payload is pure JSON, JsonMod may be worth a try
One advantage of HTTMOD is automatically and dynamically generation of readings based on JSON properties (attr [device] extractAllJSON 1) - whereas JsonMod (current version) requires the user to define the to be extracted properties manually explicitly.
JsonMod is great for processing Json[P] sources and has a lot potential (I love the cron like interval definition!).
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

mgmino

I found the extractAllJSON works great. Since I have two CT50 thermostats on the same network, is there a way to append a prefix on extractAllJSON names to make them unique?

MadMax-FHEM

Don't you have two instances of HTTPMOD!?

So one for each Device!?

So they should be/are unique!?

Every Reading is the same (maybe) on each HTTPMOD but they could be easily differentiated by the NAME of the HTTPMOD.

Like everything in fhem...

So all my Homematic Thermostats (and other devices from the same type) look exactly the same (regarding names of Readings but of course not the values ;)  ).

But I access them using the NAME...

Or maybe I did misunderstand the "problem"...

Regards, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

mgmino

I am attempting to understand the basics of FHEM. I will write an English explanation when I learn this.

How do I access the readings that result from extractAllJSON (temp, fmode, t_cool, etc)?

2020-05-30 11:12:37 HTTPMOD CT50 fstate: 1
2020-05-30 11:12:37 HTTPMOD CT50 fmode: 0
2020-05-30 11:12:37 HTTPMOD CT50 t_cool: 75
2020-05-30 11:12:37 HTTPMOD CT50 time_minute: 10
2020-05-30 11:12:37 HTTPMOD CT50 time_day: 5
2020-05-30 11:12:37 HTTPMOD CT50 override: 1
2020-05-30 11:12:37 HTTPMOD CT50 temp: 75.5
2020-05-30 11:12:37 HTTPMOD CT50 tstate: 2
2020-05-30 11:12:37 HTTPMOD CT50 hold: 1
2020-05-30 11:12:37 HTTPMOD CT50 t_type_post: 0
2020-05-30 11:12:37 HTTPMOD CT50 time_hour: 11
2020-05-30 11:12:37 HTTPMOD CT50 tmode: 2

They do not appear with the list command. Does each one need to be defined in the HTTPMOD attr?

MadMax-FHEM

#9
You can access them either using the Event "thrown" when a Reading is updated:

notify/DOIF/...

then notify/DOIF/... react on that "trigger" and in $EVENT ($EVTPART0 $EVTPART1 ...) you get the "content" of the Event ;)

based on that you can do some "automation"...

easiest way to "get" a notify/DOIF is to open Eventmonitor (set a filter) and wait for the Event of interest, mark that Event and then click "create/modify" and then a DOIF/notify could be created...

https://fhem.de/commandref.html#inotify

https://fhem.de/commandref.html#DOIF

EDIT: there are many more helpful links (Wiki) etc. but they are all in German...


if you "just" want to read out the value when in programming in Perl:

ReadingsVal("DeviceName","ReadingName","DefaultValueIfReadingDoesNotExist")

or if you just want the "numeric part":

ReadingsNum("DeviceName","ReadingName",DefaultValueIfReadingDoesNotExist)

in your case (example):

ReadingsNum("CT50","t_cool",0)

EDIT: and here you go (getting back to your last question) the next Device will be also a HTTPMOD but named e.g. CT51 with the same Readings (if it is the exact same type "sending" the exact same data). And: naming is essential for further automation things! So e.g to be able to use DevSpec (a way to "get" certain devices with "common settings" like same Type or following a naming convention. E.g. set CT5.* on will set all devices named "something" with CT5 to state on [of course teh device has to "know" that command ;)  ]. So it will set CT50 and CT51 and so forth to "on"... And as fhem/Perl and DevSpec has a lot to do with RegEx to have "Points" in names is not the best idea ;) So something like CT50.SubSomething.AnotherThing Better maybe underscore CT50_SubSomething_AnotherThing (if you want to "categorize" things/devices by names)...

https://fhem.de/commandref.html#devspec

EDIT: in order to "get to Perl" in fhem you just use brakets { "Perl inside" } when in a notify, e.g.: define nExample notify Trigger-RegEx {HereYouCanGoWithPerl}
If you then need fhem "functionality" inside Perl you can get "back" to fhem using the fhem-command: {HereYouAreInPerl; fhem("now you can do fhem commands here"); }  ;)

Regards, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

mgmino

Thank you for your detailed response. I have a lot to learn about FHEM but the journey is exciting.

I also appreciate the intelligence and vibrancy of the community. I hope I can give back.

MadMax-FHEM

You're very welcome!

Jep lot to learn but lot exciting things to do :)

"Bad" for you that mostly the things/examples etc. are in German...

So hang on and when ever you need to know something: come back here ;)

The same if you have "implemented" interestings things...
...just post them :)

Have fun, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)