Thank you soo much for looking this up. Your assumption is absolutely right! I thought, maybe the API is documented in german language and therefore called “EVU Sperre”. Until know I haven’t spent an eye on the API, I have to register first.
The EVU Sperre is a 230V line which is fed from a relay the electricity provider can control. It is fed into the control unit of the heat pump system as a simple “control signal”, so it does not cut any power by itself - it just “tells” the control unit of the heat pump system to shut down the compressor (when active in that moment) or simply suppress the start. So the system itself is up at any time and COULD report that of course to the Viessmann server (I assumed, it already does).
I will also have a look at the API you linked above.
If it’s not possible to get it via software, I have to monitor the relay’s status in hardware - more expense of course. But I will do it if we cannot get it from the software.
many thanks for the tip. The functionality is known to me, but the implementation is too rigid for me.
After the legionella has been eliminated, I want to continue using the warm water for the washing machine/dishwasher or for showers. The easiest way is to be able to start such a process flexibly, e.g. by pressing a button and if the button is not pressed within the specifications, then as plan B with a timer.
I will try this at next weekend, just right now i am far away from home. I have VPN but a small mistake could turn off the heating for the rest of the family…
I will send you the log at the weekend.
One thing I notice about your item configuration:
You have no decimal places, the value is directly 51.
In my case decimal places are displayed, here is a screenshot:
In the communication string of the API, the limits are also without decimal places:
Currently I have defined the item without a decimal place, in the past I probably made the mistake of defining a decimal place. Unfortunately, it is still displayed. Do you have any idea how to get rid of it?
In the meantime I have created the log according to your instructions, you can find it in the attachment. I have removed unimportant entries that are based on other items.
Does it make sense to completely remove the binding and reinstall?
Which leads me to think that for some reason OpenHAB is not propagating the change from the Item to the Thing. Is there some problem with the channel link?
heating.dhw.charging is not currently implemented, I guess that might tell you whether it is actively in use.
For the heat pump it seems there are a lot of compressor stats in heating.compressor.N including heating.compressors.N.power.consumption.current but they are all advanced features of the API so not available in the base package. I don’t support these and not sure if they would appear on your device or not if you don’t already have the advanced package, I guess you would have to check with Viessmann.
AFAIK with my own Vitodens 100-W there is no explicit way to tell if it’s currently calling for hot water or heating, which is I think what you are after (as opposed to whether the DHW/heating programs are on or off) - but usually the flow temp and burner modulation are a bit of a giveaway.
Everything else works, I reinstalled your binding and also created a new Viessmann account.
For example, I can set the heating temperature (vicare:heating:534acfab75:163f539d-dd98-3493-9522-26a506a61922:heating_circuits_0_operating_programs_normal) normally and it changes in Vicare. Only the DHW temperature is not transmitted for some reason.
The heating is a Vitodens 200-W. In the meantime I have provided the metadata with the pattern “%.0f”. But brought no change.
Hi,
can someone provide example code to set up the bridge thing, the (heating) device thing and the some items by code. I have managed to setup up everthing by the GUI, but I have all other things and items added by code. I found a code snippet in the 3.3 thread, but it could set up only the bridge with this code.
Can someone help?
Kind regard
Heiko
Looks like the API does not provide anything to monitor the control signal from the power provider. So I will make a piece of hardware to get that signal via an optical sensor and fed it into the zwave network I have.
BUT I found another thing which I am not sure of if it is related to your binding or Viessmann server/API:
When I set the eco mode or comfort mode (assuming I am in the “normal mode” of the heating system), I can enable that specific mode (eco or comfort). BUT: I am NOT able to DISABLE that modes and go back to “normal mode”. Might the be a bug in your binding while processing the “OFF” commands to Viessmann or is it a problem on Viessmann’s side?
The Viessmann API description tells the following:
heating.circuits.N.operating.programs.eco
Shows whether the eco program is active and the defined target temperature. Also provides the commands to enable/disable the program
or
heating.circuits.N.operating.programs.comfort
Shows whether the comfort program is active and the defined target temperature. Also provides the commands to enable/disable the program and change the program’s temperature value
or
heating.circuits.N.operating.programs.normal
Shows whether the normal program is active and the defined target temperature. Also provides the commands to enable/disable the program and change the program’s temperature value
In your binding only the channels “heating_circuits_0_operating_programs_eco_active (Switch)” and “heating_circuits_0_operating_programs_comfort_active (Switch)” are read/write (but setting them to “OFF” when they are actually “ON” does not work.
In addition to that both channels the channel for “normal mode” (“heating_circuits_0_operating_programs_normal_active (Switch)”) is read-only and don’t let me switch to “ON”. In this constellation now I am able to:
1.) set ECO mode to ON or
2.) set COMFORT mode to ON but
3.) setting ECO mode or COMFORT mode to OFF is not accepted as they will switch back to ON automatically after a while (answer from Viessmann server or timeout?) once the mode has been set before!
4.) in both cases I cannot get back to NORMAL mode since the normal mode channel is read-only and setting ECO mode or COMFORT mode to OFF does not work (see 3.)
Is there any chance to get that working as expected? Can you have a look on this?
That would be REALLY GREAT!
If there is something for me to check, please let me know immediately. Thank you in advance!
BUT I found another thing which I am not sure of if it is related to your binding or Viessmann server/API:
When I set the eco mode or comfort mode (assuming I am in the “normal mode” of the heating system), I can enable that specific mode (eco or comfort). BUT: I am NOT able to DISABLE that modes and go back to “normal mode”. Might the be a bug in your binding while processing the “OFF” commands to Viessmann or is it a problem on Viessmann’s side?
For my boiler at least, currenty the active property for each program reports 502 device communication error (403 command not executable) when attempting to activate. The API reports isExecutable = false. My boiler appears to have activated seasonal energy saving mode and I suspect that’s the reason why.
I’m not sure if that was applicable when you tried it. However in the past I seem to remember that it also doesn’t work, I think because it’s controlled by the timer program, therefore you can only extend the heating program using forcedLastFromSchedule. I could be misremembering that.
I don’t have an “eco” program, only a “reduced” program. Not sure if the two are equivalent.
4.) in both cases I cannot get back to NORMAL mode since the normal mode channel is read-only and setting ECO mode or COMFORT mode to OFF does not work (see 3.)
API reports Normal operating program is read-only on my system as well. I don’t know why, that’s just the way it is…
BTW you need to be careful with the terminology, operating mode and operating programs are separate things, don’t get the two mixed up.
I just switched from smart js plugin … on 3.4 openhab. As far as I can see: works like a charm!
I noticed that some endpoints changed; I was looking for a channel formerly know as
heating.solar.power.cumulativeProduced
… in ViCare it is still reported … any chance we can get an access to it?
There is support for heating.solar.power.production.current/PreviousDay/Week/Month/Year which are the API features containing rollups of power consumption.
I don’t think I’ve ever supported h.s.p.cumulativeProduced - it isn’t populated in any of the API responses people have sent me so I don’t know if anything actually uses it.
I can add support for it, if you send me your API json then I will know what format it’s in, I expect it’s a normal scalar in the “value” property but occasionally Viessmann are a bit weird with their property naming so you never know.
It isn’t currently supported, I have created a github issue to track it, I will put it in the next release
The examples I have only show it has an “active” property and as not active, does it ever have a “status” property or anything else, like some other features?
Regarding the “heating.dhw.charging” I asked at Viessmann if it would be possible to get a switch endpoint in order to turn it ON/OFF without the internal schedule.
The answer was as expected. Presently not implemented and the request will be handed to the developer branch (the dark hole?).
My humble guess is that such a switch, if ever implemented, will not be in the basic package.
Hi @opus,
As “heating.dhw.charging” means that the unit is producing domestic hot water, do you know which is the equivalent end point that tells you when the unit is producing hot water for the heating system?
