Yes, you do have a unit issue only. If your solar system generated this amount I’d immediately change my brand :-)!
To be correct you’ll need to multiply it by 10 to get KW. If you compare ‘DPT_FlowRate’ [0,0001 m³/h] and ‘DPT_ActiveEnergy’ [1 Wh]. If ‘DPT_FlowRate’ is selected, the binding multiplies the value internally by 0,0001 to get [m³/h]. Thus, multiplying this result by 10 for ‘DPT_ActiveEnergy’ will give you [1 KWh].
The ‘DPT_ActiveEnergy_kWh’ data point will work as well and you only need to take care for the proper multiplier.
Adding those 2 points to the binding shouldn’t be too hard. I’ll keep it in mind and maybe at the end of the year I’ll create a new version.
Anything else you did notice as your system seems to be more complex than my system?
i’ve added the second channel now to see what value is coming on from ism8i. I think the value ist only updated from time to time so i have to wait. For the moment it says “0”.
I would also like to try the datapoints showing the flow rate for the solar system. The DP is “DPT_Value_Volume_Flow”. Running the binding in debug log mode it seems the data point is sent from ism8i to openhab (see the log entries for the dp at the console).
I tried to use the existing flow rate DP, but this gives me an error at the console:
2022-11-06 15:33:31.959 [DEBUG] [g.openhab.binding.ism8.server.Server] - Message received: 147 009303024500
2022-11-06 15:33:31.960 [DEBUG] [nding.ism8.server.DataPointLongValue] - DataPoint-ProcessData: Data size wrong for this type(2/4).
2022-11-06 15:33:31.960 [DEBUG] [g.openhab.binding.ism8.server.Server] - Solar Durchfluss n
2022-11-06 15:33:31.960 [DEBUG] [ab.binding.ism8.internal.Ism8Handler] - Ism8: dataPointChanged DataPoint 147=n
2022-11-06 15:33:31.960 [DEBUG] [ab.binding.ism8.internal.Ism8Handler] - Ism8 updateDataPoint ID:147 n
Maybe thats also something we can find a workround for?
And after setting the console output for the binding to debug mode i can see that there are several other messages coming in from ism8i with DP-Numbers higher than the ones listed at the wolf manual. 354 - 385 are the numbers. Any Idea whats behind those messages?
You are fully correct in terms of receiving data. The ISM8 is sending its changes to OH and not the other way around. This means that there is no option to read explicit a value from your heating system. Some values are only send if the value has changed within the heating system. Therefore it might take a while before the value is present. The binding does send uppon startup the request to the ISM8 to send all values, but the ultimate decision what and when something is send is linked to the ISM firmware.
The work-a-round do only work as long as we are talking about an output scaling, but this doesn’t work if the underlying data-type is different. In the specific case of DP-147 there is the need to check within the manual the definition of the DP. In this case this is ‘DPT_Power’, so ‘9.024’ and this is ‘PDT_KNX_FLOAT’.
As mentioned in my initial description (Ism8 - Bindings | openHAB) did I not implement all types, but only the following types:
DPT-Bool: 1.001, 1.002, 1.003, 1.009
DPT-Scaling: 5.001
DPT-Value: 9.001, 9.002, 9.006
DPT-FlowRate: 13.002
DPT-Mode: 20.102, 20.103, 20.105
Looking into the data-point type description of the manual, it seems you can use ‘9.002’ for ID147. There is only the unit different as ‘9.002’ is ‘Kelvin’ while ‘9.024’ is ‘KW’.
I hope the description is not confusing you too much .
Instead of dealing with all the work-a-rounds we may better target to implement the missing DPs as it seems somebody else than myself is also using it.
Would you like to spent some time and contribute? Maybe we can synch and divide a bit the tasks.
With respect to DP >350 I had no idea, as I was using the reference manual from 2016. I just found a newer version (https://www.wolf-heiztechnik.at/download/?file=4252.pdf) and within this manual there are some newer DPs. Please have a look and check if there is something you can use.
actually I’m not sure about your situation. I checked the log file and have the following comments:
No ThingHandlerFactory found for thing ism8:device:heater (thing-type is ism8:device). Deferring initialization.
This is a strange message and I didn’t see anything similar when testing in my test-setup. I’m not sure, but it looks the initialization did not complete
All other log entries are completely identical to my test setup
I’m missing the following line in your log: [DEBUG] [g.openhab.binding.ism8.server.Server] - Waiting for connection in port 12004
As you were not sharing the full log, please check if the entry of point 3 is really missing.
If yes, I’d recommend to remove the binding (uninstall) and add this again. Please also start from a fresh configuration until reaching a working situation.
With enabled logging you must see the message ‘Waiting for connection in port 12004’ as otherwise the port is not open and nothing can be received.
thank you again. I re-checked my log for the entry of point 3 with no result. Since all other ism entries are ok the problem is obviously not the binding but the missing initialization (point 1). I am looking through my setup again, however, it may take some time.
sounds good, i’m happy to contribute. Have to dive in into Java Development though, i’m more familiar with typescript / nodejs.
Out of a sudden the binding killed my openhab yesterday evening. After a restart of the openhab service, the binding seems to recieve values (is also shown as ONLINE), but no values are updated for the channels (every channel shows “NULL”).
Log is in debug mode for the binding and i see the messages coming in from ism8i, but the log lines for setting the channel values are not there.
Any Idea where i could start checking for the problem?
I never had any similar case, so basically I’d try to disable parts until the system works again. As the logging does indicate incoming values, I suspect any post processing (e.g. scaling or any JS transformation). Didn’t you had something similar some days ago?
Make a backup and start to remove or deactivate features. I assume you are checking the items within the OH setup environment.
you’re right! Seems like the last added channel for “Gesamtertrag” was the problem. Removed the channel and restarted the binding. Directly after restarting the values came in and referenced channels updated. After checking the code of the binding, i couldn’t find the root cause for the whole binding crashing cause of the channel. Will look into it in more detail tomorrow.
I am new to this community, using openHAB since one year in a more simple way so far.
Now i took some time to try to understand my heatpump by connecting to openhab via ism8i (the ism7i just connects to cloud and i dont want that).
Some values i can receice, but some i cant, because the thing produces errors as the used options are not allowed by the binding… eg 191, 65, …
I have the CHA Wärmepumpe which is quite new. I kmow many people installing that heatpump so it would be nice if the connection to OH would work.
P.s. my manual is from 2021-02 so even newer than the one posted above.
Is there any chance the binding will be updated with the new datapoints?
9.006 (pressure)
9.024
9.025
10.001
11.001
I could contribute by uploading the manual, or what else, but programming is not my best skill, unfortunately.
yes, the values you are targeting are not embedded in the current version. It shouldn’t be too hard to expand it, but the point is that I cannot test it as my system doesn’t have any of those DPs.
Which version are you running?
I could create a version containing these DPs, but then I do need your contribution to test it. To release the binding and officially make it available through OH, we should test it upfront.
Do you have the manual (2021-02) as PDF or a link? I was using 2016-11 during the initial development.
Thanks for the positive Feedback! Actually I could not find my version of the manual online. Instead i found a even newer one. The expansion of the adapter with the newest datapoints could also be usefull for orhers.
I would be glad testing the adapter with my system:
WOLF CHA-07 Monoblock
Ism8i FW 1.70
OpenHAB 3.2
Manual:
It sais that its for FW 1.80, but i assume its compatible to lower versions. Maybe you will see that as you already know the older adapter configuration
.