Ble lamp reverse engineren.

[Torac]

Ik heb een prolight bluetooth lamp gekocht en wil deze nu graag aansturen via mijn raspberry pi.
Deze setup heb ik al met 3 eurodomest lampen. Het probleem is dat gewoon nergens info kan vinden over wat er naar welk adres gestuurd word. Heb helaas geen android telefoon dus kan geen hci snoop log aan laten maken. Is er een alternatief hiervoor voor iphone? Heb zelf geprobeerd met nox en bluestacks (android emulators) en een virtualbox met android erop gemaakt. Beide werken niet. Ken ook niemand die een android telefoon heeft. Heb ook hcidump via raspberry pi geprobeerd maar dit werkt ook niet helaas. Heb ook nog wat rondgekeken in de source code van de apk app maar word hier niet veel wijzer van.

Heeft iemand hier of prolight lampen of een idee hoe ik een bluetooth log kan aanmaken via iphone? Of een ander idee om bluetooth te "sniffen"?

[ Voor 6% gewijzigd door Torac op 15-06-2019 21:32 ]

[JaDatIsPeter]

iPhone kent diverse BLE apps, waarmee je BLE devices kan ontdekken. Bijv. LightBlue LE, SmartDiscover, BLE Scanner (Pally), BLU (Oncelabs). Met Linux kan ook, maar wel met een BLE dongle (BT4.x). En naast hcitool en hciconfig bijv. gatttool.

Geen ervaring met die lampen. Via de iPhone apps kwam ik er achter dat de BT dongle voor de PC die ik had geen BLE sprak; want de iPhone kon het wel.

[dogtagz]

https://medium.com/@urish...th-lightbulb-56580fcb7546

nRF connect for mobile

[Torac]

Heb de buurvrouw haar telefoon geleend en daar hcisnoop log file op bekeken.
Heb nu een hele hoop packets gesniffed en de handler gevonden via wireshark
De handler is 0x001b en als je daar bv deze value heen stuurt:

feef04a300124a gaat hij uit
feef04a300114b en aan

En dit is groen: feef06a1003bfd4cda
En wit: feef06a100e9fff97d

Maar wat ik nu dus niet begrijp hoe is de value opgebouwd. Je ziet het begin:
feef06a100 <- dit is bij elke kleur die je veranderd het zelfde en daarna komen 8 digits:
e9 ff f9 7d
Dit kan RGBA zijn. Red green blue alphachannel/opacity/transparantie.
Alleen als ik dan bv puur rood wil is de rgb code daarvan: 255 0 0 en in hex zal dit dan FF 00 00 zijn plus de 00 van de transparantie maakt feef06a100FF000000. Alleen dit werkt niet.

Dit is nog een lijstje met alle values die ik heb gesniffed:
feef04a5000159 == roodish
feef04a5000258 == vol wit
feef06a100f3fdff6f == witish
feef06a100a195fc2c == paars
feef06a100c069fc39 == paarser
feef06a100d25efc32 == paarser
feef06a1008780fc5b == blauw
feef06a1003f2dfbf7 == blauw paars achtig
feef06a1002043fb00 == nog blauwer
feef06a1003ffd6cb6 == groen
feef06a100fef44d1f == geel
feef06a100fda92f89 == roder
feef06a100fc21be83 == paars
feef06a100e9fff97d == witwit
feef06a100fda92f89 == roder
feef06a100fc21be83 == paars

Ik begrijp gewoon niet wat de formule is om van bv 255 255 255 e9 ff f9 7d krijgen.

Iemand enig idee? Ik heb ook dit gevonden: https://stackoverflow.com...t-is-the-difference-betwe

[ Voor 5% gewijzigd door Torac op 16-06-2019 13:35 ]

[Onbekend]

In principe heb je bij een lichtbron geen transparantie nodig. Je gebruikt alleen transparantie als het object zelf transparant is en dat bijvoorbeeld achtergrondlicht door kan laten.
Ik vermoed daarom dat in dit geval de laatste byte (2 tekens) een soort van checksum is.

De feef04a500 lijkt wel een commando-opdracht, waarna de byte daarna het commando is, en de laatste byte dus een checksum.
De feef06a100 lijkt dan wel een kleur-opdracht, met daarna 3 bytes aan kleurinformatie, en de laatste byte weer een checksum.

Jouw commando wit is feef06a100 e9 ff f9 7d, waarbij de vetgedrukte tekens waarschijnlijk de kleuren zijn die voluit worden gestuurd.

Hoe de kleurinformatie is opgebouwd kom ik ook nog niet helemaal uit. Je hebt bijvoorbeeld 2x paars in jouw voorbeeld met 2 verschillende commando's: feef06a100 a195fc 2c en feef06a100 fc21be 83. Zijn dat twee verschillende kleuren paars?
Misschien dat je met deze informatie wat verder komt.

[Torac]

Onbekend schreef op zondag 16 juni 2019 @ 14:04:
In principe heb je bij een lichtbron geen transparantie nodig. Je gebruikt alleen transparantie als het object zelf transparant is en dat bijvoorbeeld achtergrondlicht door kan laten.
Ik vermoed daarom dat in dit geval de laatste byte (2 tekens) een soort van checksum is.

De feef04a500 lijkt wel een commando-opdracht, waarna de byte daarna het commando is, en de laatste byte dus een checksum.
De feef06a100 lijkt dan wel een kleur-opdracht, met daarna 3 bytes aan kleurinformatie, en de laatste byte weer een checksum.

Jouw commando wit is feef06a100 e9 ff f9 7d, waarbij de vetgedrukte tekens waarschijnlijk de kleuren zijn die voluit worden gestuurd.

Hoe de kleurinformatie is opgebouwd kom ik ook nog niet helemaal uit. Je hebt bijvoorbeeld 2x paars in jouw voorbeeld met 2 verschillende commando's: feef06a100 a195fc 2c en feef06a100 fc21be 83. Zijn dat twee verschillende kleuren paars?
Misschien dat je met deze informatie wat verder komt.

Hmm. Dat is bv paars a195fc 2c en dan paars fc21be 83 maar minder fel.
Hoe kom ik dan consistent aan die checksum?

[Onbekend]

Kan je eens proberen om de kleur rood te zenden naar de ontvanger en dan alle 256 combinaties te proberen door het versturen van feef06a100 ff 00 00 xx? Wat heb je op de xx dan moeten zetten? (en is de kleur ook echt rood?)

Als dat lukt, kan je dan het zelfde herhalen voor de kleuren ff ff 00 xx, 00 ff 00 xx, 00 ff ff 00 xx, 00 00 ff xx en ff 00 ff xx?
Misschien kunnen we hier al een klein verband in ontdekken.

[ Voor 3% gewijzigd door Onbekend op 16-06-2019 16:58 ]

[Torac]

Onbekend schreef op zondag 16 juni 2019 @ 16:51:
Kan je eens proberen om de kleur rood te zenden naar de ontvanger en dan alle 256 combinaties te proberen door het versturen van feef06a100 ff 00 00 xx? Wat heb je op de xx dan moeten zetten? (en is de kleur ook echt rood?)

Als dat lukt, kan je dan het zelfde herhalen voor de kleuren ff ff 00 xx, 00 ff 00 xx, 00 ff ff 00 xx, 00 00 ff xx en ff 00 ff xx?
Misschien kunnen we hier al een klein verband in ontdekken.

Kan maar hoe?
Met een bash scriptje oid. Geen idee hoe ik dit moet aanpakken.
Dit is de command:
sudo gatttool -b 50:65:83:19:9E:9D --char-write-req -a 0x001b -n feef04a300114b
Voor bv aan.

[alex3305]

Even wat getest en gekeken, maar voor zover ik kan zijn lijkt het inderdaad opgebouwd te zijn als volgt:

code:

Opdeling van complete boodschap:
feef = checksum / header bytes voor het sturen van een commando
0x   = lengte van message (in jouw voorbeeld 4 of 6)
ax   = type commando
       1 = aangepaste kleur vanuit app
       3 = aan/uit commando
       5 = lamp bekende kleur commando (?)
00   = altijd leeg?
msg  = 4 tot 6 bytes (00-FF) met message

Voor zover te zien vaste boodschappen?
Message aan: feef 04 a3 00 114b
Message uit: feef 04 a3 00 124a

Deze lijken mij in decimaal te worden verstuurd ipv hex? Zou je kunnen testen
Bekend rood: feef 04 a5 00 0159
Bekend wit:  feef 04 a5 00 0258

Daarna heb ik de hexadecimale kleuren omgezet in decimaal en als je die door een kleur codeerapp heen haalt dan lijkt dat als volgt opgebouwd te zijn:

code:

e9  ff  f9  7d
233 255 249 125
R   G   Bl  Br

Als je in bovenstaande in een website zet zoals colorpicker lijkt dat prima te kloppen. Ook met deze voorbeelden:

code:

a1  95  fc  2c 
161 149 252 44

fc  21  be  83 
252 33  190 131

87  80  fc  5b
135 128 252 91

3f  fd  6c  b6
63  253 108 182

Wellicht dat de lamp nog wat afwijking in kleur heeft, dat zie je helaas vaker.

Kleine tip trouwens, als je zelf commando's stuurt, zet de helderheid dan niet al te hoog of te laag. Het under- of overdriven van leds vinden ze vaak niet zo leuk . Zelf heb ik dit een tijdje terug ook gedaan. Wellicht nog interessante kost? alex3305 in "[Alg] Welke tools heb jij gemaakt? - deel IV"

@Torac hierboven, ik zou het met Python doen. Daar is de bluetooth stack best wel prima en wat makkelijker te besturen dan in bash. Maar dat was mijn ervaring, wellicht is dat bij jou anders.

[ Voor 5% gewijzigd door alex3305 op 16-06-2019 17:01 ]

[Torac]

alex3305 schreef op zondag 16 juni 2019 @ 17:00:
Even wat getest en gekeken, maar voor zover ik kan zijn lijkt het inderdaad opgebouwd te zijn als volgt:

code:

Opdeling van complete boodschap:
feef = checksum / header bytes voor het sturen van een commando
0x   = lengte van message (in jouw voorbeeld 4 of 6)
ax   = type commando
       1 = aangepaste kleur vanuit app
       3 = aan/uit commando
       5 = lamp bekende kleur commando (?)
00   = altijd leeg?
msg  = 4 tot 6 bytes (00-FF) met message

Voor zover te zien vaste boodschappen?
Message aan: feef 04 a3 00 114b
Message uit: feef 04 a3 00 124a

Deze lijken mij in decimaal te worden verstuurd ipv hex? Zou je kunnen testen
Bekend rood: feef 04 a5 00 0159
Bekend wit:  feef 04 a5 00 0258

Daarna heb ik de hexadecimale kleuren omgezet in decimaal en als je die door een kleur codeerapp heen haalt dan lijkt dat als volgt opgebouwd te zijn:

code:

e9  ff  f9  7d
233 255 249 125
R   G   Bl  Br

Als je in bovenstaande in een website zet zoals colorpicker lijkt dat prima te kloppen. Ook met deze voorbeelden:

code:

a1  95  fc  2c 
161 149 252 44

fc  21  be  83 
252 33  190 131

87  80  fc  5b
135 128 252 91

3f  fd  6c  b6
63  253 108 182

Wellicht dat de lamp nog wat afwijking in kleur heeft, dat zie je helaas vaker.

Kleine tip trouwens, als je zelf commando's stuurt, zet de helderheid dan niet al te hoog of te laag. Het under- of overdriven van leds vinden ze vaak niet zo leuk . Zelf heb ik dit een tijdje terug ook gedaan. Wellicht nog interessante kost? alex3305 in "[Alg] Welke tools heb jij gemaakt? - deel IV"

@Torac hierboven, ik zou het met Python doen. Daar is de bluetooth stack best wel prima en wat makkelijker te besturen dan in bash. Maar dat was mijn ervaring, wellicht is dat bij jou anders.

Heb je precies dezelfde lampen?
Ga het gelijk testen!

[alex3305]

Torac schreef op zondag 16 juni 2019 @ 17:02:
[...]

Heb je precies dezelfde lampen?
Ga het gelijk testen!

Nee. Alleen kerstlampjes van Action. Dit is met de informatie uit jouw post . Let wel op dat mijn Characteristics in mijn Python script zeer strak staan. Vziw haal je hiermee het type device op. Je kunt deze ook vele malen groter zetten dan mijn waardes (0x0024), maar dan duurt het verbinden wel een stuk langer. Ook moet je de UUID hebben die in regel 40 staat. Die is per type device uniek.

Met andere woorden, dit is geen drop-in script, maar daar moet je zeker nog wat aan knutselen. Maar wellicht handig om mee te starten

[Torac]

Ben bang dat je theorie niet helemaal klopt. @alex3305
Als ik bv dit pak:
feef06a100e9fff97d

En dan de 7d aanpas naar ff gebeurt er helemaal niks.
Of naar een ander random hex ook niets.
En ook bekend rood:
feef 04 a5 00 0159
Als ik die aanpas naar:
feef 04 a5 00 00ff
Gebeurd er niets.
feef 04 a5 00 01ff
Ook niets.

[ Voor 25% gewijzigd door Torac op 16-06-2019 17:21 ]

[Bas170]

Misschien een gekke vraag, maar kun je eventueel contact opnemen met de fabrikant?
Wellicht willen ze helpen.

[Torac]

Bas170 schreef op zondag 16 juni 2019 @ 17:27:
Misschien een gekke vraag, maar kun je eventueel contact opnemen met de fabrikant?
Wellicht willen ze helpen.

Opzich een goeie heb een mailtje eruit gegooid en 15 min aan een telefoon gehangen met wachtmuziek om doorverbonden te worden maarja. Tot op heden niet teruggebeld en geen mail terug.

[johnkeates]

Wat voor chips en firmware zit er in? Dikke kans dat het gewoon standaard meuk is.

[Torac]

Heb net wat zooi opgezocht in de sourcecode van de apk maar ook daar niks te vinden.
Heb bv gezocht of er ergens een regel code stond met 0x001b of met feef04a300124a maar niets.

johnkeates schreef op zondag 16 juni 2019 @ 17:29:
Wat voor chips en firmware zit er in? Dikke kans dat het gewoon standaard meuk is.

Geen idee.
Het enige wat ik weet is dat het lampen van prolight zijn. Aangestuurd door prolight smart led app.
Misschien van jellyfishtur? De ihomma app heeft exact dezelfde interface.

[ Voor 19% gewijzigd door Torac op 16-06-2019 17:34 ]

[alex3305]

Torac schreef op zondag 16 juni 2019 @ 17:17:
Ben bang dat je theorie niet helemaal klopt. @alex3305
Als ik bv dit pak:
feef06a100e9fff97d

En dan de 7d aanpas naar ff gebeurt er helemaal niks.
Of naar een ander random hex ook niets.
En ook bekend rood:
feef 04 a5 00 0159
Als ik die aanpas naar:
feef 04 a5 00 00ff
Gebeurd er niets.
feef 04 a5 00 01ff
Ook niets.

En gewoon een compleet andere waarde ook niets?

Als het een BTLE apparaat is moet je er wel eerst verbinding mee maken voordat je een commando kunt versturen. Is dat wat er wellicht misgaat?

Kun je eventueel de relevante code posten die je nu gebruikt?

[Torac]

alex3305 schreef op zondag 16 juni 2019 @ 17:47:
[...]

En gewoon een compleet andere waarde ook niets?

Als het een BTLE apparaat is moet je er wel eerst verbinding mee maken voordat je een commando kunt versturen. Is dat wat er wellicht misgaat?

Kun je eventueel de relevante code posten die je nu gebruikt?

Nee reageert op geen elk getal. Dit is het commando maar als ik de orginele gebruik
Als ik dit doe feef06a100e9fff97d
Gaat hij op rood.
Maar doe ik vervolgens dit feef06a100e9fff936
Gebeurt er niets.

Dit commando: sudo gatttool -b *adres :)* --char-write-req -a 0x001b -n
Op raspberry pi.

[alex3305]

Dan zou ik de volgende commando's gaan proberen:

[code]
feef06a100e9fff97d
feef06a100e9ff007d
feef06a100e900f97d
feef06a10000fff97d
[/code]

en daarna zoiets als:

[code]
feef06a100ffaaaa7d
feef06a100aaffaa7d
feef06a100aaaaff7d
[/code]

Als er dan nog niets gebeurt, dan is het inderdaad een checksum of zoiets.

Edit: In de broncode wordt inderdaad een checksum berekent...

[ Voor 10% gewijzigd door alex3305 op 16-06-2019 18:24 ]

[TommieW]

Op GitHub was er ooit een script om die Eurodomest lampen aan te sturen. De originele repo bestaat niet meer, maar hier is het scriptje zelf, op Google cache: https://webcache.googleus...&cd=1&hl=en&ct=clnk&gl=nl

[alex3305]

TommieW schreef op zondag 16 juni 2019 @ 18:46:
Op GitHub was er ooit een script om die Eurodomest lampen aan te sturen. De originele repo bestaat niet meer, maar hier is het scriptje zelf, op Google cache: https://webcache.googleus...&cd=1&hl=en&ct=clnk&gl=nl

Helaas zit hier ook de checksum niet bij. Maar gelukkig heb ik inmiddels de checksum weten uit te rekenen. Best wel een aardige berekening, leuk bedacht door de ontwikkelaar, maar vrij triviaal.

De checksum bestaat uit drie getallen: T1, T2 en P en die reken je als volgt uit:

code:

T1 = Type 1 uit het bericht, in dit geval a1
T2 = Type 2 uit het bericht, in dit geval 00
P = optelsom van het bericht, zonder checksum, daarna een Bitwise XOR gevolgd door een Bitwise AND.

Voorbeeld message: feef 06 a1 00 a1 95 fc 2c
fe = controle byte 1
ef = controle byte 2
06 = aantal bytes van payload
a1 = type 1
00 = type 2
a1 + 95 + fc = payload
2c = checksum

Payload 0xa1 + 0x95 + 0xfc = 0x232 (562) + 0xa1 (161) + 0x00 (0) = 0x2D3 (723)
0x2D3 (723) XOR 255 = 0x22c (556) AND 255 = 0x2c (44)

@Torac Ik ben benieuwd of je hier verder mee komt . Wel ben ik nog steeds van mening dat byte 1 het rode kanaal is, byte 2 het groene en byte 3 het blauwe kanaal is in de payload. Ben benieuwd of dat ook klopt.

[Torac]

TommieW schreef op zondag 16 juni 2019 @ 18:46:
Op GitHub was er ooit een script om die Eurodomest lampen aan te sturen. De originele repo bestaat niet meer, maar hier is het scriptje zelf, op Google cache: https://webcache.googleus...&cd=1&hl=en&ct=clnk&gl=nl

Klopt die heb ik zelf ook in gebruik.
Aanzienlijk makkelijker dan dit.

alex3305 schreef op zondag 16 juni 2019 @ 19:14:
[...]

Helaas zit hier ook de checksum niet bij. Maar gelukkig heb ik inmiddels de checksum weten uit te rekenen. Best wel een aardige berekening, leuk bedacht door de ontwikkelaar, maar vrij triviaal.

De checksum bestaat uit drie getallen: T1, T2 en P en die reken je als volgt uit:

code:

T1 = Type 1 uit het bericht, in dit geval a1
T2 = Type 2 uit het bericht, in dit geval 00
P = optelsom van het bericht, zonder checksum, daarna een Bitwise XOR gevolgd door een Bitwise AND.

Voorbeeld message: feef 06 a1 00 a1 95 fc 2c
fe = controle byte 1
ef = controle byte 2
06 = aantal bytes van payload
a1 = type 1
00 = type 2
a1 + 95 + fc = payload
2c = checksum

Payload 0xa1 + 0x95 + 0xfc = 0x232 (562) + 0xa1 (161) + 0x00 (0) = 0x2D3 (723)
0x2D3 (723) XOR 255 = 0x22c (556) AND 255 = 0x2c (44)

@Torac Ik ben benieuwd of je hier verder mee komt . Wel ben ik nog steeds van mening dat byte 1 het rode kanaal is, byte 2 het groene en byte 3 het blauwe kanaal is in de payload. Ben benieuwd of dat ook klopt.

Tjezus wat een hogere wiskunde... Snap er echt geen lariekoek van. Kun je me nog wat jip en janneke voorbeeldjes geven of de checksum laten berekenen in python? Ben namelijk van plan de lampen met python aan te sturen.

[alex3305]

@Torac Het maken laat ik aan jou over. Is toch wel het leukste stapje. Zelf was ik aan het testen met de debugger van Chrome. Lekker even pielen in Javascript, maar dat was meer kladje dan iets anders. Voor jou heb ik nog een pseudo code variant gemaakt:

code:

message = [0xfe, 0xef, 0x06, 0xa1, 0x00, 0xa1, 0x95, 0xfc]
counter = 0

function advance() {
  b = message[counter]
  counter = counter + 1
  return b
}

function calculate() {
  // skip byte 1 (fe)
  advance()
  // skip byte 2 (ef)
  advance()

  // calculate length (06 = 3 bytes, 04 = 2 bytes, etc.)
  length = advance() / 2

  // type 1 (a1)
  t1 = advance()
  // type 2 (00)
  t2 = advance()

  // get payload
  for (i = 0; i < length; i++) {
    p += advance()
  }

  // calculate checksum
  return (((t1 + t2) + p) ^ 255) & 255
}

Hier kun je vast wel iets van bakken neem ik aan .

[Torac]

alex3305 schreef op zondag 16 juni 2019 @ 19:29:
@Torac Het maken laat ik aan jou over. Is toch wel het leukste stapje. Zelf was ik aan het testen met de debugger van Chrome. Lekker even pielen in Javascript, maar dat was meer kladje dan iets anders. Voor jou heb ik nog een pseudo code variant gemaakt:

code:

message = [0xfe, 0xef, 0x06, 0xa1, 0x00, 0xa1, 0x95, 0xfc]
counter = 0

function advance() {
  b = message[counter]
  counter = counter + 1
  return b
}

function calculate() {
  // skip byte 1 (fe)
  advance()
  // skip byte 2 (ef)
  advance()

  // calculate length (06 = 3 bytes, 04 = 2 bytes, etc.)
  length = advance() / 2

  // type 1 (a1)
  t1 = advance()
  // type 2 (00)
  t2 = advance()

  // get payload
  for (i = 0; i < length; i++) {
    p += advance()
  }

  // calculate checksum
  return (((t1 + t2) + p) ^ 255) & 255
}

Hier kun je vast wel iets van bakken neem ik aan .

Tjeetje. Je moet ook niet alles voorkauwen dan heb ik er niks aan.
Ik heb in elk geval dit gevonden: https://www.tutorialspoin...ise_operators_example.htm en ga daar eens mee klooien.

Sta echt versteld haha.
Toch snap ik niet waarom de developer dit heeft gedaan. Hackers?

[alex3305]

@Torac Hackers zou een mogelijkheid kunnen zijn. Of er zit in de lamp nog een stukje code die controleert of het bericht goed is aangekomen. Wellicht dat ze problemen hadden met bereik of het aankomen van berichten. Je ziet vaker dat er om die reden een check byte wordt verstuurd. De lamp zou dan bijvoorbeeld om een retransmission kunnen verzoeken, maar ik denk niet dat deze verlichting zo slim is .

Bitwise operators is inderdaad de juiste term, maar dat is uiteindelijk alleen maar nodig voor het uitrekenen van de checksum en voor het definiëren van een maximale lengte van de checksum.

Overigens denk ik trouwens dat er vast nog een slordigheidsfoutje in mijn pseudo code hierboven zit. Maar daar kom je denk ik wel uit. Wat je altijd kunt doen om te kijken of het klopt is simpelweg met de hand even uitrekenen. Dit kun je ook al eenvoudig doen in de debugger van Chrome, in een Python terminal of met een (online) rekenmachine die bitware operaties ondersteund. Dan krijg je wellicht ook wat inzicht in hoe de formule in elkaar zit.

[Torac]

alex3305 schreef op zondag 16 juni 2019 @ 19:36:
@Torac Hackers zou een mogelijkheid kunnen zijn. Of er zit in de lamp nog een stukje code die controleert of het bericht goed is aangekomen. Wellicht dat ze problemen hadden met bereik of het aankomen van berichten. Je ziet vaker dat er om die reden een check byte wordt verstuurd. De lamp zou dan bijvoorbeeld om een retransmission kunnen verzoeken, maar ik denk niet dat deze verlichting zo slim is .

Bitwise operators is inderdaad de juiste term, maar dat is uiteindelijk alleen maar nodig voor het uitrekenen van de checksum en voor het definiëren van een maximale lengte van de checksum.

Overigens denk ik trouwens dat er vast nog een slordigheidsfoutje in mijn pseudo code hierboven zit. Maar daar kom je denk ik wel uit. Wat je altijd kunt doen om te kijken of het klopt is simpelweg met de hand even uitrekenen. Dit kun je ook al eenvoudig doen in de debugger van Chrome, in een Python terminal of met een (online) rekenmachine die bitware operaties ondersteund. Dan krijg je wellicht ook wat inzicht in hoe de formule in elkaar zit.

Komt vast goed. Mag ik vragen hoe je bij die formule komt like?

Dit is alvast een python scriptje die de formule doet.
a = 161
b = 149
d = 252
e = a + b + d
c = 0

print("d is", e)

f = e + a

g = f ^ 255

h = g & 255

print("checksum is", h)

[ Voor 7% gewijzigd door Torac op 16-06-2019 19:42 ]

[Torac]

alex3305 schreef op zondag 16 juni 2019 @ 19:14:
[...]

Helaas zit hier ook de checksum niet bij. Maar gelukkig heb ik inmiddels de checksum weten uit te rekenen. Best wel een aardige berekening, leuk bedacht door de ontwikkelaar, maar vrij triviaal.

De checksum bestaat uit drie getallen: T1, T2 en P en die reken je als volgt uit:

code:

T1 = Type 1 uit het bericht, in dit geval a1
T2 = Type 2 uit het bericht, in dit geval 00
P = optelsom van het bericht, zonder checksum, daarna een Bitwise XOR gevolgd door een Bitwise AND.

Voorbeeld message: feef 06 a1 00 a1 95 fc 2c
fe = controle byte 1
ef = controle byte 2
06 = aantal bytes van payload
a1 = type 1
00 = type 2
a1 + 95 + fc = payload
2c = checksum

Payload 0xa1 + 0x95 + 0xfc = 0x232 (562) + 0xa1 (161) + 0x00 (0) = 0x2D3 (723)
0x2D3 (723) XOR 255 = 0x22c (556) AND 255 = 0x2c (44)

@Torac Ik ben benieuwd of je hier verder mee komt . Wel ben ik nog steeds van mening dat byte 1 het rode kanaal is, byte 2 het groene en byte 3 het blauwe kanaal is in de payload. Ben benieuwd of dat ook klopt.

Wat ik nog niet helemaal begrijp is welke a1 je pakt. Die van kanaal rood? Of type 1.

[alex3305]

Torac schreef op zondag 16 juni 2019 @ 19:49:
[...]


Wat ik nog niet helemaal begrijp is welke a1 je pakt. Die van kanaal rood? Of type 1.

Mijn voorbeeld kun je ook zo interpreteren:

code:

Payload 0xa1 + 0x95 + 0xfc = 0x232 (562) + 0xa1 (161) + 0x00 (0) = 0x2D3 (723)
Payload R    + G    + B                  + T1         + T2

Alleen had ik wat tussenstappen om het e.e.a. te verduidelijken. Hopelijk is het nu wat duidelijker

[Torac]

alex3305 schreef op zondag 16 juni 2019 @ 21:41:
[...]

Mijn voorbeeld kun je ook zo interpreteren:

code:

Payload 0xa1 + 0x95 + 0xfc = 0x232 (562) + 0xa1 (161) + 0x00 (0) = 0x2D3 (723)
Payload R    + G    + B                  + T1         + T2

Alleen had ik wat tussenstappen om het e.e.a. te verduidelijken. Hopelijk is het nu wat duidelijker

Gelukt.
Heel erg bedankt voor de tip van de checksum! Dat heeft het hem uit eindelijk gedaan.
Hoe kwam je daar nou achter??

Dit zijn de 2 files:

Om via de app op mijn iphone (homekit) verbonden via homebridge de rgb waardes te krijgen.

code:

var colorsys = require('colorsys');
var Service, Characteristic;

module.exports = function(homebridge) {
  Service = homebridge.hap.Service;
  Characteristic = homebridge.hap.Characteristic;
  homebridge.registerAccessory("homebridge-fake-rgb2", "Fake-RGB2", RgbAccessory);
};

function RgbAccessory(log, config) {
  this.log = log;
  this.config = config;
  this.name = config.name;
  this.power = 0;
  this.brightness = 100;
  this.saturation = 0;
  this.hue = 0;
  this.adress = config.adress

  this.log("Initialized '" + this.name + "'");
}

RgbAccessory.prototype.setColor = function() {
  var color = colorsys.hsv_to_rgb({
    h: this.hue,
    s: this.saturation,
    v: this.brightness
  });

  if (!this.power) {
    color.r = 0;
    color.g = 0;
    color.b = 0;
  }

  this.log("Kleur naar rgb waarde", color.r, color.g, color.b);
  const fs = require('fs');


   fs.writeFile("/root/eurodomest-rgb1/red", color.r, function(err) {
    if(err) {
        return console.log(err);
    }
 }); 

   fs.writeFile("/root/eurodomest-rgb1/green", color.g, function(err) {
    if(err) {
        return console.log(err);
    }
});     

   fs.writeFile("/root/eurodomest-rgb1/blue", color.b, function(err) {
    if(err) {
        return console.log(err);
    }
}); 
 
   fs.writeFile("/root/eurodomest-rgb1/adress", this.adress, function(err) {
    if(err) {
        return console.log(err);
    }
}); 

const spawn = require("child_process").spawn;
const pythonProcess = spawn('python',["/root/eurodomest-rgb1/test2.py"]);

};

RgbAccessory.prototype.getServices = function() {
  var lightbulbService = new Service.Lightbulb(this.name);
  var bulb = this;

  lightbulbService
    .getCharacteristic(Characteristic.On)
    .on('get', function(callback) {
      callback(null, bulb.power);
    })
    .on('set', function(value, callback) {
      bulb.power = value;
      bulb.log("power to " + value);
      bulb.setColor();
      callback();
    });

  lightbulbService
    .addCharacteristic(Characteristic.Brightness)
    .on('get', function(callback) {
      callback(null, bulb.brightness);
    })
    .on('set', function(value, callback) {
      bulb.brightness = value;
      bulb.log("brightness to " + value);
      bulb.setColor();
      callback();
    });

  lightbulbService
    .addCharacteristic(Characteristic.Hue)
    .on('get', function(callback) {
      callback(null, bulb.hue);
    })
    .on('set', function(value, callback) {
      bulb.hue = value;
      bulb.log("hue to " + value);
      bulb.setColor();
      callback();
    });

  lightbulbService
    .addCharacteristic(Characteristic.Saturation)
    .on('get', function(callback) {
      callback(null, bulb.saturation);
    })
    .on('set', function(value, callback) {
      bulb.saturation = value;
      bulb.log("saturation to " + value);
      bulb.setColor();
      callback();
    });

  return [lightbulbService];
};

Dit script runned als een status word veranderd aan, uit, helderheid, kleur etc. Met jou hulp was dit nooit gelukt erg bedankt!

code:

import os

adr = open('/root/eurodomest-rgb1/adress')
r = open('/root/eurodomest-rgb1/red')
g = open('/root/eurodomest-rgb1/green')
b = open('/root/eurodomest-rgb1/blue')
adress = adr.read()
red2 = r.read()
green2 = b.read()
blue2 = g.read()

red = int(red2)
blue = int(blue2)
green = int(green2)

a = red + blue + green

b = a + 161

c = b ^ 255

d = c & 255

checksum = hex(d)
checksum2 = checksum.replace('0x', '')
print(checksum2)

red2 = format(red, '02x')
blue2 = format(blue, '02x')
green2 = format(green, '02x')

payload = "feef06a100" + red2 + blue2 + green2 + checksum2
print("debug: sending to", adress, "with payload:", payload)
os.system("gatttool -b " + adress + " --char-write-req -a 0x001b -n " + payload)
os.system("gatttool -b " + adress + " --char-write-req -a 0x001b -n " + payload)

[alex3305]

Top om te zien dat het gelukt is. Nu wellicht nog wat netjes maken en eventueel een aparte modulenaam geven? Wellicht kun je hier ook aan refereren in andere topics, zodat andere Tweakers er wellicht ook gebruik van kunnen maken .

Ook zou ik geen gebruik maken van gattool, maar netjes een Python BLE bibliotheek gebruiken. Dit heeft iets meer voeten in de aarde, maar is wel OS onafhankelijk. Wellicht iets voor een versie 2?

Maar hoe ik erachter ben gekomen? De APK decompilen en de code doorlopen. Dit had overigens wel wat voeten in de aarde en is helaas niet de meest nette oplossing. Heeft dus ook zeker niet mijn eerste voorkeur. Maar omdat @Onbekend een checksum ontdekte - dit las ik wat later pas - is er eigenlijk weinig keus. Behalve eventueel brute forcen, maar dat heeft ook niet de voorkeur vanwege de tijd die dit kost.