[modbus] Do not process values from channel if configured transformation service is unavailable (during startup) #16847
Comments
dandjo
changed the title
|
Looks very similar to openhab/openhab-core#3763 |
|
@lolodomo True, especially 3763#1745267997 comment nails the issue. |
|
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/oh4-transformationservice-of-type-js-is-unavailable/148786/21 |
|
@lolodomo @kaikreuzer Are there any ideas on how to solve this? Is it even possible to influence the order? Is there a dependency management for this? |
|
This is not a core issue. The |
J-N-K
changed the title
|
Has anybody found a solution to this? It's really bothering at least for modbus add-on (which ususally requires read/write transforms) |
|
I found a workaround, which is not really satisfying, but solves the issue atm. I created a transformation script of the same type which I am using in the thing transformation (
|
|
@dandjo if the scale is wrong, we could try to fix this using bare UoM. No transformation service might be needed at all. Since 4.2.0 the persistence services UoM support has been greatly enhanced. It should now be possible to store, show and calculate in your unit of choice. If you need help to adapt, please state your item labels, scripts and persistence configuration. |
|
I have moved away from JS, you can see some discussions in this post: |
|
Have not read everything, can I assume this issue is fixed / no longer relevant? If so please close it otherwise add details so we can work on this together. |
|
@lsiepel it is relevant and not fixed. Using UoM is the wrong approach, since some transformations are more complex for certain Modbus data. The behavior of |
|
@jimtng in #17306 this transformation was adapted to support chaining, while related it does not fix this issue. So i was looking into this again. |
|
When I migrated it to use ChannelTransformation, I retained the original behaviour of the binding. It passes through the data unmodified when the transformation failed. Since I don't use modbus binding myself, I'm not sure why it was designed this way originally. #17457 will discard the data now, but I need testers to make sure that this doesn't break something. |
|
@dandjo would you be able to test? |
|
@jimtng I cannot recall either why it was built this way originally. |
|
For those who can test, I've posted a jar file here #17457 |
|
@jimtng basically it works, but I'm getting this error: |
|
@dandjo thanks for testing. Can you tell me if you're running a recent openhab 4.3 snapshot (M1 or later) with the test bundle? At first glance I can't tell how the change I made could affect discovery. |
|
@jimtng Yes, 4.3.0-M1 running here. When using the original ModBus binding, the error is gone, so it definitively has to do with the manual placed jar. |
|
Maybe double check by re-compiling, uploading and verifying the used version in karaf. It should have a date in the version if i remember correctly. |
|
Not sure what you want me to check @lsiepel :-) The pasted Exception above tells me, I'm using This is what openHAB tells me: |
|
Was mainly for jimtng. Only thing you could double check is if the bundled version of the binding is ininstalled. Two versions of the same binding can give weird results. I also don’t see any relation between the PR and the exception . |
|
@dandjo When testing the jar, was the bundle |
|
@jimtng When uninstalling the original ModBus binding and placing the jar in the addons folder, I get a non functional binding: Wen placing the jar in the addon folder without modifications to my setup I get the following with the error pasted before: |
|
Try stopping the stock binding, don't let both be active at the same time. |
|
Okay, done. Now the error is gone and the binding is providing correct values. Seems to work in general. |
|
Ok, I'm experiencing weird behavior now. After a restart, the "Read Transform" settings are wrapped with "[]" and the transformation got completely broken. Original values are passed and destroy my persistence. Maybe someone else could test this too.
|
This is because you've reverted to the default binding, not the new binding. It's because of this new enhancement: #17306 which was merged after 4.3.0.M1. To be sure, once you've upgraded to snapshot, check the read transform settings again, make sure there are no |
|
@jimtng Thanks, I see. What is the correct inline syntax with the new version? before: new: Is this correct? |
|
Both syntaxes are supported by the new version |
|
Yes, but which syntax is preferred and should be used in the future? |
|
At the moment, it is undecided, so perhaps both will continue to be supported. The idea was to make the syntax uniform with the core syntax, i.e. the |
|
Thanks, LGTM! |
Expected Behavior
Consistent value range for items.
Current Behavior
When starting or restarting openHAB, services like ModBus poll data from server ignore transformation services (here: JS) when they are not ready. This results in values out of usual value range destroying average calculations and representations (e.g. in Grafana - see screenshot).
Possible Solution
Ignore values from Thing channel when transformation is configured but not available or initialize transformation services earlier or before Things.
Steps to Reproduce (for Bugs)
Your Environment
The text was updated successfully, but these errors were encountered: