Scale transformation issues (openhabian with 2.5.0~M1-1)

  • Platform information:
    • Hardware: raspberry pi 3b+
    • OS: openhabian
    • Java Runtime Environment: openjdk 1.8.0_202
    • openHAB version: 2.5.0~M1-1

I want to automate my roller/shutters based on the sun’s azimuth (using the astro thing)
For this I want to create a switch item for each side of my house indicating if that side is illuminated by the sun. I wanted to use a scale transformation on the azimuth channel of the astro thing to configure this switch. So my items look like this

Switch SunOnSouthFacade “Southfacade lit” (GF_Kitchen) {channel=“astro:sun:local:position#azimuth”, profile=“transform:SCALE”,function=“sunOnSouthFacade.scale”}

(The GF_Kitchen is only to make sure it appears in basicUI)
and the scale file currently contains:

[0-1000]=ON
[NaN]=OFF
[…]=OFF

The reason for the large range is that I’m not sure if the values should be degrees or radians, so I just took a really large range :slight_smile:

Somehow this switch item never switches to on, so I have no idea what is wrong.
(the astro thing works fine, the scale transformation is installed)

For now I have moved to using a rule to control a similar item, but I would prefer to get this working with the scale transform.

I am probably doing something wrong, but I have no idea what.
Any ideas on how to make a switch item work this way?

Eric

I don’t think SCALE currently handles non-numeric parameters nor offers a default.
You should be able to use a JS

So instead of using a Switch item I could use a number Item?
I mean that if a facade is irradiated the number becomes 1 and 0 if not irradiated (instead of ON/OFF)?
Then I can still trigger a rule on value changed, right?
Thanks for the pointer.

Update:
Hmm, also strange behaviour:
item definition is now:

Number SunOnSouthFacade “Southfacade lit: [SCALE(sunOnSouthFacade.scale):%s]” (GF_Kitchen) {channel=“astro:sun:local:position#azimuth”, profile=“transform:SCALE”,function=“sunOnSouthFacade.scale”}

and the scale file contains:

[150…330]=1
[…]=0

This shows the proper 0 or 1 value in the ui, but the state value of the item is not transformed and contains the raw azimuth value.

I don’t think the profile/function parameters are handled in the way I was expecting.

Eric

Syntax is wrong. The profile goes with the channel

{channel="astro:sun:local:position#azimuth" [profile="transform:SCALE", function="sunOnSouthFacade.scale"] }

According to documentation, the syntax is wrong for NaN, you should use :

[0-1000]=ON
NaN=OFF
[…]=OFF
1 Like

SCALE has got more useful since I last looked.
Thankyou, developers :smiley:

Thanks, I should really read the documentation more carefully.
Unfortunately none if this works for me.
The NaN entry is not accepted as valid syntax (With or without square brackets around the NaN entry, the log shows:

Scale transform file ‘/etc/openhab2/transform/sunOnWestFacade.scale’ does not comply with syntax for entry : ‘NaN’, ‘0’

And the only place where I can get the scale transform to work is on the display side:

Number SunOnWestFacade “Westfacade lit: [SCALE(sunOnWestFacade.scale):%s]” (GF_Kitchen) {channel=“astro:sun:local:position#azimuth”}

with a transform file without a NaN entry (should be fine, this channels only produces proper numbers anyway)

Eric

It’s new. What OH version do you run? Top right of documentation is a version selector. NaN does not appear in v2.4 docs.

SCALE like all transforms produces string output. I would have thought that could get auto-parsed into a Number Item, but maybe not ; try a String type.

I’m running the 2.5.0 snapshot release(I have elero roller-shutters which are not yet in the stable release). Not sure what that means for the scale transform.
But… using a string type seems to work THANK YOU!
I have to test a bit more though (it’ll have to wait though, not much time the coming days :frowning:) to see how to use it in my rules, but this is beginning to look good :smile:

It’s a shame if the profile is limited to String types, considering its a numeric function really.
Looks like no-fix for OH2