Is there a 'reset' command available in the API?

[johanjongsma]

Thanks, Johan

[sbidy]

No, I don't saw something like a reset trigger.

[vodovozovge]

WiZ Dev here
There is a reset command in the API available, but since the bulb is paired to the mobile APP -- lamp will reject such config changes coming from the UDP.

btw, @sbidy if you have questions about the API or module name mapping (ESP01_SHDW_01 etc), let me know. Would be glad to help

[sbidy]

Hey @vodovozovge thank you for the support. Cool to see somebody from WiZ here 😉.
I'm currently do a "reverse engineering" on one of the bulbs firmware to get the possible UDP API interactions.
This integration for Home Assistant is using my pywizlight library to control the light via UDP. I saw a "reset" and "reboot" method for the the UDP interface but good to know that this will be rejected in some cases.
I'm not shure what exactly @johanjongsma means with reset - reset the config or reset/reboot the light controller. But both will be integrated into the library.

A little bit off-topic of that issue but I've one question regarding the UDP API:
I saw a getUserConfig method in the UDP stack - this will return all use specific parameters like user defined kelvin values and (for me important) the value of the dim-in and dim-out speed. Is it possible to set this values with the setUserConfig to provide a possibility to change these values? I try it with different (fuzzed) parameters but I will always get a Invalid Request error. So maybe can you bring some light into that for me 😄 ...

[vodovozovge]

@sbidy you're right, we have both reset and reboot commands :)
reset -- cleans up the bulb, restoring factory defaults
reboot -- simply reboots it, for example to apply new firmware

Regarding setUserConfig:
actually the name of the method is misleading. It actually sets both the values user can configure, like fadeIn and fadeOut and values that come as a confiuration for the model.

You cannot apply them as they are considered "config", so meant to be sent through the cloud only. Hence the error you're receiving.

Listing below some of the parameter names, so you can skip the step with guessing ;) :

User defined params:

• fadeIn – speed of fade in when switching the lamp with app or remote, specified in milliseconds
• fadeOut – speed of fade out when switching the lamp with app or remote, specified in milliseconds
• dftDim – default brightness when the lamp physically turns on with WiZclick (value ranging from 10 to 100, default being 100)
• startupMode – defines how the lamp behaves when starting up after being physically powered on, must take one of the following values :
  * wizclick : rotates between favScene1 and favScene2 with multiple hard on/off, enabled by default
  * lastStatus : reverts to the settings before the lamp was turned off
  * default : uses favScene1

Model configuration params:

• pwmRange – Array that contains minimum and maximum supported PWM ratios
  values range from 0 to 100 (default for WiZ is [0, 100])
• whiteRange – the temperature in Kelvin for the native warm white and cool white
  values (default for WiZ is [2700, 6500])
• extRange – the temperature in Kelvin for the extended warm white and cool white where red and blue needs to be added

[sbidy]

Thank you for the (insider) info 😄 !!!

[vodovozovge]

a bit of an offtopic too,
Small comment about the registration method

# Note: The IP and address we give the bulb here don't seem to matter for our
# intents and purposes, so they're hardcoded to technically valid dummy data.
# Fix for async problems if boardcast_registration is called twice! See #13.
# dirty dirty hack

the idea behind registration is to well, "register" ip address of the phone on the bulb, so the bulb will deliver unicast messages to it. So if you specify the correct IP the bulb will send the updates there.

You correctly mentioned that the bulb will send "heartbeat" messages, but it will also send the syncPilot message whenever the state was changed (like piloting happened). We use it to update the UI in the app reactively when the status changes. I'm not sure if it is possible to use in HA, not familiar with its architecture

One important thing to note is that the bulb will stop reporting the status after 20-something seconds unless the phone replies with ack message to the bulb. Something like:
{"method":"syncPilot","env":"pro","result":{"mac":"5ccf7f09615c"}}
where mac is the same as you used during the registration.
The reasoning behind is that the phones can come and go and there is no need for the bulb to send updates when nobody is listening

btw, awesome job with the reverse engineering of the protocol 👍

[johanjongsma]

Hi Guys, I asked the question about reset, as I had many lights connected to the wrong Home IDs. I already resetted them all manually, so the command is no longer needed.

On another note: there is "something wrong" when setting a color and then change back to white by setting a Kelvin temperature. If you do so, the light still reports it is in red, although it is in reality white. I can't tell if this is in the API or in the light itself.

Lastly, a feature request: I would like to change the color temperature 30 minutes before sunset (from 3500 to 3200/3000), REGARDLESS if they are switched on. So, to set a color temperature, without switching the light on. How could that be done? Of course, it would also be nice to use such a feature to set other parameters, such as delay.

All the best, Johan

@vodovozovge @sbidy

[vodovozovge]

On another note: there is "something wrong" when setting a color and then change back to white by setting a Kelvin temperature. If you do so, the light still reports it is in red, although it is in reality white. I can't tell if this is in the API or in the light itself.

did a brief check on the messages coming from the bulb -- it indeed reports correct value.
Though the bulb will not report r=0 when changing the CCT, color track values will be omitted. Probably that could cause the issue

For example:
Setting color:
{"method":"syncPilot","env":"pro","params":{"mac":"a8bb500111e2","rssi":-58,"src":"udp","state":true,"sceneId":0,"r":255,"g":0,"b":0,"c":0,"w":0,"dimming":93}}

Setting CCT:
{"method":"syncPilot","env":"pro","params":{"mac":"a8bb500111e2","rssi":-58,"src":"udp","state":true,"sceneId":0,"temp":2550,"dimming":93}

Lastly, a feature request: I would like to change the color temperature 30 minutes before sunset (from 3500 to 3200/3000), REGARDLESS if they are switched on. So, to set a color temperature, without switching the light on. How could that be done? Of course, it would also be nice to use such a feature to set other parameters, such as delay.

There is a method in the protocol that does exactly that -- setState. Parameters are similar to what setPilot has:
{"method":"setState","params":{"temp":3200}}
The difference is that applying setState does not turn the bulb on (unless "state":true is passed). The bulb will record the value and apply it when switching on later.

[sbidy]

Added some of the features with a6df093

I'm not sure about the problem with the color reporting after change the kelvin value.
But I think this is by design because of the missing color parameters (r, g, b ,w, c) in the return state of the bulb (as @vodovozovge mentioned) So you talking about the color wheel in HASS ? This will not change to "white" if you set the kelvin. It will stay at the "last color" until you change these. To possible fix this I should transfer the kelvin to a RGB value to set the color wheel to the "correct" color. May I have a look into that in the future.

I close the issue because the reset is implemented 😉

Thank you for the feedback!!

(@vodovozovge thanks you ... again 😆 )

[ChrisLizon]

@vodovozovge I just want to say that I think it's totally awesome that you not only took interest in this open source project, but you also shared so much knowledge with the community. I have a feeling there will be a bunch more WiZ products in my future!

Is there a reason why one would use setPilot over setState and vice versa? If setState can be used with "state":true I would imagine it could make setPilot redundant? I might be missing something.

Is there anything in the protocol that would allow a transition speed to be passed with setPilot (or setState?) for example if I change the color from 2500Kelvin to 5000Kelvin it seems to take about 0.5s, but I would like to be able to make the transition slower. Much like @johanjongsma I am using my bulbs for circadian lighting situations and that transition would make the effect smoother.

Cheers!

[vodovozovge]

@vodovozovge I just want to say that I think it's totally awesome that you not only took interest in this open source project, but you also shared so much knowledge with the community. I have a feeling there will be a bunch more WiZ products in my future!

@ChrisLizon thank you!

Is there a reason why one would use setPilot over setState and vice versa? If setState can be used with "state":true I would imagine it could make setPilot redundant? I might be missing something.

let me dive a bit into the history of how it all evolved. Back in the days one of the main ways of controlling WiZ bulbs was IR remote control (it's replaced now by WiFi one). It had 4 buttons - to trigger favorite modes saved on the lights. Internally it was like -- received scene id from the IR -> turn on the light and switch to that scene.

SetPilot was implemented mimicking the behavior of remote control. Sending scene id (or CCT, or color) triggers turning on the bulb. And it's not the only side effect of setPilot. For example, consider the following sequence:

1. Light was in Ocean
2. Switch to Night Light
3. Turn off using the remote control (or app)
4. Turn on
   After step 4 the light will turn on to ocean, and not to night light. Reasons? Because that's how the remote control works. We have separate button for the night light and generally assume that when the user presses ON on the remote -- they would like to get back to the original light mode.

To tackle that (and to better support scenes) we introduced side-effect free setState method. It's more predictable in what will happen with the light and I think there is little reason to use setPilot right now if you can pass the target state of the light.

Is there anything in the protocol that would allow a transition speed to be passed with setPilot (or setState?)

unfortunately no. We're looking at implementing custom transition speed but it's not there yet.

A bit of technical background -- the main issue is transitioning between the color values. Power supply (LED driver) can output only certain amount of power at a time and FW should be careful to not overshoot it. Transitioning means calculating the number of steps between initial and target state and there could be situations when the amount of power will exceed the capacity of the power supply.
We were not ready to implement more complex algorithm back in the days and decided to play safe, so transitions were skipped.
Over time we advanced on the power management of LEDs in the firmware and doing transitions should be way simpler now.

[charlietomo]

@vodovozovge I would like to echo what others have said in this thread; it is great to see you taking an interest and being helpful to such projects such as this. It makes me much more likely to invest more heavily in Wiz in the future, having been burnt in the past with proprietary systems that have stopped working as advertised.

And of course thanks to @sbidy for the ongoing work on this :-)