Switch item to understand true/false

I have managed to query the state and parameters from Philips Hue devices with the HTTP Binding. All info comes back in JSON format, so the most charming way here is transformation via JSONPATH.

This works perfectly fine so far, but most of the important states have “true”/“false” values, so I have to use String items.
However, I would rather use Switch items as these items are binary Switches by definition.

Currently I have to use JavaScript transformation instead of JSONPATH.
But I would like to convert the “true” or “false” results into “ON” and “OFF”…ON THE FLY…and do it entirely via HTTP and JSONPATH.

By the way: I originally thought Switch items understand more than “ON” and “OFF” and work as some kind of Boolean type, so even “TRUE” and “FALSE” or “1” and “0” would be possible. My mistake :slight_smile:

Mapping is not a solution as the state value of the item itself is not changed with that.

Having more flexible Switch items would simplify lots of things. Contact items seem to be nothing more than Switch items accepting different values.

This is what I want to do:

Switch Hue_PIR_Dark" "Dunkel?"
  { http="<[http://<MyHueIp>/api/<MyHueKey>/sensors/22:10000:JSONPATH($.state.dark)]" }

Currently I am using JS instead, example:

Switch Hue_PIR_Dark" "Dunkel?"
  { http="<[http://<MyHueIp>/api/<MyHueKey>/sensors/22:10000:JS(getHuePirDark.js)]" }

Is there a way to achieve my goal without JavaScript? For example, multiple “nested” transformations in the HTTP query? - Thanks in advance!

If you cannot change the value of the JSON payload, I suggest you use proxy items:

Cannot be done. You have to either use JavaScript or a Proxy Item and Rule like Lucky suggests.

Not entirely accurate. Contact Items are “read only” in a way. Contacts are intended to be used for binary sensors and if I’m not mistaken you will receive an error if you try to send command to a Contact.

Though feel free to create feature request issues on the Eclipse Smarthome Github if you find these features important enough.

Personally, I can see a lot of advantages in being able to have Switch and Contact be more flexible in the sort of data they will accept (e.g. true/false, TRUE/FALSE, T/F, 0/1, On/Off, on/off, etc.)

I also personally would like to see an overhaul of the transformation system to pull the implementation out of the bindings and make them generically applicable across all bindings. As part of that would be the ability to chain transformations. But this would be a HUGE change so I’m not holding my breath. I’m not in a place where I can work on it so I haven’t filed the issue myself.

But in the short run, handling a situation like this is what the JavaScript Transform is for.

Yes, sure, Contact vs. Switch is clear and I already accepted the current situation, so JavaScript will be the way to go until either acceptance for other values in item types is widened, or nested/chained transformations will be possible.

Proxy items + rules is a no brainer as I would have to create lots of them for every single item to handle - if I’m not mistaken there is no one-for-all approach possible. JS with variable input is more flexible, so I will stay with this solution.

Eventually I will create a feature request. The more I think about it, the more likely it is :slight_smile:

However, thanks so far for clearing things up!

By the way: What would be the best way for creating a feature request?
As far as I know a Pull Request on GitHub is more for contributing…

Can someone point me to the proper place, please?

There are tons of approaches to achieve this with one rule, depending on the specifics and details of course. If you find yourself making lots of rules with the same code there is always a way to consolidate. Look at the Design Pattern postings to get started or you can post your code and I cna make suggestions.

This is probably the right solution, despite what I said above about Rules.

Open an Issue and mention that it is a feature request in the Issue. Please do search to make sure there isn’t already an issue open.

PRs are indeed to be used when you have actually made the changes and want those changes added to the baseline.

For these changes the correct place would be https://github.com/eclipse/smarthome/issues