Issue of the topic: OneWire channels don’t update when using transform:JS
Hi,
I’m trying to get transform:JS working on OneWire channels (via profile, as I’m planning to directly forward it to KNX). However, as soon as I add a transform:JS profile to a OneWire channel, it stops updating its values. This only happens in the combination of OneWire with transform - other channel types and other profiles seem to work well.
Number TestValueKNX "Test [%s]" { channel="knx:device:bridge:knx_device:voc"[profile="transform:JS", function="test.js"] } // works
Number TestValue1 "Test [%s]" { channel="onewire:ms-tx:6df521a0:26_59141A020000:voltage"[profile="offset", offset="10"] } // works
Number TestValue2 "Test [%s]" { channel="onewire:ms-tx:6df521a0:26_59141A020000:voltage"[profile="transform:JS", function="test.js"] } // never updates, no error message in log
As reference, also the test.js (it’s just a dummy):
(function(i) {
return i;
})(input)
As OneWire is a version 2 binding, it should fully support profiles, right?
Am I missing something, or could that be a bug?
I don’t know the answer, but is there an issue here because your Item is a Number type, whilst the JavaScript will return a String? (By default, the profile sends a String (%s) to the transform) Do you have a String type Item you could test on?
I just made the item a String - and interestingly it kind of works then. Which is quite interesting, as the transform works very well with the item type being a Number when doing the same with a value coming from KNX.
However, just making it a String item doesn’t solve my problem - I’d like to forward it to KNX like this:
However, no values seem to get sent to KNX. I assume it’s because the data type expects a number. Making the item a Number and removing the transform works (but then lacks the conversion).
Is there maybe some other way that avoids rules to make this happen?
Worst case I can fall back to rules, but I did hope for a more elegant solution.
I don’t know anything about the OneWire binding, but with other bindings you can apply the transformation at the incoming Thing Channel (i.e. before the Item picks it up). Does OneWire allow the same?
I’m not sure what that means. As far as I understand, profiles are always assigned to the link between a channel and an item - and the transformation does happen before it goes to the item, also in this case, but then it seems to fail because the item type isn’t compatible with string.
Do you have an example for how to do this with another binding?
This profile is a one-way transformation; only values from a device toward the item are changed.
Only Values comming from the channel to the item are transformed. You can create another string item and link it to the same channel to put data into the channel that will then be transformed to the other item.
There isn’t any ‘forwarding’ in your configuration.
Your Item is linked to two channels.
Generally, incoming traffic to a binding results in an Item state update. Commands issued to an Item result in outgoing traffic via bindings.
You might look at the follow profile for this purpose, but it does have limitations.
Also of note, you can only apply one profile at a time to any given Item-channel link.
Speaking of limitations, the inability of transform profile to work with other than String type Items should have been fixd recently, but I do not know which version it will appear in
EDIT - I now realize you won’t be able to use transform profile with anything other than a String type Item until OH3
Thanks everyone!
Interestingly the “forwarding” seems to work even without the follow profile.
IIRC my first attempts (before trying to transform data) were even with follow, which didn’t work - then I came across another post where someone shared their config (without follow). Doing it the same way seemed to work for me, but that was without transforming anything.
Regarding limitations: I’ve come across the same post - I’m just still puzzled that it seems to work flawlessly if I transform KNX input, so this restriction seems to not apply everywhere. Maybe the KNX binding just has a special way of treating data.
There’s no public time frame for the OH3 release yet, is there?
