How about reading actual temperature values at the rooms!?

[Hobbyists]

Hi there,

Thanks a lot that hard work here, impressive reverse engineering. I was wondering if there is a way to capture actual temperature readings from one of the devices (Room therm. or Wall therm.)? That can be great input for our own systems/projects. And then we can be sure that the temp value is reached to the expected degree at a room.

Thank you very much for any possible feedback in advance.

Hobbyist

[Bouni]

Hi,

as far as i know/read on the other attempts to reverse engineer this protocol, it is not possible to get the temperature from the heater thermostats (i don't know how the situation is for the wall mount thermostat). I have thought about why they don't provide this and ended up with the assumption that they measure a much to high value because the sensor sits next to the heater and use some kind of algorithm/offset to regulate the temperature to a value that fits the specified room temperature.

But at the moment I've only reversed/documented the tip of the iceberg. Lets see what comes out if i got time to reverse more. (At the moment i have to less free time to continue this project, but that does not mean that it's dead :-) )

[Hobbyists]

Hi Bouni,

Thanks a lot for the prompt reaction on my question.

Right after asked you I came across with a link (http://www.domoticaforum.eu/viewtopic.php?f=66&t=6654&sid=8c43bf4a44e2f73a25a6745647f9f4d6&start=75). According to matthijskooijman, L-Response contains actual temp. value from Wall mount thermostat. I have ordered some RFM12B 868Mhz modules from JeeLabs. I want to see it with my eyes directly instead of max cube. If it is a success at the end, I can even think about switching to my own cube version. If I find some more time and have good luck, I will return back here and contribute.

[Bouni]

I can not tell you much about wallmount thermostats because i don't use one :) If you get your own RFM12 up and running it would be nice if you could create a documentation about the radio protocol. I'm not sure if there is something like that already available.

[marcelrv]

@Hobbyists Actual temperature can be read from the L message. There is one big caveat. To read the actuals from the heathing thermostat the valve must have moved. Only then the data is available. Until that time is shows 0 Wall thermostat provides the actual

[Hobbyists]

@marcelrv I am thinking of a work around. Once I find a solid base to communicate with all the MAX devices with my own transmitter/receiver, I can do something about it. For example, a set point change request (dummy request) can be sent to the rooms individually and then be rolled back for the sake of starting a talk. Room#1, actual 20.5, change request 21.0 and then roll back to 20.5 again. Room#2, actual 22.0, change request 22.5 and then roll back to 22.0 again. and so on.... This might give recent/actual readings I believe.

[marcelrv]

Yes, similar approach is used before. Note that you probably can save battery and noise by just changing the thermostat mode.

For an example check e.g. http://www.fhemwiki.de/wiki/MAX!_Temperatur-Scanner Likewise same approach is also planned for the MAX! binding in Openhab. https://github.com/marcelrv/openhab2/tree/master/addons/binding/org.openhab.binding.max/src/main/java/org/openhab/binding/max Note. if you are looking for a pretty ready to go solution for the MAX! you may want to look @ Openhab

[Hobbyists]

@marcelrv I appreciate your reaction on that, thank you. I will keep in my mind the idea "changing thermostat mode". I have several times come across with Fhem thing. I am sure that there are some valuable information in there. I couldn't really go into it that deep due to language barrier (although google translate helps). Besides this, for now, I like to use my own transceivers and arduino base instead of diving into a place uncharted (perl server, FHZ1300, etc...) for me. But, I will definitely try to get some knowledge about how things handled with your solution at Openhab.

Since I can't have a flawless data using FSK modulation, I doubt that if eQ3 actuators, thermostats using something else! Question: Do you exactly know the type of modulation with Max! besides the frequency 868.3 MHz? (FSK, OOK, etc...)

[marcelrv]

here you have a pointer for it. https://github.com/matthijskooijman/arduino-max

or you can go through the sources of FHEM 's radio module (CUL devices). I have not tried decoding them yet. It is still on my wishlist to connect a CC1100 module to my PI and try to decode the signal avoiding the max cube

[Hobbyists]

@marcelrv Yeah, I know that guy's work (Matthijs), it is pretty cool so to say, but I didn't check it lately. Since then, apparently he made some progress. Thanks for bringing this to my attention. So, all I need now is having some spare time:)

[AndyP2]

actual temperature from a room thermostat is available (in degrees C * 10) as the 12th byte of its L message. I'll update the document in a bit.

[Hobbyists]

Thank you for the update. Sent using CloudMagicOn Sun, Mar 1, 2015 at 2:24 pm, Bouni/max-cube-protocol reply@reply.github.com wrote: actual temperature from a room thermostat is available (in degrees C * 10) as the 12th byte of its L message. I'll update the document in a bit.

—Reply to this email directly or view it on GitHub.