If you have a Alpha Innotec heatpump, the update files are here:
http://www.heatpump24.de/kontoeinst_104.php?layout=1
For Novelan pups here:
http://www.heatpump24.de/kontoeinst_104.php?layout=2
There must be a third manufacturer that uses the Alpha Innotec firmware, if the layout is increased to 3, another color scheme is used:
http://www.heatpump24.de/kontoeinst_104.php?layout=3
@Bouni:
My concern with the Websocket interface is that it seems to allow only very few write operations and the binary one seems to allow more (maybe you know that better?).
The suggestion for the chat was that there might be some technical discussions which might be irrelevant for HASS users on this forum. Like when we try to figure out how to get a sensor with multiple values or by searching for such patterns in similar addons. Just my opinion, but I’m also fine staying here.
I think as we’re dicussing in a develpment branch of this forum, its exactly what its meant for, so I would vote for staying here for any future discussion / development.
Anyway, here is a dump of what I get from the websocket interface:
https://pastebin.com/Mud9W2XB
It has all write options that are available through the webinterface. Do you need any other write options?
There are only a few write options I need 
I just don’t want that we miss possibilities by just supporting the websocket interface. But in anyway, If absolutely needed we might be able to switch to the binary interface without too much of a hassle. The only quesion is if we will ignore those that do not have the websocket interface or if we still want to stay with the websocket? The current known ratio is that 33% would not be able to use the component 
Regarding the sensor: I think a sensor can only have one value but multiple attributes. So either we create sensors for each value we want to expose or one/a few sensors with multiple attributes. Maybe we should first create a list of values we want to show and/or edit? What do you think? I am thinking about a google doc here to collect that information so we can collaborate easier.
Another question: Do you know about internationality? In the xml we have usually an id, a name and a value. The id is dynamic as far as I know and not always the same for the same element. So we would need to go for the name. Is the name always in German or is it English if you have setup your heatpump/Luxtronik to English?
Edit: If we would need to support multilanguage, the binary interface suddenly gets more appealing as there we only have numbers.
I think you’re right, maybe we should go for the binary protocol as we could support all users and we’re not dependent on the language!
I’ll collect samples of the binary protocol and post 'em in a minute.
Here we go:
3004.xml (2.2 KB)
3003.xml (9.0 KB)
If I understand it correct, the 3004 values are calculations, read only values.
The 3003 values are parameters, read and write parameters, right?
The command 3002 is then used to write those parameters.
What do you think, should we kind of restrict the writable values to those we know for sure!?
Just to beware users of accidentally change values that normally are not changeable through the webinterface.
That’s how I understood it as well. Yes I think we should only expose those that we for sure know what they are. There are plenty of projects which could maybe help like:
and maybe others.
How about creating a list/mapping in google sheets to collect all information about what value means what and which can be settable/readable?
OK, sounds good!
I would suggest that we create a Github project and do the documentation in a Markdown file. That way we can later work on the component itself in the same project and can easily collaborate.
If you agree, I’ll set up the project and grant you access to it!
Here is the repo: https://github.com/Bouni/Home-Assistant-Luxtronik
I’ve created 4 Markdown files, so we can write detailed descriptions for each of the 4 commands.
After looking into other components I would suggest to go for a approch like the apcupsd component.
A central component that fetches the data from the Luxtronik:
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/apcupsd.py
Binary_sensors and Sensors for the attributes:
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/sensor/apcupsd.py
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/binary_sensor/apcupsd.py
Is anyone of you aware of a component that can set different values like heating, cooling, off?
Or how to implement such a component, maybe an example!?
My component as mentioned above has multiple different values for a single component. I haven’t looked into apcupsd but seems like a nice solution.
In my opinion its way cleaner to have multiple sensors then having one component with several attributes.
I think I’ll go for this approach. It will take me some time but I’m not in a hurry
I’m going to write a Luxtronik lib that then can be imported into the HA Component as suggested in the dev docs:
In that lib I plan to integrate a parser that processes the raw data into a dict (actually a dict of 3 dicts which represent parameters, calculations, visibilities)
How does that sound to you guys?
Edit:
How should we label the data? The labels out of the Java source is a mixture of German and English and sometimes weird abbreviations 
That makes sense. Wanted to mention that as well.
I think we should try to name everything in English. I’m kind of busy this month but would be able to help starting from next month.
Hi,
I started to write the mentioned module, so far I’ve created a part that gets the data from the Luxtronik and a parser + lookup table for converting the data.
This is the dict that is the result of the parser. I plan to use that dict of all parameters, calculations and visibilitys in the HA component then.
At the moment I use the ID i got from the java source but its no problem to extend the lookup table at a later point with logical english names.
Let me know if you’ve better ideas or suggestions!
calculations.xml (18.8 KB)
Finished the basic work for 3003, 3004 and 3005 commands.
At the Moment there are no conversions available for 3003 and 3005, but maybe I can get them out of the source as well.
Here’s what I get when I run the parser against my heatpump:
data.xml (257.3 KB)
Edit: sorry for using the xml ending on the files but neither json nor txt are allowed for upload 
I’ve created a pypi installable package for getting data from the Luxtronik and parsing it into a huge dict.
Writing is parameters is further back on my list, I’ve decided to get the sensor/binary_sensor parts up and running first.
Initial work is done, the component works, a sensor platform that can be set up by configuring the ID’s from the JAVA webinterface works also, but needs still a lot of polishing!
strong text
luxtronik:
host: "192.168.1.10"
port: 8889
sensors.yaml
- platform: luxtronik
sensors:
- 'ID_WEB_Temperatur_TRL'
- 'ID_WEB_Temperatur_TVL'
I still look for a nicer way to configure the sensors than the ID, its not very nice in my opinion because a lot of the a weird german/englisch abbreviations…
Ideas are welcome!
