Nightmode does not work

[bombcheck]

Using some RGBW-Bulbs (FUT016) with my own switching-app (with the milight-php-api). Nightmode does work as expected with the original bridges. But using this milight hub, the bulbs just turns off. Tried latest v1.6-dev-release and the 1.5.0 stable.

Any idea?

[bombcheck]

Nobody with this problem? Using the udp gateway-server-function to spoof my old brige-ids. No night mode. :( And sometimes, if I toggle a group, some other group with the same bridge id gets toggled, too...

Regards

[bombcheck]

Just reviewed the dev-page at limitlessled and my implementation of the php-api: Commands are as follows (for RGBW): NIGHT MODE ALL: 0x41 / Wait 100ms then: 0xC1 NIGHT MODE GROUP 1: 0x46 / Wait 100ms then: 0xC6 NIGHT MODE GROUP 2: 0x48 / Wait 100ms then: 0xC8 NIGHT MODE GROUP 3: 0x4A / Wait 100ms then: 0xCA NIGHT MODE GROUP 4: 0x4C / Wait 100ms then: 0xCC

Basically it is a OFF-command followed by a second long-press-OFF-command.

[bombcheck]

Checked V5MiLightUdpServer.h: Is this where the commands the virtual gateway server reacts to are defined? OFF-commands are defined here, but the NIGHT-commands are missing...

[sidoh]

I probably won't have time to look at this for another week or so.

If you want to take a crack yourself:

• You already found where the UDP command ID is found. Would need to add it.
• Command handler is the source file for that header, V5MiLightUdpServer.cpp

If night mode is not working from the REST API either (via PUTting {"command":"night_mode"}), there's likely an error in the RF packet formatter as well:

https://github.com/sidoh/esp8266_milight_hub/blob/master/lib/MiLight/RgbwPacketFormatter.cpp

[bombcheck]

Maybe I can have a look at this when I get the time... But would be great to see you working on this, too. :) Any ideas on this: "And sometimes, if I toggle a group, some other group with the same bridge id gets toggled, too..."

[sidoh]

Eventually. Hopefully it's obvious this is a for-fun spare time project. :)

Nothing offhand. Please try to find a consistent way to reproduce it.

[sidoh]

Actually there was a sort of similar issue ( ~#25~ #98 ). Might be something similar for the UDP servers.

Edit - had the wrong ticket.

[bombcheck]

Just checked out the code: RgbwPacketFormatter.h is not included in V5MiLightUdpServer.cpp Is that correct?

Sniffing the packets of my rgbw remote from the web gui show me a rgbw and a cct packet for each key press. Correct?

[sidoh]

Yeah, those two have different responsibilities. PacketFormatter is responsible for formatting and buffering the RF commands sent to the bulbs given semantic function calls like enableNightmode(). The latter essentially translates UDP packets into calls to the appropriate PacketFormatter (through MiLightClient).

The RGBW packet formatter looks like it's supposed to be supporting night mode. I think a good place to start might be checking if that's working. The easiest way to test is via the REST API, e.g.:

curl -vvv -X PUT -d '{"command":"night_mode"}' milight-hub.local/gateways/0x0000/rgbw/1

If this isn't working, the RF formatter has an error of some sort, and it'd be super helpful if you could figure out what's different about the packets your remote is sending.

I've not seen remotes that send two types of packets before, but it doesn't shock me. My guess is that bulbs only pair with one, though.

I will take a look at this sometime in the near future. Haven't had much free time recently.

[bombcheck]

OK. Will check die REST API later. Forked the project and will have a look at the codes for night mode. Already added some stuff and getting used to platform.io. :)

[bombcheck]

Damn, my build throws an exeption and the esp restarts when trying to send a command. Sniffing works, but when I try to send via API or Web-GUI it crashes. Flashed your pre-compiled DEV8-Image. Night mode via REST API does not work: Often the bulb does not react to any command (on/off and so on). When trying the night mode, the bulb just turns on to white.

[bombcheck]

No luck on building my own firmware. Default Atom/Platform.io setup. Thought that it could be an issue with my modifications, so I tried your code. Master and v1.6.0 branch compiles and runs, but crashes as soon as I send a command. Flashing your pre-compiled v1.6.0-dev8 image does not crash. Strange... :(

[sidoh]

Are you on a Windows machine? I'm quite sure there's some super bizarre behavior with whatever compiler pio pulls in under Windows (see #109).

I think I had found something that fixes it (at least according to another Windows user -- see this comment), but it's totally unclear to me why that fixes it. Not had the time to dig more into it. But if you just want to iterate, you should be able to apply that diff.

[bombcheck]

Yes Windows 8/Windows 10. How can I apply your fix?

[sidoh]

Instructions should be in the comment I linked:

https://github.com/sidoh/esp8266_milight_hub/issues/109#issuecomment-335016939

Just a one-line change in platformio.ini.

[bombcheck]

Ahhhh ok. Looked at the commit and trying to locate the library file. :D That seems to fix it... Noticed that an your master branch, sniffed packets from the remote always show up as "rgbw", while on the v1.6.0 branch they hop between "cct" and "rgbw"...

[sidoh]

Huh, that's interesting. Can you paste a capture from the v1.6.0 branch?

[bombcheck]

OK let me see... The fix for compiling under windows works perfect. Have no remote at home, just my bridges. Got this packets sniffed;

Turning off a bulb:

rgbw packet received (7 bytes):
Request type  : B8
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 0A
Sequence Num. : 08

rgbw packet received (7 bytes):
Request type  : B8
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 0A
Sequence Num. : 03

Turning on, setting brightness and color:

cct packet received (7 bytes):
Request type  : B8
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 0E
Sequence Num. : A0

rgbw packet received (7 bytes):
Request type  : B8
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 0E
Sequence Num. : 9C

rgbw packet received (7 bytes):
Request type  : B8
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 0E
Sequence Num. : 99

cct packet received (7 bytes):
Request type  : B8
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 09
Sequence Num. : 95

rgbw packet received (7 bytes):
Request type  : B8
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 09
Sequence Num. : 91

cct packet received (7 bytes):
Request type  : B8
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 09
Sequence Num. : 8E

rgbw packet received (7 bytes):
Request type  : B0
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 0F
Sequence Num. : 88

cct packet received (7 bytes):
Request type  : B0
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 0F
Sequence Num. : 84

rgbw packet received (7 bytes):
Request type  : B8
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 09
Sequence Num. : 82

rgbw packet received (7 bytes):
Request type  : B8
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 09
Sequence Num. : 7E

cct packet received (7 bytes):
Request type  : B8
Device ID     : 932D
b1            : F6
b2            : BC
b3            : 09
Sequence Num. : 7B

Strange: Seems to no always happen: Got a capture where all packets from my "on"-sequence where labeled as "rgbw"...

[bombcheck]

Some minor progress on the night mode issue: I added the necessary codes and catches for the night mode here: https://github.com/bombcheck/esp8266_milight_hub/commit/aa5ff7dc6523758a5e97c57f51c20029fe9a485c

They work: When I send a night mode command via my php api to the esp, I get the corresponding serial printout. But the reaction on the bulb is the same as when night mode is engaged via the REST API: The bulb just turns on,

[bombcheck]

Better use this commit: https://github.com/bombcheck/esp8266_milight_hub/commit/8b27a6447855877a8b211abd2d7a0b6760279f7a Debug output is formatted better...

Night command is recognized correctly... If bulb is on, it turns off and immediately back on again. Now we have to fix the packet formatter... :)

[bombcheck]

Is far as I can tell, we just need to send out the proper button code to enter night mode (a long "OFF" press of the corresponding group master switches):

0x12, # Night mode all 0x14, # Night mode group 1 0x16, # Night mode group 2 0x18, # Night mode group 3 0x1A, # Night mode group 4

[bombcheck]

But why is in "V5MiLightUdpServer.cpp" only the "CctPacketFormatter.h" included? We are also talking to RGBW bulbs there, so we should have/use "RgbwPacketFormatter.cpp", too. Or am I missing something?

[sidoh]

Awesome! Won't have time to look at this closely for a bit, but seems like you're getting it figured out. :)

V5MiLightUdpServer includes CctPacketFormatter directly because it uses a couple of static helper methods, e.g., CctPacketFormatter::cctCommandIdToGroup. The other packet formatters are used via the MiLightClient instance.

[bombcheck]

Ah OK... So client->enableNightMode(); uses the RgbwPacketFormatter?

[bombcheck]

OK... Added button codes for RGBW night mode into "RgbwPacketFormatter.h". And changed enableNightMode() accordingly. See https://github.com/bombcheck/esp8266_milight_hub/commit/35c8a562029d4b7bdf521edfcf43db6f1ae545d1

A "dry run" with a local version of my php api produces the debug output I was expecting. Will test with a real bulb this evening.

[bombcheck]

No luck... Bulb just turns off when engaging night mode. And setting white mode when turned on does not work any more. Must have broken something...

[bombcheck]

AH I GET IT: The OFF-command is NOT neccessary before sending the LONG OFF-press button code. Nightmode fixed for RGBW-bulbs! https://github.com/bombcheck/esp8266_milight_hub/commit/735a6cb1e373930622b3dc7f89b690d798b61c8c

[sidoh]

That's great! Whenever you're ready, open a pull request. Should have time to look at it this weekend.

[bombcheck]

OK, just checking some things and removing debug stuff (floods the serial output)...

[bombcheck]

Have to look at the REST API: Night mode does work from there, but need two calls. When the bulb is off, a single PUT of {"command":"night_mode"} is enough. But when it is on, it just turns off. A second PUT then triggers night mode. Where are the commands of the API are processed in the code?

[sidoh]

That's probably why the packet formatter was sending the OFF command.

It's here:

https://github.com/sidoh/esp8266_milight_hub/blob/state_persistence/lib/MiLight/MiLightClient.cpp#L337

JSON received via MQTT is pushed through the same code path.

By the way - make sure you're developing against the state_persistence branch. There are a bunch of big changes in there that might cause conflicts.

[bombcheck]

Damn, was working against the v1.6.0 branch. Will check that.

[bombcheck]

OK, nothing in state_persistence that prevents me from merging my changes. :)

Strange that night mode via upd server works on first command in every mode the bulb is in, but does not from the REST API...

[sidoh]

Most of the bigger structural changes were in v1.6.0, so it shouldn't be too bad. Sorry, should've thought to mention that earlier. Glad it's not giving you trouble.

That is strange. Have you tried running it with sniffing (in the UI) enabled? All sent packets should show up there.

[bombcheck]

It can sniff its own packets? :)

[sidoh]

Well, kind of. Sent packets are pushed through the same handler that intercepted packets are. So they show up in the same way.

[bombcheck]

Fighting with the config ap. Keeps disappearing...

[bombcheck]

OK, must be a bad settings blob... No packets "sniffed" when using the REST API...

[bombcheck]

OK, API gives me a bad request error. Strange...

[sidoh]

What command are you running? It definitely works for me, and I see it sending the two RF packets I'd expect.

[bombcheck]

{"status":"on"} works. {"command":"night_mode"} gives me a bad request error,.

[bombcheck]

But it worked from home (linux). Just have windows here at work...

[bombcheck]

Strange, it works well on my Mac. Must be an issues windows-curl... Tried night_mode via REST API and UDP-Server: Packets are the same. But I get no serial output when using the REST API. So there must be used a different routine...

EDIT: Forget about the last sentence. When using the PHP API with the UDP gateway, enableNightMode() is triggered 5 times. But only one time when using the REST API.

[bombcheck]

PHP api sends commands a few times. Maybe the REST API should do this, too?

[bombcheck]

Pull request created. :)

[sidoh]

Awesome!

re: repeats, packets are repeated 30 (I think?) times by default, but it's the same RF packet, so it's deduplicated. There actually is a setting to multiply the number of repeat packets for HTTP requests by some factor because of this:

I don't use the UDP protocol, though, so it's just set to 1 for me.

[bombcheck]

Experimented with packet repeats, of course. Small values give unreliable switching experiences with the bulbs. But to high values make cascading switch commands (in macros for example) slow.

I think we can close this one as the night mode has been fixed with the merge of #139

[bombcheck]

It seems it still does not work properly. Can anybody confirm? I made all changes to the "old" v1.6.0-branch (before sidoh merged state_persistence into it). I merged my changes into state_persistence, but it seems they do not actually work. I have to confess that I always compiled v1.6.0. I just tried to merge state_persistence into v1.6.0 of my fork. Works, but night mode is broken again. And bulbs do respond seconds after I issued the command via udp server.

[sidoh]

Hm... yeah. Didn't actually test this myself. Just did, and can confirm that night mode is not working.

Is there a revision that does work for you? Just tried checking out b488c03b1ef6ae4a253c28e29bababd246725cf4, but it's not working with my RGBW bulbs.

[bombcheck]

Yeah the whole state_persistence-branch seems to have this issue with night mode ongoing. I was always working and compiling v1.6.0-branch (forked before you merged state_persistence into it). It still works great there. But as soon as I merge state_persistence into it (which works flawlessly), the whole thing is broken again. :(