Version with original LT8900(LT8910-8920) module about esp8266_milight_hub HOT 102 CLOSED

I will try to make a mockup, and then you can come with some inputs afterwards.

from esp8266_milight_hub.

Nice, I like this! :)

from esp8266_milight_hub.

Nice, I like this! :)

But i am beginner in С++ and I not able to write this LT8910 version, but i ready to help you :)

from esp8266_milight_hub.

Chris, it's possible, that you can make in foreseeable future library with support LT8910 or no? :)

from esp8266_milight_hub.

I like the idea from a cleanliness perspective, but given that Henryk's PL1167 emulator code works pretty well, and NRF24L01s seem to be more available, I'm not sure there's much practical value.

What are the biggest advantages that you see?

from esp8266_milight_hub.

Probably you are right. Simply at the first stage, it was much easier for me, as a beginner, to work and explore data packets, using literally small sketches .. And in practical application, it is possible that it is not needed.

from esp8266_milight_hub.

#include <SPI.h>
#include "LT8900.h"
#include <ESP8266WiFi.h>
#include <PubSubClient.h>

const char *ssid = ".."; // cannot be longer than 32 characters!
const char *pass = "..."; // WiFi password

const uint8_t PIN_NRF_RST = 4;
const uint8_t PIN_NRF_CS = 5;
const uint8_t PIN_NRF_PKT = 10;
uint8_t bufer;

LT8900 lt(PIN_NRF_CS, PIN_NRF_PKT, PIN_NRF_RST);

//Thanks to Henryk and Erantimus for providing details and checksum code.
//Calculate Checksum - Returns 2 bytes.

uint8_t recieve_code()
{
uint8_t bbuf[20];
int packetSize = lt.read(bbuf, 20);
Serial.print ("RAW packetSize =");
Serial.println(packetSize);
if ((packetSize>1)&&(packetSize<20))

{
digitalWrite(LED_BUILTIN, LOW); // Turn the LED off by making the voltage HIGH
delay(2);
digitalWrite(LED_BUILTIN, HIGH); // Turn the LED off by making the voltage HIGH

    Serial.println();
   // Serial.println("Packet read OK");
    uint16_t value = lt.getChannel();
    Serial.print ("Current channel = ");
    Serial.println (value);
    Serial.print("Size of packet = ");
    Serial.print(packetSize);
    Serial.println();

    //dump the packet.
   
    for(int i = 0; i < packetSize; i++)
    {
      if (i) Serial.write(':');
      if (bbuf[i] < 16) Serial.write('0');
      Serial.print(bbuf[i],HEX);

    Serial.println();
   // Serial.write(bbuf,packetSize);
  }

return bbuf[packetSize];
//crc=calc_crc(bbuf,packetSize);
}

void setup_wifi() {

delay(4);
// We start by connecting to a WiFi network
Serial.println();
Serial.print("Connecting to ");
Serial.println(ssid);

WiFi.begin(ssid, pass);

while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());
}

void setup()
{
// put your setup code here, to run once:
pinMode(LED_BUILTIN, OUTPUT); // Initialize the LED_BUILTIN pin as an output
digitalWrite(LED_BUILTIN, HIGH);
Serial.begin(256000);
Serial.println(F("\n\nLT8900 module sample, v0.1.\n\n"));

SPI.begin();
SPI.setFrequency(1000000);

lt.begin();
lt.setCurrentControl(12,7);

char sbuf[32];

//verify chip registers.
for (int i = 0; i <= 50; i++)
{
uint16_t value = lt.readRegister(i);

sprintf_P(sbuf, PSTR("%d = %04x\r\n"), i, value);
Serial.print(sbuf);

}
Serial.println(F("Reader mode"));
lt.startListening();
lt.whatsUp(Serial);
Serial.println(F("Boot completed."));
setup_wifi();
}

void loop()
{

lt.setSyncWord(0x55AA00000000050A);
lt.setSyncWordLength(0x01);
lt.setChannel(0x27); //39
lt.startListening();
if (lt.available())
{
 bufer=recieve_code();

lt.setSyncWord(0x1809000000007236);
lt.setSyncWordLength(0x11);
lt.setChannel(0x08); //39
lt.startListening();
if (lt.available())
{
bufer=recieve_code();

lt.setSyncWord(0xBCCD000000009AAB);
lt.setSyncWordLength(0x11);
lt.setChannel(0x03); //3
lt.startListening();
if (lt.available())
{
 bufer=recieve_code();
/// uint8_t crc=calc_crc(bbuf,packetSize);
}

lt.setSyncWord(0xBCCD000000009AAB);
lt.setSyncWordLength(0x11);
lt.setChannel(0x26); //3
lt.startListening();
if (lt.available())
{
 bufer=recieve_code();
}

lt.setSyncWord(0xBCCD000000009AAB);

lt.setSyncWordLength(0x11);
lt.setChannel(0x49); //3
lt.startListening();
if (lt.available())
{
bufer=recieve_code();
}

lt.setSyncWord(0x03805A5A03800380);
lt.setSyncWordLength(0x10);
lt.setChannel(0x05); //5
lt.startListening();

// lt.whatsUp(Serial);
if (lt.available())
{
bufer=recieve_code();
lt.whatsUp(Serial);

} 

}

from esp8266_milight_hub.

That's all code.

from esp8266_milight_hub.

Gotcha. Makes sense. Nice to not need to deal with CRC and bit fiddling. But given that it's all handled in a pretty reliable way (thanks to Henryk), I'm not sure it makes sense to switch, especially since it seems like the NRF24L01 is a more popular xceiver.

from esp8266_milight_hub.

Hi there,
super work decoding the protocol.
I also use the different transciever, and have had quite a few problems with the nRF ones.
With some minor tweaks and the addition of two files + a interface selection it should be doable without much hassle.
It will only be the transport layer, all the magic happens in your layer.

from esp8266_milight_hub.

Interesting. I've not noticed anything funky with the nrf24s. Do you mind sharing what kinds of issues you saw?

Yeah, I'd imagine it's possible to construct a different implementation of MiLightRadio within MiLightClient and it'd work pretty seamlessly.

I ordered some of these things a few days ago, but they probably won't be here for a few weeks. I can play around with it then.

Obviously happy to look at a PR before then.

from esp8266_milight_hub.

Yeah, instability and quite slow.
I had to implement synced fading and control between different groups, and due to all the recalcs of parameters it never looked visually good.
With the other module - once set up for a type with the matching sync word, it is just a matter of sending a frame, and the channel is just a register to set also.

from esp8266_milight_hub.

Aah, interesting. Yeah I'm not doing anything that requires nearly that level of precision or performance.

Definitely sounds like it's worth investigating. :)

from esp8266_milight_hub.

I looked at the project, and thought about making a copy of PL1167_nRF24.cpp and make a PL1167_PL8900.cpp leaving the unnecessary functions empty making it compatible with the milightclient.... but it seems the RF24 is well incorporated.... maybe it is better to make a clone of the milightclient, accessing the new module directly, and then differ when init the client module.

from esp8266_milight_hub.

I looked at the project, and thought about making a copy of PL1167_nRF24.cpp and make a PL1167_PL8900.cpp leaving the unnecessary functions empty making it compatible with the milightclient.... but it seems the RF24 is well incorporated.... maybe it is better to make a clone of the milightclient, accessing the new module directly, and then differ when init the client module.

If need, i can be a tester with LT8900 or LT8920..:)

from esp8266_milight_hub.

I feel like MiLightRadio is the right layer of abstraction here. I guess it seems like exactly the interface for the "transport layer" you referred to above. Without knowing exactly what you'll need to do, the methods in this class seem more or less exactly what you what to swap implementations for:

    int begin();
    bool available();
    int read(uint8_t frame[], size_t &frame_length);
    int dupesReceived();
    int write(uint8_t frame[], size_t frame_length);
    int resend();
    int configure();

Obviously some things like the reference to an AbstractPL1167 would need to be pulled into a separate implementation (something like NrfMiLightRadio, maybe?)

Then it'd just be a matter of passing or constructing a different type of MiLightRadio in MiLightClient.

from esp8266_milight_hub.

I think the AbstractPL1167 can be omitted, and then there must be added to RadioStack also.

from esp8266_milight_hub.

RadioStack is just meant to be pairs of MiLightRadio and MiLightRadioConfig. I think stuff specific to the NRF would be pulled into the NRF-specific implementation of MiLightRadio.

The interfaces are messy and bleed into each other because the transport layer wasn't an important abstraction. Obviously we'd want to clean that up before adding a new impl. :)

Let me know if I can help out making the code more amenable to this.

from esp8266_milight_hub.

Just an update - I can receive something, but will just tidy up the code... hopefully something within a day or two

from esp8266_milight_hub.

Awesome :)

from esp8266_milight_hub.

There might be added a further pin setup for a hardware reset pin - if set to '0' then it is not used. Furthermore a setup of RF module used: nRF or LT8900 compatible...

from esp8266_milight_hub.

I have reception running, and also transmission, one thing though is I have three RGB_CCT bulbs on the same group, and when sending an on/off - one or two does not respond, but then one is reacting as it should. And then the behaviour shuffles between the bulbs.... it is late here - will look into it the next few days.

from esp8266_milight_hub.

Might be some timing issues caused by the stream and my resend function... can be sortes.

from esp8266_milight_hub.

Awesome! I'm excited to test this out. I noticed yesterday while testing some of the UDP changes that something seems pretty sluggish, and I'm wondering if it's the NRF. Could totally be my rather unoptimized UDP handling too, but one can hope :)

from esp8266_milight_hub.

Have you tried multiple RGB_CCT bulbs in a group with the nRF interface.... do they all respond as they should - I keep getting the same issue, where they shuffle in the behaviour?
What about the frame that is being sent when powering the remotes, could that be a "MASTER" frame the resets the bulbs sequence number, to make them listen again for a low sequence number? Do they respond, if the number decrement instead of increment?

from esp8266_milight_hub.

Yeah, I have three different groups of RGB+CCT bulbs I've been using. Two of them have three bulbs, the other has two. They all at least appear to act in unison. It's definitely necessary to send repeat packets. I'm sending 30-50 on each channel the bulbs listen on. This might be excessive, but I've found that it's a good balance of responsiveness and reliability.

Bulbs do seem to ignore packets that have the same sequence value as the last packet they saw. I noticed this when replaying packets. I haven't tried sending packets with decreasing sequence numbers. My remotes and wifi box definitely seem to send packets with increasing sequence values.

As far as I've been able to tell, official devices are only sending the same packet multiple times per action, and not multiple packets.

from esp8266_milight_hub.

For best result on the other bulbs I've used around 100 transmissions spread across all channels.
I've just switched to the v1.1.0 branch - but now PlatformIO is acting up.... doh.
It might be the sequence number just needs to be different from command to command, to prevent acting many times on the re-transmits.

from esp8266_milight_hub.

Gotcha, interesting. I suppose it depends a bit on timing and signal strength?

What's PlatformIO doing? Hope I didn't break something. :(

Right, makes sense that it'd only need to be different. Only meant to suggest that the official devices seem to increment the sequence number by one rather than changing it by some other function.

from esp8266_milight_hub.

PlatformIO is running again with latest v1.1.0 - but still the same.
I can pair all three bulbs with the gateway, but they actually flashed green out of sync, and if I sync with a real remote, they pair and flash green in sync.... so something is off when transmitting the frames.
Reception works super, but just the problem with transmission.
What can it be......they change pattern on pressing the on toggle switch on the web interface.
But the encrypted frame must be OK, as some of the bulbs react.
Can it be related to the switch between channels..... or.... well. Night time here... .I'm off to bed.

from esp8266_milight_hub.

Problem solved:) - stupid mistake with an internal value being used instead of the right one - will clean up the code, and try to make a way to switch between the two interfaces.

from esp8266_milight_hub.

An option to select different modules must be added, but what about showing the connection state to the module on the web app. Makes it easy to identify if everything is connected OK.

from esp8266_milight_hub.

Where try new code? :)

from esp8266_milight_hub.

Will see if I can get it done later tonight..

from esp8266_milight_hub.

Awesome! Was it was performant as you hoped?

from esp8266_milight_hub.

Settings is where we'd put a setting to swap between radio modules, btw.

from esp8266_milight_hub.

Yep - working on it.... due to heavy work activity it might take a day or two - sorry.
Will try to make it as fast as possible, or at least upload something nearly finished.

from esp8266_milight_hub.

How will you prefer to get the changes...?

from esp8266_milight_hub.

Pull request sounds good to me if that works for you.

Should probably start a new minor release branch for it (v1.2.0).

from esp8266_milight_hub.

OK - I will make a branch v1.2.0 in my fork, commit the changes, and see if I can get the pull to work.
Might get the time later today.

from esp8266_milight_hub.

OK - I will make a branch v1.2.0 in my fork, commit the changes, and see if I can get the pull to work.
Might get the time later today.

Can you say pinout by default for LT8900 (in your version)?

from esp8266_milight_hub.

I use cs 15 and pin 4, reset is not used

from esp8266_milight_hub.

But you can set it from the web app

from esp8266_milight_hub.

Like this:

Reset not used (on LT8900)
Whats about PKT?

from esp8266_milight_hub.

Pkt shares the setting with csne, and you can connect reset also just assign a value different than 0 in the web app.

from esp8266_milight_hub.

Pkt is used as rx frame ready detection

from esp8266_milight_hub.

From my fork you just cannot save the module type yet. I saw somewhere that sidoh mentioned a rewrite, so thought is was more fun if you could test it.

from esp8266_milight_hub.

I propose correct this lablel to PL1167/LT8900/8910/8920

from esp8266_milight_hub.

Pkt shares the setting with csne

You mean csn_pin?

from esp8266_milight_hub.

Makes sense with the label☺ Yes sorry, the csn pin.

from esp8266_milight_hub.

From my fork you just cannot save the module type yet. I saw somewhere that sidoh mentioned a rewrite, so thought is was more fun if you could test it.

Rewrite of the web app? Yeah, made #23 for that. Not sure when I'll get around to that, though.

from esp8266_milight_hub.

Correct?

from esp8266_milight_hub.

Pkt should be on a input, different from 15

from esp8266_milight_hub.

Ok, will look into storing the interface selection then.

from esp8266_milight_hub.

If connected with serial, then it outputs connection state to the module. Should perhaps show the connection state in the app.

from esp8266_milight_hub.

@WoodsterDK, here are the results of the speed test with an nRF24. This is with 50 repeats:

Starting using 'nRF24' interface...
Elapsed: 171
Elapsed: 171
Elapsed: 173
Elapsed: 173
Elapsed: 172
Elapsed: 172

from esp8266_milight_hub.

The nRF24 seems faster then - but since you can tell me it works with narrower timing, I will try to speed it up down.

• I think I have a 'yield' placed somewhere unfortunate regarding the retransmission - it gets called a lot of times.
  Should be removed from "int MiLightRadioPL1167_LT8900::write(uint8_t frame[], size_t frame_length)" to the MilightClient instead.
• a delay between different channel transmissions might be removable.
• speed up the SPI communication

One question - 100-150 seems to a good amount of total transmissions, but why do you multiply with a factor?
milightClient->setResendCount(settings.httpRepeatFactor * settings.packetRepeats);

from esp8266_milight_hub.

Seems like the SPI clockdivider is the bad guy :)

I need to check up with the bulbs when I get home, but with 350uS between each frame/channel I get a time of ~95ms @ SPI_CLOCK_DIV4 vs. ~340ms @SPI_CLOCK_DIV128.

Removing the timing between the frames around 50ms can be chipped of.
Theoretically ~45ms @ SPI_CLOCK_DIV4 without delays between frames, but that has to be tested later today against the bulbs.

Might get even lower with a different SPI setting.

Will get back.

from esp8266_milight_hub.

Ok so, without delayMicroseconds(DEFAULT_TIME_BETWEEN_RETRANSMISSIONS_uS); between the channel resends, and with the following SPI setup:

SPI.begin();
SPI.setDataMode(SPI_MODE1);
SPI.setFrequency(4000000);
SPI.setBitOrder(MSBFIRST);

A complete transfer of 50 repeats (x 3 I guess due to the different channels) the total transmission time is:
Radio module running correctly...
Elapsed: 47
Elapsed: 49
Elapsed: 44
Elapsed: 43
Elapsed: 41

So quite faster .... and the bulbs responds:+1:

from esp8266_milight_hub.

👍

from esp8266_milight_hub.

Did you get it running :)

from esp8266_milight_hub.

No, in windows i have mistakes - #34 (comment)

from esp8266_milight_hub.

Awesome that you figured out how to optimize! I wonder if there are similar improvements we could make to the NRF24 radio...

One question - 100-150 seems to a good amount of total transmissions, but why do you multiply with a factor?

I'm not in love with how this is done, but the reason is basically that UDP clients typically re-send the same packet multiple times, which inflates the number of repeated packets. Obviously want to even out the number of repeats in UDP vs. HTTP, thus the multiplicative factor.

I took a stab at refactoring the interfaces to use the radio factory. Changes are in the PL1167 branch. Can you test to see that the LT8900 still works? You might need to update your settings (should work via the web UI if you update it).

You also might want to develop against this branch to make merging in changes easier.

@Lstt2005, just replace your platformio.ini with this until I can fix Windows compatability.

from esp8266_milight_hub.

Testing as we speek : )

from esp8266_milight_hub.

A couple of observations:
Pin settings are wrong:
LT8900Factory(settings.csnPin, settings.resetPin, settings.cePin);
should be:
LT8900Factory(settings.cePin, settings.resetPin, settings.csnPin);

And the set module type in the web app does not save the setting.

but still module does not respond.... will look into it - "I get Failed initializing the radio module..."

from esp8266_milight_hub.

Update - module just had to be hardware reset.
Issues seen as noted below - optimization regarding speed still works.
Pin settings are wrong:
LT8900Factory(settings.csnPin, settings.resetPin, settings.cePin);
should be:
LT8900Factory(settings.cePin, settings.resetPin, settings.csnPin);

And the set module type in the web app does not save the setting.

from esp8266_milight_hub.

D'oh! Sorry I borked the pin settings. I had actually screwed them up in the NRF factory too.

Looking more closely, though, shouldn't the way it is be correct?

...
    case LT8900:
      return new LT8900Factory(settings.csnPin, settings.resetPin, settings.cePin);
...

LT8900Factory::LT8900Factory(uint8_t csPin, uint8_t resetPin, uint8_t pktFlag)
  : _csPin(csPin),
    _resetPin(resetPin),
    _pktFlag(pktFlag)
{ }

...

MiLightRadio* LT8900Factory::create(const MiLightRadioConfig& config) {
  return new LT8900MiLightRadio(_csPin, _resetPin, _pktFlag, config);
}

and in LT8900MiLightRadio:

    LT8900MiLightRadio(byte byCSPin, byte byResetPin, byte byPktFlag, const MiLightRadioConfig& config);

Did you update the web UI? I had to make some changes for it to switch settings. It was successfully switching between radios for me, but it wouldn't display that the change stuck in the UI. Still working on that, but will have to wait until later tonight.

from esp8266_milight_hub.

Csn equals pkt.
I saw that the setting was not visually changed, and thought it wasnt working. Will check later.
The implementation of the factory looks fine.

from esp8266_milight_hub.

Fixed the UI with 723d698. Should function as expected now.

from esp8266_milight_hub.

thinking this should be good to go. let me know if LT8900 stuff is still working. I can only confirm that NRF24 still works. :)

from esp8266_milight_hub.

Will make a test later, and get back... yeah.

from esp8266_milight_hub.

New pull request has been made - small changes made + functionality tested.

• Connection to module OK
• Settings saved from webapp

from esp8266_milight_hub.

Flipped arguments in factory and in UI with 8bbad4e.

Thinking this is pretty much complete at this point. I'll merge into a version branch in a sec.

Thanks so much for adding this, @WoodsterDK!

from esp8266_milight_hub.

Also updated the README to cover how to connect an LT8900 with 056241a.

from esp8266_milight_hub.

Today trying my LT8920 module..Very unstable...From Web UI commands run, but very often not always ..
If i try sniff, in serial i received:
LT8900: Packet less than zero, buffer to small
ElapsedRX: 1073686592
Packets received: 1073686592
Packet read OK, rec: 1073686592 Frame:
3FFF2840 3FFF2840 3FFF2840 3FFF2840 3FFF2840 3FFF2840 3FFF2840 3FFF2
840 3FFF2840
LT8900: Packet less than zero, buffer to small
ElapsedRX: 1073686592

And in WebUI sniffied code is displayed with a huge delay of 1-2 seconds ..

from esp8266_milight_hub.

Bummer!

How tight are the connections with the module? This is sounding a little bit like behavior I saw when connecting an NRF that had shorter headers, and wasn't making good connections with the dupont wires. I soldered a prototype board with some socket headers instead and the same module worked just fine.

@WoodsterDK, any insight here?

from esp8266_milight_hub.

See speed, when i pres randomly on FUT091 with my sketch - https://youtu.be/BVwxUvTkozM

#include <SPI.h>
#include "LT8900.h"
#include <ESP8266WiFi.h>
#include <PubSubClient.h>

extern "C" {
#include "ets_sys.h"
#include "os_type.h"
#include "osapi.h"
///#include "mem.h"
#include "user_interface.h"
#include "cont.h"
}
const char *ssid = ".."; // cannot be longer than 32 characters!
const char pass = ".."; // WiFi password
const char mqtt_server = "m21.cloudmqtt.com";
const uint8_t PIN_NRF_RST = 0;
const uint8_t PIN_NRF_CS = 15;
const uint8_t PIN_NRF_PKT = 5;
uint8_t bufer;

LT8900 lt(PIN_NRF_CS, PIN_NRF_PKT, PIN_NRF_RST);
uint8_t recieve_code()
{
uint8_t bbuf[32];
int packetSize = lt.read(bbuf, 32);
Serial.print ("RAW packetSize =");
Serial.println(packetSize);
if ((packetSize>1)&&(packetSize<32))

{
digitalWrite(LED_BUILTIN, LOW); // Turn the LED off by making the voltage HIGH
delay(2);
digitalWrite(LED_BUILTIN, HIGH); // Turn the LED off by making the voltage HIGH
Serial.println();
uint16_t value = lt.getChannel();
Serial.print ("Current channel = ");
Serial.println (value);
Serial.print("Size of packet = ");
Serial.print(packetSize);
Serial.println();
for(int i = 0; i < packetSize; i++)
{
if (i) Serial.write(':');
if (bbuf[i] < 16) Serial.write('0');
Serial.print(bbuf[i],HEX);
Serial.println();
}
return bbuf[packetSize];
}
}

void setup_wifi() {

delay(4);
// We start by connecting to a WiFi network
Serial.println();
Serial.print("Connecting to ");
Serial.println(ssid);
WiFi.begin(ssid, pass);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());
}

void setup()
{
// put your setup code here, to run once:
pinMode(LED_BUILTIN, OUTPUT); // Initialize the LED_BUILTIN pin as an output
digitalWrite(LED_BUILTIN, HIGH);
Serial.begin(256000);
Serial.println(F("\n\nLT8900 module sample, v0.1.\n\n"));
SPI.begin();
SPI.setFrequency(1000000);
lt.begin();
lt.setCurrentControl(12,7);
char sbuf[32];
//verify chip registers.
for (int i = 0; i <= 50; i++)
{
uint16_t value = lt.readRegister(i);
sprintf_P(sbuf, PSTR("%d = %04x\r\n"), i, value);
Serial.print(sbuf);
}
Serial.println(F("Reader mode"));
lt.startListening();
lt.whatsUp(Serial);
Serial.println(F("Boot completed."));
setup_wifi();
}

void loop()
{
lt.setSyncWord(0x55AA00000000050A);
lt.setSyncWordLength(0x01);
lt.setChannel(0x27); //39
lt.startListening();
if (lt.available())
{
bufer=recieve_code();
}
lt.setSyncWord(0x1809000000007236);
lt.setSyncWordLength(0x01);
lt.setChannel(0x08); //39
lt.startListening();
if (lt.available())
{
bufer=recieve_code();
}
lt.setSyncWord(0x1809000000007236);
lt.setSyncWordLength(0x10);
lt.setChannel(0x027); //39
lt.startListening();
if (lt.available())
{
bufer=recieve_code();
}
lt.setSyncWord(0x1809000000007236);
lt.setSyncWordLength(0x11);
lt.setChannel(0x46); //39
lt.startListening();
if (lt.available())
{
bufer=recieve_code();
}
lt.setSyncWord(0xBCCD000000009AAB);
lt.setSyncWordLength(0x11);
lt.setChannel(0x03); //3
lt.startListening();
if (lt.available())
{
bufer=recieve_code();
}
lt.setSyncWord(0xBCCD000000009AAB);
lt.setSyncWordLength(0x11);
lt.setChannel(0x26); //3
lt.startListening();
if (lt.available())
{
bufer=recieve_code();
}
lt.setSyncWord(0xBCCD000000009AAB);
lt.setSyncWordLength(0x11);
lt.setChannel(0x49); //3
lt.startListening();
if (lt.available())
{
bufer=recieve_code();
}
lt.setSyncWord(0x03805A5A03800380);
lt.setSyncWordLength(0x10);
lt.setChannel(0x05); //5
lt.startListening();
if (lt.available())
{
bufer=recieve_code();
lt.whatsUp(Serial);
}
}

Result on boot:
LT8900 module sample, v0.1.

0 = 6fe0
1 = 5681
2 = 6617
3 = 3000
4 = 9cc9
5 = 6637
6 = 0000
7 = 0030
8 = 6c90
9 = c380
10 = 7ffd
11 = 0000
12 = 0000
13 = 48bd
14 = ffff
15 = 0000
16 = 0000
17 = 0000
18 = 0000
19 = 0000
20 = 0000
21 = 0000
22 = 00ff
23 = 8005
24 = 0067
25 = 1659
26 = 19e0
27 = 1300
28 = 1800
29 = 0000
30 = f413
31 = 0002
32 = 4800
33 = 3fc7
34 = 0800
35 = 0600
36 = 0000
37 = 0000
38 = 0000
39 = 0000
40 = 4401
41 = b000
42 = fdb0
43 = 000f
44 = 0101
45 = 0080
46 = 3f01
47 = 0101
48 = 0140
49 = 0101
50 = 0000
Reader mode

Tx_EN=0
Rx_En=0
Channel=48
CRC=1
FEC=0
FRAMER_ST=1
PKT=1
FIFO=0
FIFO_WR_PTR=0
FIFO_RD_PTR=0
Boot completed.

from esp8266_milight_hub.

So sounds like you're saying this sketch works well with your LT89 radio, but it's sluggish in the milight firmware?

I still don't have one to test with, so it's hard for me to be helpful debugging until I do. :(

from esp8266_milight_hub.

I see. Yes, this sketch works well ans super fast. But in my case, i have LT8920 (Lt8900 and LT8920 have some difference between initialise registers).
In my case, i try many modification with code and it's works absolutely unstable..(
When i try sniff RGB_CCT code, i see in a serial:

*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.0.128
Radio module running correctly...
Radio module running correctly...
Radio module running correctly...
Radio module running correctly...
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
ElapsedRX: 1073687072
Packets received: 1073687072
Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 Packet read OK, rec: 1073687072 Frame:
Packet read OK, rec: 1073687072 Frame:
Packet read OK, rec: 1073687072 Frame:
Packet read OK, rec: 1073687072 Frame:
3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20 3FFF2A20

Exception (9):
epc1=0x4023029e epc2=0x00000000 epc3=0x00000000 excvaddr=0x2d504013 depc=0x00000000

ctx: sys
sp: 3ffffd90 end: 3fffffb0 offset: 01a0

stack>>>
3fffff30: 4021d435 3ffec364 00000040 00000001
3fffff40: 3fff5334 40236ab3 3ffed424 3ffed430
3fffff50: 3ffed430 000000be 00000000 0000001e
3fffff60: 00000002 00000018 4021c2a3 3ffeff78
3fffff70: 3ffed424 3fffdcc0 3ffec5d8 3ffec5d8
3fffff80: 00000000 3ffeff78 3fffdab0 3fff1f50
3fffff90: 4021bbcf 3fffdab0 00000000 40202ca3
3fffffa0: 3ffec5d8 40000f49 3fffdab0 40000f49
<<<stack<<<

from esp8266_milight_hub.

Hmm... how much difference is there in the initialization of the LT8920 and the LT8900? It's sorta sounding like the code is not compatible. Exception 9, I think, is kinda like segfault.

It's hard for me to test because I have neither of these devices.

I'll test compatibility with the LT8900 when it gets here, but no idea when that'll be :(

from esp8266_milight_hub.

LT8900 showed up today! I didn't realize how tiny they are.

@WoodsterDK -- sending works very reliably. Seems like it's as reliable as the NRF.

Receiving seems quite a bit flakier, though. It takes multiple seconds (~5) for a packet to show up, and it clogs up the whole thing while listening is running. It seems like if it receives too many packets at once, it'll get killed by WDT. Here's some logs with DEBUG_PRINTF turned on:

LT8900: Packet read fail
ElapsedRX: 1073686160
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
LT8900: Packet less than zero, buffer to small
ElapsedRX: 1073686160
Packets received: 1073686160
Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 Packet read OK, rec: 1073686160 Frame:
3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FFF2690 3FF

@Lstt2005 -- is this consistent with what you see? Does transmit work for you?

I'll poke around a bit.

from esp8266_milight_hub.

is this consistent with what you see? Does transmit work for you?

Yes, I have almost the same situation ... The transfer works, but very rarely ...

LT8920.pdf
LT8900-ETC.pdf

Maybe some trouble in initialise module?

from esp8266_milight_hub.

Potentially. Can you put your LT8900 code on gist?

from esp8266_milight_hub.

Potentially. Can you put your LT8900 code on gist?

https://gist.github.com/Lstt2005/93d36a9a5dd56193ec239bd0454c275f

from esp8266_milight_hub.

I meant whatever library you're using to control the LT8900. You're including something, it looks like:

#include "LT8900.h"

from esp8266_milight_hub.

https://bitbucket.org/robvanderveer/lt8900lib
This is original library.

from esp8266_milight_hub.

I took a stab at improving read reliability in the lt8900_reads branch. Can you give that a try, @Lstt2005?

Writes are still working very reliably for me, though. Having a hard time reproducing the flakiness you're seeing.

I can try poking at differences in the setup code later.

from esp8266_milight_hub.

Work! Super fast receive, but:

1.Many doubles;
2.Not transmit :(

When i press Group 1 ON, i sniff:

Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E
Packet received (9 bytes):
Raw packet: AD 01 8A 90 C5 A5 48 C7 60

Decoded:
Key : AD
b1 : 21
ID : 02F2
Command : 01
Argument : 00
Sequence : B3
Group : 00
Checksum : 8E

from esp8266_milight_hub.

Cool.

Yeah, I expect duplicates. I think sniffing is really only useful to determine the remote ID, and having de-duplicated packets doesn't help with that. Are there reasons I'm not considering for deduping?

I didn't make any changes to the transmit code, so if it wasn't working for you before I wouldn't expect it to work now.

It's pretty strange that send is not working when receiving is. Are you positive all of the pin configs are consistent with the example you pasted? Are you able to send with the example sketch you pasted above?

from esp8266_milight_hub.

I sniff with my second NRF24:

1. Real FUT091 - ALL ON:
   Raw packet: E8 F4 D3 4C 3E A8 C6 3D 5C
   Decoded:
   Key : E8
   b1 : 21
   ID : 2651
   Command : 01
   Argument : 00
   Sequence : 4C
   Group : 00
   Checksum : 75

2. Virtual remote with LT8920, ALL ON:
   Raw packet: 00 DB BB 54 66 D1 AD 66 28
   Decoded:
   Key : 00
   b1 : 20
   ID : 2651
   Command : 01
   Argument : 01
   Sequence : 1F
   Group : 01
   Checksum : 71

3. Real FUT091 ALL OFF:
   Raw packet: 18 C4 A3 7C 0E 75 17 0D 76
   Decoded:
   Key : 18
   b1 : 21
   ID : 2651
   Command : 01
   Argument : 05
   Sequence : 4D
   Group : 00
   Checksum : 4B
   Packet received (9 bytes):

4. Virtual remote with LT8920 ALL OFF:
   Raw packet: 00 DB BB 54 66 CA 9A 66 22
   Decoded:
   Key : 00
   b1 : 20
   ID : 2651
   Command : 01
   Argument : 06
   Sequence : 20
   Group : 01
   Checksum : 77

Virtual command not control LED strip.
Maybe difference between real and virtual Argument?

from esp8266_milight_hub.

Wait, so you can see the LT8900 sending packets via another ESP, but it's not controlling the strip?

In your examples, the LT8900 radio is not sending "all on/off" commands. It's sending "group 1 on/off" commands. Make sure you have "all" selected in the group list.

from esp8266_milight_hub.

Wait, so you can see the LT8900 sending packets via another ESP, but it's not controlling the strip?

Yes.

In your examples, the LT8900 radio is not sending "all on/off" commands.

You are right! But if I have "all" selected in the group list, nothing change:

1. Real FUT091 ALL ON:

Raw packet: 6E 35 09 DB 1E F0 C0 DD 22
Decoded:
Key : 6E
b1 : 21
ID : 2651
Command : 01
Argument : 00
Sequence : 4F
Group : 00
Checksum : EA

2. Virtual remote with LT8920 ALL ON:

Raw packet: 00 DB BB 54 66 D0 96 65 23
Decoded:
Key : 00
b1 : 20
ID : 2651
Command : 01
Argument : 00
Sequence : 24
Group : 00
Checksum : 74

3. Real FUT091 ALL OFF:

Raw packet: A1 15 BA E5 D9 B4 5F DB 23
Decoded:
Key : A1
b1 : 21
ID : 2651
Command : 01
Argument : 05
Sequence : 50
Group : 00
Checksum : C7

4. Virtual remote with LT8920 ALL OFF:

Raw packet: 00 DB BB 54 66 CD 97 65 2D
Decoded:
Key : 00
b1 : 20
ID : 2651
Command : 01
Argument : 05
Sequence : 25
Group : 00
Checksum : 7A

from esp8266_milight_hub.

Gotcha. And the same thing works with an NRF?

from esp8266_milight_hub.

Just flash another ESP WITH an NRF (with lt8900_reads branch), NRF work and control led strip fine...

from esp8266_milight_hub.

Wacky. And it seems like they're sending the same packets, right?

Do you think it's possible it's a range thing? What happens if you move the LT8900 really close to the LED controller?

from esp8266_milight_hub.

Try all things:

1. Move the LT8900 really close to the LED - not stable control (1-2 times from 10);
2. Use another DC - not stable control (1-2 times from 10);
3. Use another frequency of SPI - not stable control (1-2 times from 10)....

In all cases my NRF sniffer see stable packets (from 10 cm on one table with LT8920 to 10 meters).
Maybe some with Channels frequency, it's quantity (not 3), number of packets?

from esp8266_milight_hub.

Thanks for trying that!

How many repeat packets do you have configured?

from esp8266_milight_hub.

Change from 5 to 50 - very very unstable...Maybe my module broken? Can try tomorrow - after tomorrow another LT8920..

from esp8266_milight_hub.

Yeah, my experience is that it needs to be in the vicinity of 50 for it to be reliable. Maybe try rebooting the ESP after setting it to 50. It should work without a reboot, but doesn't hurt to try. You could also try increasing it even more.

Given that you're seeing the commands showing up on your NRF, I sort of doubt it's a problem with the module. :\

from esp8266_milight_hub.

For me works fine with this settings:

Many thanks to all!!

from esp8266_milight_hub.

Nice! :)

from esp8266_milight_hub.