New Color Setting trait: Formatting thoughts

#1

Hi everyone,

I’m currently working on a new trait to support setting the color of light bulbs. It consists of two features:

Optionally, the “color temperature” feature could be activated. You set user defined upper and lower constraints in kelvin. The value in kelvin will be published and received from own topics.

The other feature is setting the actual color in RGB. However, I’m unsure how the value for the MQTT topic could be formatted. I’ve got a couple of ideas there:

  • Plain hex code, e.g. FFFF00 for yellow
  • Somehow formatting each color codes and using decimal numbers, like the message R: 255 G: 255 B: 0
  • JSON formatting the data inside the mqtt payload. I rather like this idea, because both a wide variety of formats (like individual color codes, hex representation and maybe HSV) and even the textual representation of the color the user asked for could be integrated. I image something like {"red": 255, "green": 255, "blue": 0, "requested": "yellow", "hex": "FFFF00"}

What do you guys think? Any ideas or suggestions? What would be the easiest to integrate for you?

1 Like

#2

I agree that the JSON idea sounds nice. It is certainly the most flexible. My RGB bulbs use a hex color code, but others likely use other formats, so it would be nice to include various formats in one JSON payload.

If we wanted to set the remote status of the bulb by publishing to the /set endpoint, I suppose we would we have to construct a JSON object in the same format and publish that. That sounds like it would work.

Looking forward to this feature!

0 Likes

#3

Json is the most flexible and holds the most data.
Are you putting the color and the color temperature in the same mqtt topic?
Maybe ist better to split them into 2 separate topics…

0 Likes

#4

Any update on this feature?
I’m looking forward to saying ‘set mood lighting to red’ !
Thanks

1 Like

#5

Yup, next week :wink:

I’ve decided to add two different kind of traits you can choose for the device: One sends data as RGB in RRGGBB suiting for most systems and another one sending the JSON data for more powerful systems

0 Likes

#6

That’s great! Thanks Peter.
I use esp8266’s connected to neopixel strips with an mqtt interface through node-red so hopefully I can control them in this way. :slight_smile:

0 Likes

#7

What about the color temperature?

0 Likes

#8

Any updates on the color trait?

0 Likes

#9

Yup, it has been deployed just now.

The update was actually planned for the end of last week, but I had to reconsider my schedules because of unforeseen problems. Sorry for that…

1 Like

#10

Great…

Is it definitely working for everyone? I created a device initially with RGB and sync my devices. But I dont have the color option in the Google Home interface. So I added the TEMP and JSON options and re-sync but still dont get an option showing like other COLOR lights.

0 Likes

#11

I guess, @peter implemented the ‘new’ ColorSetting trait.
I can confirm that the Google Home app color picker works with the deprecated ColorSpectrum trait.

@Peter, is it possible to add the min and max color temperature to the trait settings?
@Peter, is it possible to implement HSV to? maybe with a setting in the trait?

0 Likes

#12

Having the same problem. Color option is not showing up in Google home app.

0 Likes

#13

I appreciate all the work gone into this @peter
Will there be any documentation as I’m struggling to get this to work.

0 Likes

#14

Devices using the “ColorSetting” trait can’t be controlled via the Google Home app, only using voice commands (as @Aart already pointed out).

I’m a bit disappointed with Google’s work here. They forced everyone to use their new “ColorSetting” trait (instead of the ColorSpectrum) - but they don’t implement it properly in their own app. They have been promising to add a whole lot of new traits for almost half a year, but nothing happened there either.

Documentation is going to come soon

0 Likes

#15

Quick question :slight_smile:

I already pulled the new docker images. But i want to keep my existing DB :slight_smile:

How to start partial migration ?? Start “docker-compose exec web php artisan migrate” ?

BTW i didnt see following files inside docker image:

2019_03_23_182751_add_loginusername_column.php|API V2, Trait “ColorSetting”|15 days ago|
2019_03_23_184412_create_api_key_table.php|API V2, Trait “ColorSetting”|15 days ago|
2019_03_24_095707_add_colorsetting_trait_type.php|API V2, Trait “ColorSetting”|15 days ago|

0 Likes

#16

I’m unsure why the files are missing… gonna check that.

You can safely run the migration, since it is incremental. The script compares the newest available database scheme with your current one and only makes the necessary adjustments

0 Likes

#17

Did you have a look ?
On the arm32v6, I’ve updated to the last image but the content seems to be the previous one.

0 Likes

#18

I’ve restarted the build of the containers (https://travis-ci.org/kservices/gBridge-docker-arm32v6).

Let’s see whether this changes something (if there only was a caching issue or something alike).

0 Likes

#19

The build is done now. Could you be that kind and check this for me? I currently only have my smartphone at hand.

0 Likes

#20

Same result. Maybe there is something I’m doing wrong.
I’ve made a pull, the downloads and extracts are ok.
Stop all the container, ask for up, new images are created.

When I’m looking inside, I see some files and folders from the 28/03 but not all the updated ones for the color traits. Another example, in the migration folder, the last files are from the 2019_01_10.

0 Likes