HSBtype, did something happen from OH2.0 to 2.3

Setup, Configuration and Use Scripts & Rules
1

I just upgraded to Oh2.3 and my rules now throws error for the HSBType.toString() methods:

 2018-08-09 19:52:22.508 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Change the scene in Master Bedroom': cannot invoke method public java.lang.String org.eclipse.smarthome.core.library.types.HSBType.toString() on null

My rule is as follow:

//OFF
		case 1: {
		    hsbValueMasterBedRoom = HSBType::fromRGB(0, 0, 0)
		    Group_DMX_MasterBedRoom.members.forEach[l|l.sendCommand(hsbValueMasterBedRoom.toString())]	
		    Dimmer_MasterBedRoom.sendCommand(0)
		}
		//ON
		case 2:{
		    hsbValueMasterBedRoom = HSBType::fromRGB(255, 255, 255)
			//hsbValueMasterBedRoom=Color_MasterBedRoom.state as HSBType
		    rgbLights.apply(Group_DMX_MasterBedRoom,Group_DMX_MasterBedRoom,hsbValueMasterBedRoom)
		    Dimmer_MasterBedRoom.sendCommand(80)
		}
		//NIGHT
		case 3:{
		    hsbValueMasterBedRoom = HSBType::fromRGB(50, 0, 10)
			//hsbValueMasterBedRoom=Color_MasterBedRoom.state as HSBType
		    rgbLights.apply(Group_DMX_MasterBedRoom,Group_DMX_MasterBedRoom,hsbValueMasterBedRoom)
		    Dimmer_MasterBedRoom.sendCommand(60)
		}
		//READING
		case 4:{
		    hsbValueMasterBedRoom = HSBType::fromRGB(255, 204, 51)
		    rgbLights.apply(Group_DMX_MasterBedRoom,Group_MasterBedRoom_Reading,hsbValueMasterBedRoom)
		    Dimmer_MasterBedRoom.sendCommand(100)
		}

I assume this is not vaild anymore in OH2.3

hsbValueMasterBedRoom=HSBType::fromRGB(255, 204, 51)

where

var HSBType hsbValueMasterBedRoom

is defined at the top of the rule. SO how can i rewrite it to get it to work under OH2.3?

2

Do you only see this error at oh startup or reload of the .rules file? If so it’s a known problem. It seems rules start executing before oh is ready for them and all sorts of things that are perfectly normal and standard generate unknown symbol exceptions. Once things settle everything works as normal

As far as I know, the code you have is perfectly acceptable.

3

Yeah, I think I’ve hit that at some stage, too. Not sure when that changed, I vaguely recall there were some posts or something in the release notes that made me aware of it. Either way, I had to recode, too.
Now using

val String value="255,204,51"
hsbValueMasterBedRoom=new HSBType(value)
item.sendCommand(hsbValueMasterBedRoom)

(yes, you can likely combine that into one line as well).

4

Seems like that are hsbvalues, and not rgb converted to hsb value, however I think the problem is somewhere else:.

it seems like it might be the lambda function that’s the issue:

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////// Switch the different areas where LED-Lights should be switched on/off ////////////////7////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////

 val Functions.Function3 rgbLights= [ GroupItem mainGroup,GroupItem subGroup, HSBType hsbValueIn |
	mainGroup.members.filter[l|l.state.toString != hsbOff.toString].forEach[l| l.sendCommand(hsbOff.toString()) ]
	subGroup.members.forEach[l2|l2.sendCommand(hsbValueIn.toString())]	
]
5

Yes, sorry.
Check out if this works for RGB to HSB.

6

Found where I had read about it: the OH1 migration docs state this and offer an alternative.

7

Ok, its working now. However I do get some warnings about the lambda being of the wrong format, in OH2.3.
I also read something about that looping in groups are now easier in OH2.3. So I guess its time for rewrite the lambda. @rlkoshak do you have any tips on this?

So the pseudo code would be something like this

lambdaFunction lights(mainGroup,subGroup,Optional hsbValue){

if light in subGroup is off then turn on to color, or dimmig value specified by hsbValue), 
if its already on, then just change to correct dimming value and color.
all other lights in maingroup switch off

}

Light can be Dimmer,switch and Color, any other light types exist?

8

Out of the top of my head (thus untested), I think your lambda’s first line (to not throw warnings in 2.3) would need to look something like

val Functions$Function3 <Group,Group,hsbValue,Number> lights = [ mainGroup,subGroup,hsbValueIn |

Not sure if you can make the 3rd parameter optional, but of course you can call it with a dummy.

9

Somewhere in 2.3 something changed and we can now go back to the simpler:

val lights = [ Group mainGroup, Group subGroup, HSBType hsbValue |
    // code goes here
]

The language interpreter will be smart enough to tell the difference between a Functions and a Procedures based on the value of the last line executed. And you don’t need the import statement any more or to mess with all that messy stuff with the $ and < >. And most importantly, no more warnings in the logs.

There are no changes in 2.3 that I’m aware of regarding looping through Groups. All the same filter and forEach and such methods are still there and unchanged.

What do you want to achieve with the optional third argument? Your pseudocode requires it and you do not indicate what your default value for hsbValue would be when it is not supplied. What should it do with Switches and Dimmers? Your pseudo code doesn’t say.

Some things to note:

  • Switches can receive ON/OFF commands only
  • Dimmers can receive ON/OFF and PercentType commands
  • Colors can receive ON/OFF, PrecentType, and HSBType commands
  • You can get the state from, for example, a Color Item as an ON/OFF using MyColorLight.getStateAs(OnOffType)
  • You can get a list of the names of all the Groups an Item directly belongs to using MyItem.getGroupNames (I think that’s it, I may be remembering the name of the method wrong, it should show up in VSCode)