Windows Support?

[g2bb]

Is there any plan for Windows support, or even better support for something like a Rasberry Pi so that they could be made into Wifi appliances with something like Home Assistant so I could control it with Google Assistant or Alexa?

[g2bb]

Or could you link to where you found how to control it and I could look into it

[keefo]

Unfortunately, I don't code on Windows or Rasberry Pi. If you do feel free to convert it to a Windows app. The core logic is in the NeewerLight.swift file.

[g2bb]

Thanks, I'll have a look into it, if I make something I'll upload it to Github and credit you!

[dreyes15]

I wonder if writing it in Java or another language that is cross platform would work a bit better...g2bb let me know as I am pretty interested in this also

[g2bb]

Let me guess you also got them on Prime Day? I

In seriousness though I haven't had the chance to start any development yet, I was hoping to set up a docker container for it. I'm want to set up a raspberry pi that I can connect to a digital assistant (I prefer Google assistance but theoretically it could be made to work with Alexa or Siri)

Programming not really my forte, I mostly just do web development, but I'd love to make this cross platform so if you're want to help, or even head that up I will help in any way I can!

[fribse]

I would love to see this as well, maybe as a webservice of sorts? I wonder if it could be handled by something tiny like an esp32 with bluetooth?

[taburineagle]

I just got 2 Neweer lights (ha, yes - Amazon too, but I had actual lighting needs before finding these) and was honestly wondering the same thing :) I have a nature project that would be amazingly awesome if I could find some way to control these lights when motion is detected. The motion detection I'm good on, but I came here trying to see if there was a way to control the lights remotely from a device like a Raspberry PI. I checked through the NeweerLight.swift file, and I think I understand the basics of the protocol, but there are some pieces I'm not 100% on. Using Bluetooth on the Raspberry Pi, I can see the light as a Bluetooth device (it's listed as NEWEER-SL-80), and I can see the list of services/attributes/characteristics, but could not find the right characteristics to send data to until I used the nRF Connect app (on a phone) to find the characteristic. In my case, the GUID for the characteristic is 69400002-B5A3-F393-E0A9-E50E24DCCA99 (although I'm sure that is different for different devices), and in reading the Swift file, the command sent to that characteristic works like this:

{78 86} 04 [00 00 64 64]

{prefix tag as hex} = seems to always be 0x78
{command tag. also as hex} = 0x81 for power, 0x86 for RGB mode, 0x87 for CCT mode, ??? for animation mode
length in bytes of the command = Power has 1 byte (01 for on, 02 for off), RGB mode has 4 bytes, and CCT mode has 2
[command] = this is where I'm a little confused about, at least in the RGB mode.

 CCT mode has:
       (brightness value, as hex, converted from integer range from 0 to 100)
       (color temp value, as hex, converted from integer range of 32 (3200K) to 56 (5600K))
       
  RGB mode has: (as far as I can read it) 
       (RGB value in hex, ranging from integer range 0-355?)
       (a similar value to the above, but I'm not 100% sure what the purpose of this is...?  This one I need more help on)
       (the saturation value, in hex, converted from integer range 0-100)
       (brightness value, in hex, converted from integer range 0-100)

In my testing, just sending the string of commands to the light, I haven't found a need (at least as far as communication with the light itself is concerned), for the checksum, but that might be more of a benefit for the program itself (I'm honestly relatively green with Bluetooth programming). I also haven't really found where the light's channel comes into play, as none of the commands I found take that into consideration, but that will probably be more apparent when testing commands with multiple lights. I was also wondering if when sending a command to 2 different lights, is it just sent as 2 commands, one to each light's Mac ID/characteristic, etc., one at a time, or is it sent to some group characteristic...?

[keefo]

Hi @taburineagle

Good write up.

I could explain some of the questions you had.

1. what is the code for animation mode?
2. explanation about RGB setting.
3. what is the purpose of the checksum?
4. how to set channel?
5. does it send 2 commands to 2 lights or 1 command sends to 2 lights?

1. what is the code for animation mode?

During my reverse engineering I did not find any code for animation mode. My guessing is this is a pure application logic, you could use a timer to cycle through colors and keep sending setRGBLightValues commands.

2. explanation about RGB setting.

I think the reason for your confusion is because the function name I use. It contains 'RGB' in the name, however, in the lights embedded system. It uses HSL color space. This code is dealing with HSL not RGB color space.

3. what is the purpose of the checksum?

The checksum is a thing I found in the official Android app, I just keep it there. It probably as you said for application.

4. how to set channel?

I would also like to know how to set channel. I wasn't able to find it.

5. does it send 2 commands to 2 lights or 1 command sends to 2 lights?

From application/programming level, I don't think about Bluetooth hardware interaction. When the code finds 2 lights, I should get 2 bluetooth device objects. I just need to send separate commands to this 2 device objects.

[fribse]

@taburineagle Yes, using a RPi would be awesome as well. Great initiative :-) Let me know if I can test anything, I have a RPi4 not in use and a Neewer 660 light.

[g2bb]

I'm really excited to see some movement on this. I really wish I could have done it myself, but I just don't have the coding chops for it. I'm learning Docker right now, so hopefully by the time we have a RasPi build I'll be confident enough with that to set up a docker image to deploy on different hardware.

…

On Thu, Sep 9, 2021, 4:30 PM Kenneth Fribert ***@***.***> wrote: @taburineagle <https://github.com/taburineagle> Yes, using a RPi would be awesome as well. Great initiative :-) Let me know if I can test anything, I have a RPi4 not in use and a Neewer 660 light. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADVIVWIFLIKH6DCNNKZLJWLUBERP5ANCNFSM47ECFOIA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[taburineagle]

@keefo - Thanks! And thanks for clearing some of those up! A few things I've noticed on those points,

1 - That makes sense that it could be application logic, but the lights themselves physically have the same animation modes accessible without the app - I'd assume the command wouldn't be too complex (if there actually is one), just 78, (subset) and probably 2 parameters, possibly 3, animation group (1-3), animation subset (A-C) and brightness. I don't have a setup to packet sniff the Bluetooth commands coming from the app at the moment, but if I can get something like that running myself, I'll check more into that later on.

2 - Ah, ah, got ya - what I meant was I was confused about why there were 2 bytes used for the hue setting, but I sat down and checked more into it last night, and it makes sense to me now. Ha, as insane as it sounds, I haven't done much with bit shifting (shock!), so I wasn't familiar with what the & and >> functions were doing, but I understand it now - the first byte is the H setting, up to 256, then the overflow if it's over 256 (so if the H value is 266, that byte would be the hex for 10), and the 2nd byte is whether or not there's an offset (so if the 2nd byte is 1, then add 256 to the first byte for the final value) - I do understand what the bit shifting is doing now, I've just never used that myself before now 😶

3 - Ha, on 2nd view of the checksum, I tried setting commands with a 660 PRO light, and they won't go without the checksum - so there's definitely something more to that, maybe in the later versions of the light programming (the SL-80 I was originally testing with did change modes without a checksum, but the 660 PRO does not)

4 - Yeah, that part still confuses me... that's probably one to sort out later.

5 - That's what I was thinking, just iterate through the devices - that's honestly what the app is already doing, most likely - makes sense!

@fribse - I'll definitely keep that in mind! I'm not sure how long it'll take to write something up, but I was looking at possibly doing a proof-of-concept python script and possibly using BluePy to control the light(s) - ha, I'm fairly inexperienced with Python though, so that might take a bit of time.

@g2bb - Hopefully! Eventually I want to do a VB.net program for Windows (and a Python program for the RPi) that should hopefully be able to at the very least control one light at a time, to begin with.

[keefo]

@taburineagle - You have a very interesting Youtube channel. I can totally see how you gonna use this + motion detector to film wild life during night. Cheers and Good luck.

[taburineagle]

@keefo - Thank you! Yeah, I could envision all kinds of cool lighting setups I could use with these lights and my wildlife setups. My current setup is a RPi running a Bash client script I wrote, which looks for motion, and then sends a LANC signal to a camera waiting to roll when it senses something (and a small LED light in the camera enclosure), and the RPi is sending and receiving commands from a PHP script that I also wrote, at the "home base" 6 miles away.

[taburineagle]

Slight discovery while fotzing with sending the commands to the Pi - sending "78 88 ..." goes into animation mode~! (at least on the SL-80.

(br) - brightness value from 0-100, converted to hex

78 88 01 (br) - sets the brightness (only), does not change current mode, but only if you're already in an animation mode

In fact, if you send 78, 87, 01, (br) to CCT mode, you can adjust the brightness without altering the color temp.

78 88 02 (br) 01 - sets the brightness to (br), and shows "emergency mode A" (the "police sirens")
78 88 02 (br) 02 - " ", and shoes "emergency mode B", but just stays one color?
78 88 02 (br) 03 - " ", and shows "emergency mode C", which is... ambulance? I'm not sure
78 88 02 (br) 04 - " ", and shows "party mode A", alternating colors
78 88 02 (br) 05 - " ", and shows "party mode B", same as A, but faster
78 88 02 (br) 06 - " ", and shows "party mode C", fading in and out (candle-light?)
78 88 02 (br) 07 - " ", and shows "lightning mode A"
78 88 02 (br) 08 - " ", and shows "lightning mode B"
78 88 02 (br) 09 - " ", and shows "lightning mode C"

[keefo]

@taburineagle
You are awesome. I have tested. It works on my RGB660 as well. I will add this feature ASAP.

[keefo]

@taburineagle
I have added the scene support in version 0.4.
Thank you for your investigation.
Feel free to checkout and use the code.

[taburineagle]

Ah, excellent - thanks, and you're welcome! Glad to hear it worked out. Last night, I started a VB.net program to hopefully bring most of the functionality of the project to the Windows side, so I'll keep checking in! It's very rudimentary so far, but I've already coded the HSV side (dragging the sliders computes the hex string + checksum to send to the light). I don't have Bluetooth on my Windows computer (yet - I ordered a dongle), so at the moment, it just computes the raw hex values. But testing those values with the RPi and bluetoothctl work exactly how they should, so it's a good start :)

[keefo]

I tested the python library bleak, https://github.com/hbldh/bleak It supports cross platform bluetooth functions.
It would be better to write the core with bleak and implement UI on separate platforms. WPF on windows, and Swfit UI on Mac.

[taburineagle]

That's actually pretty awesome, I didn't know that existed! I've been trying to work out the Windows Bluetooth side of things the past few days, but they're... complicated to say the least (https://docs.microsoft.com/en-us/uwp/api/windows.devices.bluetooth.genericattributeprofile?view=winrt-20348) - among the intricacies, you need to be in a very specific dev environment before even being able to implement that, you can't just import the Windows.Devices namespace normally. Bleak definitely seems like a much more manageable back-end for actually doing the communication with the lights!

[taburineagle]

I'm going to check into that, and IronPython, and designing a GUI in XAML - I've never used XAML before for layout, but it should be pretty straight-forward (hopefully...), at least using Visual Studio to lay out the initial look.

[taburineagle]

OK, after a day of (on-and-off) testing the Bleak library, I really dig it - it connects to the light perfectly, and I can send commands to it with no problem, just with the Mac address and the UUID (and I even tested it with a few loops, to see if sending multiple commands would simulate a custom animation - and they worked perfectly!) But, strangely enough - the laptop I tried it out on (Ubuntu with built-in Bluetooth) had literally no issues at all, no issues connecting, sending, etc... but the RPi I tested it out on (4B+ with 2020's version of Raspian/Pi OS) had random issues connecting to the light using the same code. It's been a while since I've run an apt upgrade on it, so I'm going to update everything on the Pi and test it again when I get a chance to, I just think that's interesting.

[taburineagle]

OK, I've rewritten the bytestring computation logic in Python, and I might actually go with a Python-based GUI, then it shouldn't need as much else to port to multiple platforms, just bleak and either PySide or Qt (or possibly Tkinter, I'm not sure which one is the best yet). 2 questions though @keefo -

Do you mind if I call the project something similar but slightly different like NeweerPyLite, and would you like a credit in the comments?

[keefo]

OK, I've rewritten the bytestring computation logic in Python, and I might actually go with a Python-based GUI, then it shouldn't need as much else to port to multiple platforms, just bleak and either PySide or Qt (or possibly Tkinter, I'm not sure which one is the best yet). 2 questions though @keefo -

Do you mind if I call the project something similar but slightly different like NeweerPyLite, and would you like a credit in the comments?

No, I don't mind. Yes, if you could credit this project in there that would be great. Thank you.

[taburineagle]

Perfect - I'll push the first commit now then. It's only the bytestring logic at the moment, but it's a good place to start.

[taburineagle]

OK - it's live!

https://github.com/taburineagle/Neweer-PythonLite

[Teravus]

I know that this is old, but I've gotten an extremely hacked up program based on information in neewerlight.swift to turn on and off 660 pro LEDs using InTheHand.BluetoothLE on .NET

I'm still working on implementing CCT, brightness, hue and scene changes..
.. just tested Hue changes.. and they're working:

var FullPurple = new NeewerLight.NeewerLightInstruction()
{
          LightMode = nLightMode.HSIMode,
          RGB = NeewerLight.NeewerColor.Purple,
          brightness = 1f,
};
btmgr.ExecuteLightInstruction(id,FullPurple).Wait();
var FullGreen= new NeewerLight.NeewerLightInstruction()
{
          LightMode = nLightMode.HSIMode,
          RGB = NeewerLight.NeewerColor.Green,
          brightness = 1f,
};
btmgr.ExecuteLightInstruction(id,FullGreen).Wait();
var FullBlue= new NeewerLight.NeewerLightInstruction()
{
          LightMode = nLightMode.HSIMode,
          RGB = NeewerLight.NeewerColor.Blue,
          brightness = 1f,
};
btmgr.ExecuteLightInstruction(id,FullBlue).Wait();