Reading light power

[ratmice]

Not terribly familiar with bluetooth, and just reading the source code

I noticed some commented out code in the NeewerLite.swift, //self.write(data: cmd_check_power as Data, to: characteristic)
But there is no cmd_check_power value.

I didn't see any other place where it seemed you could get the power_on/power_off status from the light.
I had noticed that it appears you can get this by calling I think it should be CBPeripheral.readValue(deviceCtlCharacteristic).
(edit) The return value seems equal to either power_on or power_off, I at least haven't seen anything other value.
This seemed odd, because afaict on my light it doesn't list the readable permission, only saying that it is writable...

I figured I would mention it in case it helps

[keefo]

When I write these code, I am hoping to read power state from light by using CBPeripheral.readValue. However, it does not work. The lights I am using does not support value reading. So, I commented the code out.

Even their own iOS app does not support power state reading.

[taburineagle]

I was curious about that too, it would be great if the light could send the current state it's in when first launching, mode, hue, brightness, battery, etc., but I don't think there's a characteristic that does that. Channel, yes - but AFAIK that's all the light sends back - and I don't (or at least haven't) used the channel in my program yet.

[ratmice]

FWIW i'm running linux with a RGB480,
I did manage though to get a null value out of it. When I first turn the device on and haven't written to the characteristic it will return null, but after that reading and writing works across connections.

here is a bluetoothctl session which shows what I am seeing:

[NEEWER-RGB480]# menu gatt
[NEEWER-RGB480]# select-attribute 69400002-B5A3-F393-E0A9-E50E24DCCA99
[NEEWER-RGB480:/service0009/char000d]# read
Attempting to read /org/bluez/hci0/dev_F1_1E_BD_08_B6_2F/service0009/char000d
[CHG] Attribute /org/bluez/hci0/dev_F1_1E_BD_08_B6_2F/service0009/char000d Value:
  00                                               .               
  00                                               .               
[NEEWER-RGB480:/service0009/char000d]# write "0x78 0x81 0x01 0x02 0xFC"
Attempting to write /org/bluez/hci0/dev_F1_1E_BD_08_B6_2F/service0009/char000d
[NEEWER-RGB480:/service0009/char000d]# read
Attempting to read /org/bluez/hci0/dev_F1_1E_BD_08_B6_2F/service0009/char000d
[CHG] Attribute /org/bluez/hci0/dev_F1_1E_BD_08_B6_2F/service0009/char000d Value:
  78 81 01 02 fc                                   x....           
  78 81 01 02 fc                                   x....           
[NEEWER-RGB480:/service0009/char000d]# write "0x78 0x81 0x01 0x01 0xFB"
Attempting to write /org/bluez/hci0/dev_F1_1E_BD_08_B6_2F/service0009/char000d
[NEEWER-RGB480:/service0009/char000d]# read
Attempting to read /org/bluez/hci0/dev_F1_1E_BD_08_B6_2F/service0009/char000d
[CHG] Attribute /org/bluez/hci0/dev_F1_1E_BD_08_B6_2F/service0009/char000d Value:
  78 81 01 01 fb                                   x....           
  78 81 01 01 fb                                   x....           

alas, that returning a null value until you've written to it is kind of pesky.

[taburineagle]

Hmm, interesting - so is the value you're reading back from that characteristic parroting back the last value you wrote to it?

[ratmice]

Yeah it seems so, i.e. if one turns the Right knob, to turn the light on and off I notice that it doesn't affect the value read, so it can read power_off, when the light is on etc... So it seems like it might not be very useful

[keefo]

I got the same test result. the reading doesn't reflecting the real state of the light power.

[taburineagle]

OK, theoretically, if you write read_request 78 84 00 FC to the main characteristic 69400002-B5A3-F393-E0A9-E50E24DCCA99, the notify characteristic 69400003-B5A3-F393-E0A9-E50E24DCCA99 replies with the channel information 78 01 01 03 7D - in this case, the light is on channel 3. I'm also kind of new to Bluetooth myself, but I'm curious what the 7F510005-B5A3-F393-E0A9-E50E24DCCA9E characteristic does - it's labeled as "Write, Write Without Response and Notify", and there's another "Write and Write Without Response" characteristic living at 7F510006-B5A3-F393-E0A9-E50E24DCCA9E - AFAIK (but I could be way off), those ones aren't used...?

[taburineagle]

Here's a look at those in nRF Connect, for an SL-80 - I haven't checked the other lights I have to confirm if they also have these characteristics, but I believe they do. Sending 78 84 00 FC to either 7F510005-B5A3-F393-E0A9-E50E24DCCA9E or 7F510006-B5A3-F393-E0A9-E50E24DCCA9E doesn't change anything.

[taburineagle]

Hmm - this is for a completely different device, but uses the same BT characteristics -
http://en.abluetech.com/uploads/soft/202007/PTR5610-S_PS_EN_V2.2.pdf

[ratmice]

I haven't checked the other lights I have to confirm if they also have these characteristics, but I believe they do

Can confirm RGB480 does at least, and while configuration service does sound promising no idea what they are. Curious if that is e.g. how they program the scenes.

[taburineagle]

That'd be interesting to find out, I'm guessing that's probably set in the firmware, but they might be able to tweak things using the AT commands. Ha, that might be worth a noodling some day :) I'm also curious to find what all of the Bluetooth commands do - for instance, the Bi-color LEDs send the color temp/brightness data differently than the RGB ones, and they each have their own prefix -

78 01 - Channel information return
78 02 - Power (?) information return
78 81 - Send power command on/off
78 82 - Send color temp in CCT mode (bi-color lights only)
78 83 - Send brightness in CCT mode (bi-color lights only)
78 84 - Request return from 78 01 - maybe there's something in here to get other forms of status info?
78 85 - Request return from 78 02 - power data? - this isn't a constant notify response though, it just requests once
78 86 - Send HSI command (RGB light only)
78 87 - Send CCT command (RGB light only)
78 88 - Send SCENE command (RGB light only)
78 89 - ?

[taburineagle]

Also, I have seen some lights on Neewer's website that have more than the 9 preset scenes available. I can't remember which one, but I saw one that had at least 20 separate scenes to use!

[taburineagle]

I think I may have figured out how to read the light power status! It needs some testing though... the bytestring 78 85 00 FD changes the value reported from 69400003-B5A3-F393-E0A9-E50E24DCCA99 to a slightly different value. When the light is on, it reports 78 02 01 01 7C and when it's off, it reports 78 02 01 02 7D at least in my little bit of testing here - so this may be the key?

[ratmice]

Sorry it took me so long to get back to you, but this works perfectly with my rgb480, It basically follows the same packet format as mechanism as writes do!

But 78 is some magic number, 02 is something which means power status, 01 is the length of the msg in the next bytes, 02 is the value, and 7d is the checksum.

Edit: heh hadn't seen your updated comment, Had been wondering what the gap between 81, and 83` is on the RGB lights 😢

[taburineagle]

@ratmice - Right! I've actually implemented that in NeewerLite-Python -

78 is the hex that all commands, both send and receive, start with for Neewer lights
02 is power status
01 is the length
01 means ON, and 02 means STBY
and 7C/7D (AFAIR) is the checksum for the ON and STBY values, respectively

Strangely enough though, and I'm not 100% sure why this is, but unlike the channel status (which automatically updates when the channel changes), the 78 02 value doesn't update its status unless you send the light another update request... at least for me, it doesn't 🤔

[ratmice]

I believe the reason for lack of updates for STBY is because:

• At device power on STBY is reset
• At program startup/device connection STBY can be queried
• STBY cannot be changed from the interface on the device

So in theory, only one query is needed each time the device connects to keep it synchronized,
but it doesn't really hurt to send the request every time the power status message is sent.

whereas channel can be modified from the device and become unsynchronized

[taburineagle]

That makes sense - also, you're sending it a different request on the back end, so the light might prioritize the channel info (as it's the normal request for notifications), based on those facts. I have my program querying both power and channel every 12 ticks (around 5-6 seconds), that way, if something does change, it'll update the table, and if something disconnects entirely (power loss, out of range, etc.), the program says "Device disconnected!"

[keefo]

I have released the v0.7(cad82f4) to support channel updates.