Thanks for this thread! I own a LWZ 404 SOL and I’m desperate to integrate it into my HA for visualizing status informations, logging data over time and maybe start to control basic things like switching between automatic mode and “Bereitschaft” (standby?) to define slots when heating is more appropriate or not.
I’ve read about the ISG Web option (approx. 400€ AFAIR) which offers a gateway from the LWZ to LAN (RJ45) when I understood it correctly. It has much more functionality but I would not use it for that. I would use it as an interface to get data from/to HA.
Then there is the DIY variant (ESP-Home and an MCP 2515 CAN-Bus device; https://juerg5524.ch/list_data.php ) where I have to get some parts, solder them together and build something that gets connected to a RPi which is able to talk to HA.
So here’s my question to you: Did I understand it correctly that those two hardware options are more or less offering the same level of HA integration (number of values to read out; options to control basic things)?
If so, I probably will prefer bying the expensive ISG Web (although it’s hurting my geeky heart) because I’m able to solder parts together but I’m not able to debug DIY hardware issues when it’s not working and getting those (single) parts in the first place is very tedious to me as a non-hardware guy.
Thanks for your work and your motivation to share it with this community!
I ran into exact the same problem (no decimal values via modbus), so I quickly set up some screen scraping.
Initially, I used the built-in HA scrape integration, but that led to a huge amount of log errors and failures as the ISG frontend has such a bad performance that the scraper throwed a lot of connectivity errors. The problem is that the scrape integration will do seperate requests for every scraping task (=sensors, 4 in my case).
I decided to use multiscrape as this can handle several data scraping tasks within one http request.
My configuration:
multiscrape:
- resource: http://<isg-ip>/?s=1,1
scan_interval: 60
sensor:
# Wärmemenge VD Heizen Tag
- unique_id: se_scrape_wm_heizen_tag
select: "div.span-11:nth-child(2) > table:nth-child(1) > tr:nth-child(2) > td:nth-child(2)"
value_template: '{{ value | replace ("KWh", "") }}'
unit_of_measurement: kWh
device_class: power
# Wärmemenge VD Warmwasser Tag
- unique_id: se_scrape_wm_warmwasser_tag
select: "div.span-11:nth-child(2) > table:nth-child(1) > tr:nth-child(4) > td:nth-child(2)"
value_template: '{{ value | replace ("KWh", "") }}'
unit_of_measurement: kWh
device_class: power
# Leistungsaufnahme VD Heizen Tag
- unique_id: se_scrape_la_heizen_tag
select: "div.span-11:nth-child(3) > table:nth-child(1) > tr:nth-child(2) > td:nth-child(2)"
value_template: '{{ value | replace ("KWh", "") }}'
unit_of_measurement: kWh
device_class: power
# Leistungsaufnahme VD Warmwasser Tag
- unique_id: se_scrape_la_warmwasser_tag
select: "div.span-11:nth-child(3) > table:nth-child(1) > tr:nth-child(4) > td:nth-child(2)"
value_template: '{{ value | replace ("KWh", "") }}'
unit_of_measurement: kWh
device_class: power
// Edit 13.06.2022: When you protected your ISG with a password, you can use the form submit functionality. This will let the multiscrape integration post the login form on first start (it will save the session / cookie, so this has not to be done every scrape run).
Just add the following lines to your multiscrape configuration:
hey sorry I am just migrating to Home Assistant… so my questions might be stupid…
- name: WPL17 Komforttemperatur
slave: 1
address: 1501
input_type: holding
scale: 0.1
precision: 2
unit_of_measurement: °C
device_class: temperature
scan_interval: 60
can I define directly at creation of such entities a value range? so a minimum and max value that entity can actually have? and a stepping like stepping 0.1 ?
for this entity the value actually translates to a string.
so if the value == 1 I would like to actually show “Standby” for a 2 “Comfort” etc.
Can this be defined directly as part of the entity syntax?
Out of interest, because I will be getting one of these later in the year, have you tried playing with data_type and precision in your sensor configs?
I was wondering if changing the precision to “3” would give you 3 decimal places (from default “0”).
Or if the comma (for european numbers) was causing a problem, and therefore changing the data_type to “string” or “float16” from the default “int16” would work.
Most of the discussion here has been around HVAC heat pump systems and not hot water heat pumps.
The SG Ready option looks like it needs a relay to control a boost function, which should be simple with something like a Shelly Uni to provide a wifi interface I can switch when I have excess solar.
The Energy Management System interface looks like it is going to have greater functionality, but I have not been able to find any details - is it via an open standard? Is this the ISG/ ModBus interface supported by the HA integration?
Anyone with experience in either of these interface options?
I did everything as you described. Unfortunately I get the following error:
Scraper_noname_0 # Multiscrape Sensor # Unable to scrape data: ‘NoneType’ object has no attribute ‘select_one’. Consider using debug logging and log_response for further investigation.
Hey, I use a Stiebel Eltron HK 07 Premium and I control it via SG-Ready (my E3DC inverter has a relay for sg-ready). It is also possible to set the sg ready conditions via modbus (so you probably don’t need a relay and the shelly). As far as I know, the Energy Management System only works with the SMA Sunny Home Manager 2.0 (Energy Management Interface (EMI))
Hello everyone,
I have a LWZ 303 integral.
Via modbus I’m able to read the values from my lwz. But I can not translate the value “betriebsstatus” into its description. For example the current value of sensor.HEIZUNG-BETRIEBSSTATUS is 1095.
Home Assistant shows entity with the status not avalible.
Does anyone have an idea, where my mistake is?
As far as I have seen (and entirely based on my very recent experiences) the entity IDs get reformatted as compared to the name you defined in your first sensor.
So the entity ID for “HEIZUNG-BETRIEBSSTATUS” likely is “sensor.heizung_betriebsstatus”. You can confirm this by checking the entity in Developer Tools > States. Once there you can also save yourself some typos by clicking the copy button next to the entity ID and pasting it.
Just a tip; in my case I converted the statuses through binary “running” sensor templates instead of generic sensors. It seemed appropriate and I find it gives a slightly cleaner look in dashboards. I am assuming that you are building based on @ArminF 's trail blazing work. (can’t thank him enough!) If yes, you would have to store the binary sensor templates in a different folder that also needs to be referenced in configuration.yaml
It looks like this for me:
configuration.yaml
# Include sensors (all in a seperate *.yaml)
sensor: !include_dir_merge_list sensor/
binary_sensor: !include_dir_merge_list sensor_binary/
And then in another yaml file created in the “sensor_binary” folder
# Sensor
# Stiebel WPM Templates
- platform: template
sensors:
# Operational State Template
# Converts the operational state of the WPL to running or not running
wpm_system_state_hc1_pump_active:
friendly_name: "WPM System - Internal Circuit Pump"
device_class: running
value_template: "{{ states('sensor.wpm_system_wpm_operating_states')|int|bitwise_and(1) > 0 }}"
wpm_system_state_hc2_pump_active:
friendly_name: "WPM System - Heating Circuit Pump"
device_class: running
value_template: "{{ states('sensor.wpm_system_wpm_operating_states')|int|bitwise_and(2) > 0 }}"
wpm_system_state_heat_up_active:
friendly_name: "WPM System - Heat-Up"
device_class: running
value_template: "{{ states('sensor.wpm_system_wpm_operating_states')|int|bitwise_and(4) > 0 }}"
wpm_system_state_backup_heater_active:
friendly_name: "WPM System - Backup Heater"
device_class: running
value_template: "{{ states('sensor.wpm_system_wpm_operating_states')|int|bitwise_and(8) > 0 }}"
wpm_system_state_heating_active:
friendly_name: "WPM System - Heating"
device_class: running
value_template: "{{ states('sensor.wpm_system_wpm_operating_states')|int|bitwise_and(16) > 0 }}"
wpm_system_state_warm_water_production_active:
friendly_name: "WPM System - Warm Water Production"
device_class: running
value_template: "{{ states('sensor.wpm_system_wpm_operating_states')|int|bitwise_and(32) > 0 }}"
wpm_system_state_compressor_active:
friendly_name: "WPM System - Compressor"
device_class: running
value_template: "{{ states('sensor.wpm_system_wpm_operating_states')|int|bitwise_and(64) > 0 }}"
wpm_system_state_summer_mode_active:
friendly_name: "WPM System - Summer Mode"
device_class: running
value_template: "{{ states('sensor.wpm_system_wpm_operating_states')|int|bitwise_and(128) > 0 }}"
The important part is to reference the “device_class”
It has been a while but I thought I would share my experience on this since I have been going through the same process and was also considering using a physical relay at first. Turns out it is totally possible to trigger the SG Ready inputs through Modbus. In my case I used Node-Red and the “Modbus - Write” node. (FC6, Address 4001). “Boost production” is a helper that I switch on or off when my PV production passes a certain threshold for a certain time as well as early morning when the grid price is lower. When it is toggled the following executes.
This is for an ISG Plus connected to a WPM 3i controller for a WPF10 geothermal heat pump. The SG-Ready input has to be switched to Modbus in servicewelt. Might need to double check the Modbus address for another setup.
just wanted to say THANK YOU to everybody in this thread. It helped me very much to figure out a solution to my problem (getting 2 Stiebel Eltron Heat Pumps in 1 Network connected to Home Assistant). Finaly made it with “modbus:”-integration in configuration.yaml (and a bit multiscrape-sensor).
