[ism8] Binding ism8 doesn't support UoM, values don't update #9598
Comments
schmidmuc
added
the
bug
It should pointed out that so far UoM item types are not supported. Related issue about UoM support is opened here: openhab#9598
Hilbrand
added
enhancement
|
This is not a bug. But by design. I suspect this binding was created before UoM types was introduced. |
|
The binding was introduced as a new binding with release 2.5.9 - UoM were introduced a long time before. |
|
@schmidmuc looking at the binding, it internally allready has units specified in many cases. So i don't think it will be hard to implement it. The problem is that i don't have a ism8 device and that makes testing and polishing tedious. @holgerfriedrich did a PR last week to this binding, don't know if he is planning to do more changes? Anyway, i'm fine spending some time on it, but i do need others to test and verify. |
|
@lsiepel I do not plan to spend more time here, still busy with knx binding. I just went through the bindings I have used before and did some quick fixes. My ism8 is now connected to a BAOS device and no loger available for testing. |
|
Thanks for the quick response, maybe @schmidmuc is available for testing, otherwise i pass on this. |
Thanks, that you would spend efforts to work on this topic. I have the ISM8 still in use, so I could support with testing when getting the jar file including the changes. |
|
Made a first attempt. 3.4.1 Jar is available here: https://1drv.ms/u/s!AnMcxmvEeupwjp4L347Q22cnMI1QQg?e=ROo8Y1 Used UoM types. If you test, please enable debug loging if you have any issues. I mainly focused on data flowing from the device to openHAB. Edit: The channel types have changes, so you need to setup the channels again. I added a table to the readme.md half -way: https://github.com/lsiepel/openhab-addons/blob/ism8-uom-400/bundles/org.openhab.binding.ism8/README.md |
|
Did some first tests with 3.4.1 version: Getting values from read-only ISM values to OpenHab items seems to work. But I'm wondering if in things configuration menu with channel ribbon opened (shown in following screenshot) channel type shouldn't be "Number:Temperature" instead of "Number"? Setting a writeable value didn't work in a first try, but not sure if this worked with former version, as I do not use this regularly: |
|
Yes that should have been Number:Temperature. Did you re-create this channel? (delete and add it) Writing the value failed because the unit was also send to the channel. It should only send the number. Do you use some formatting on the item? I'll also look on the code side if there is anything i have missed or can be improved. Thanks for first results! |
|
Just finished a new version. You can use the same download link. Version is as of 2023-01-08 13:09 Let me know any results. Please provide a debug log if you encounter any issues including the actions before the issue. |
|
After some time thing goes OFFLINE:
I changed the port in OH and in ISM, but after some time same error occurs. Interesting is, that between the connection losses the binding/thing receives data, like seen in the log below:
Things configuration menu with channel ribbon opened (shown in following screenshot) channel typeis now shown correctly with "Number:Temperature" instead of "Number": |
|
After connection problems occur also values are updated wrong although data interpreation in log seems correct:
But shown in UI like |
|
So i guess there are two issues:
I'll look into it later this week. Thanks for your testing efforts! |
|
Deleting the ism8 thing for a new start and even deleting the binding jar does not stop the failure messages in log file. Something still tries to bind the port 12005:
|
|
Things seems not to unbind the ports after deletion:
Both ports are still blocked although no active thing is existing anymore. |
|
Ok, startet from skretch with a changed port to 12006: Deleted and installed the binding again: 2023-01-08 23:02:14.152 [DEBUG] [ing.ism8.internal.Ism8HandlerFactory] - bundle org.openhab.binding.ism8:3.4.1.202301081209 (331)[org.openhab.binding.ism8.internal.Ism8HandlerFactory] : BundleComponentActivator : ComponentHolder created. Thing recreated: 2023-01-08 23:04:17.249 [DEBUG] [g.openhab.binding.ism8.server.Server] - Waiting for connection in port 12006. Channel #1 created: 2023-01-08 23:07:15.177 [DEBUG] [ab.binding.ism8.internal.Ism8Handler] - Ism8: Channel=Configuration[{key=type; type=String; value=9.002}, {key=id; type=BigDecimal; value=4}] From this point on the thing goes OFFLINE again |
|
Not sure if this is the same issue: When adding a channel with channel type "Temperature Readonly DataPoint" there is only choice to select type "DPT_Value_Tempd" (9.002), but not "DPT_Value_Temp" (9.001)
|
|
Might all be the same issue. 9.001 was accidently removed in the proces from the both channels. I reinstated them with new version: 2023-01-09 13:23. I also wrote some tests, to assure this back and forth data exchange is stable. Thanks for giving the details. Hope this new version is more stable. I have one remaining concern for writing channels, but your (hopefully) last test will show if it is ok or not. |
|
Connection and things' state now is stable. 9.001 type is shown too. Configuration works, but values are not taken over to the items. With former version debug looked like this: Now it look this way (for the same parameter ID = 4: Did you change the logging format or are there some processing steps missing which show the following two lines before: |
|
Yep, found it. The link is updated version 2023-01-09 21:21 Did not yet document it, but the behavior has changed. Previously the DataPoint ID could be added to as many channels as needed. As side effect, every message was looped and matches to every channel. Now the behavior is different, as soon as it finds a channel with mathing datapoint id in the config, it stops looking for others. (way more efficient) TL:DR the binding demands unique DataPoint Id's per channel. I can not think of a situation where one would need the same DataPoint Id on different channels. (effectively that would be clones). |
|
Hhmm, the item still doesn't get an update. But still searching if there might be another reason for this. 2023-01-09 23:10:36.102 [DEBUG] [g.openhab.binding.ism8.server.Server] - Data received: 0620F080001604000000F00600040001000403020F4E |
|
Does any item get updated? Or non at all? Maybe stupid question, but the item is properly linked? Will continue to search further. But the tests are concluding that the channel is updated, the rest is up to the openHAB framework. |
|
Added a new version 2022-10-01 16:56 . No funcitonal change, alot more verbose logging. About every code path has a log. as i don;t understand (yet) why it is not working. Did you recently re-create the channel? |
|
Thanks for the new file - below the log outputs after I removed the old thing incl. all channels and deleted the old jar. After uploading the new jar file: 2023-01-10 21:59:09.203 [DEBUG] [ing.ism8.internal.Ism8HandlerFactory] - bundle org.openhab.binding.ism8:3.4.1.202301101556 (336)[org.openhab.binding.ism8.internal.Ism8HandlerFactory] : BundleComponentActivator : ComponentHolder created. After creation of thing: 2023-01-10 22:01:46.579 [DEBUG] [g.openhab.binding.ism8.server.Server] - Waiting for connection in port 12008. After creation of a channel for ID 4: 2023-01-10 22:02:52.587 [DEBUG] [g.openhab.binding.ism8.server.Server] - Stop Ism8 server. |
|
There where no more lines after 2023-01-10 22:02:59.820 ? As exactly after this data send line there should be aditional logging. Edit: looks something is going wrong with binding init. i don not see this Ism8: Channel= in the logs. So the datapoint is not registered and that certainly leads to no channel updated. |
|
Just to be sure, the latest version is the following one? 336 │ Active │ 80 │ 3.4.1.202301101556 │ org.openhab.binding.ism8 After this only a lot more channel / id data was sent: 2023-01-10 22:02:59.820 [DEBUG] [g.openhab.binding.ism8.server.Server] - Data sent: 0620F080001104000000F0860005000000 |
|
oke, i'm interested in the logging when you disable the binding and enable it again. |
|
Disable and enable = delete the jar file and upload again? |
Sorry, hold on, think i found it. |
|
Yep, think i found it, the lack of logs was an indicator. Please retry with the newest version Edit: i refactored the init method. This method is not part of the tests so it was not clear that a var was declared and all fine, but in the wrong scope :-( leading to not registering the datapoints ... leading to not updating the channels. |
|
First tests with new version successful. Item states get updates. Will add some more channels/items with different units and a writeable channel as well. Will send an update later. 337 │ Active │ 80 │ 3.4.1.202301102135 │ org.openhab.binding.ism8 |
|
Some more test results - more to come tomorrow maybe. 1.) Crash of thing After adding some more channels thing changed to error state. Same behavior like described two days ago. Deleting thing and deleting the binding jar still blocks the selected port. 2023-01-10 22:55:31.931 [DEBUG] [g.openhab.binding.ism8.server.Server] - Stop Ism8 server. Deleting the thing, deleting the jar file, restarting OH, uploading jar file again, recreating the thing incl. channels -> works again. After this reinstall/recreation such a crash did not happen again. Maybe this was caused to so many times create/delete and again and again. 2.) Boolean values DpID 9 is of type DPT_Switch - chosed DPT_Switch in channel configuration menu. Log file shows following DEBUG information - seems that switch type and boolean type are mixed somehow: 2023-01-10 23:18:02.209 [DEBUG] [g.openhab.binding.ism8.server.Server] - Data received: 0620F080001504000000F006000900010009030100 Changed to DPT_Bool, same logging: 2023-01-10 23:25:53.091 [DEBUG] [g.openhab.binding.ism8.server.Server] - Message received: 9 0009030100 Same behaviour for a DPT_OpenClose datapoint: 2023-01-10 23:29:09.828 [DEBUG] [g.openhab.binding.ism8.server.Server] - Message received: 12 000C030100 3.) Setting a writable value 3.1) Setting a number value Parameter was succesfully changed within the Wolf heating device. 2023-01-10 23:36:39.388 [DEBUG] [ab.binding.ism8.server.DataPointBase] - Convert into byte array '56.0' 3.2) Setting a DPT_DHWMode value Parameter was succesfully changed within the Wolf heating device. 2023-01-10 23:50:43.530 [DEBUG] [ab.binding.ism8.server.DataPointBase] - Convert into byte array '4' |
|
Great results, thanks. Should be cool if we can also hit the last remaining types:
|
|
Ok, then lets go on with the testing, now with new version 3.4.1.202301111025 installed. 2.) Boolean values 2023-01-11 20:48:38.173 [DEBUG] [g.openhab.binding.ism8.server.Server] - Data received: 0620F080001504000000F006000900010009030100 4.) DPT_DHWMode and DPT_HVACContrMode values 2023-01-11 20:48:43.335 [DEBUG] [g.openhab.binding.ism8.server.Server] - Data received: 0620F080001504000000F006003A0001003A030100 2023-01-11 20:48:34.852 [DEBUG] [g.openhab.binding.ism8.server.Server] - Data received: 0620F080001504000000F006000200010002030101 **5.) Percentage value ** Works as expected. 2023-01-11 20:48:35.013 [DEBUG] [g.openhab.binding.ism8.server.Server] - Data received: 0620F080001504000000F006000300010003030100 6.) Pressure value Works as expected. 2023-01-11 21:01:39.883 [DEBUG] [g.openhab.binding.ism8.server.Server] - Data received: 0620F080001604000000F006000D0001000D03027407 7.) Flow rate Do not have a flow rate channel, so I have no chance to test this type. 8.) Tempd value Receiving values and setting a value works as expected. 2023-01-11 21:20:09.771 [DEBUG] [g.openhab.binding.ism8.server.Server] - Data received: 0620F080001604000000F00600420001004203020190 2023-01-11 21:31:27.428 [DEBUG] [ab.binding.ism8.server.DataPointBase] - Convert into byte array '3.0' |
|
Do you know if the Mode channels are always 0/1 or are there more states? |
|
Screenshot from the ISM8 manual: |
|
Would be nice to map that to a channel with preset values, but this data list is different for each device :-( Anyway, i think the DataPointByteValue is now also covered and added some tests for those too. I guess we are all set now. Edit version: 2023-01-11 23:22 is available |
|
Think so too. |
Expected Behavior
It should be possible to link ism8 channels to items with UoM, such as Number:Temperature for all temperature values, etc.
Current Behavior
When linking an ism8 temperature channel to a Number:Temperature item values are not updated.
Possible Solution
Integrate UoM support to binding.
The text was updated successfully, but these errors were encountered: