-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reading light power #7
Comments
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. |
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. |
FWIW i'm running linux with a RGB480, here is a bluetoothctl session which shows what I am seeing:
alas, that returning a null value until you've written to it is kind of pesky. |
Hmm, interesting - so is the value you're reading back from that characteristic parroting back the last value you wrote to it? |
Yeah it seems so, i.e. if one turns the |
I got the same test result. the reading doesn't reflecting the real state of the light power. |
OK, theoretically, if you write read_request |
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 |
Hmm - this is for a completely different device, but uses the same BT characteristics - |
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. |
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 -
|
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! |
I think I may have figured out how to read the light power status! It needs some testing though... the bytestring |
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 Edit: heh hadn't seen your updated comment, Had been wondering what the gap between |
@ratmice - Right! I've actually implemented that in NeewerLite-Python -
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 |
I believe the reason for lack of updates for STBY is because:
So in theory, only one query is needed each time the device connects to keep it synchronized, whereas channel can be modified from the device and become unsynchronized |
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!" |
I have released the v0.7(cad82f4) to support channel updates. |
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
orpower_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
The text was updated successfully, but these errors were encountered: