-
Notifications
You must be signed in to change notification settings - Fork 639
Support for GBLife RGBW Socket #1305
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
Comments
Given that the device appears to show multiple colours at the same time, there's a good chance that it will need FastLED support to get those LED's working (possibly WS2811/2 or similar). If it only shows single colours at a time, then it's probably similar to (for example), the Tonbux XS SSA06 Do you have any pictures of the front/back of the main boards - do the two boards separate easily? I think @xoseperez is currently targetting version 1.14.0 for FastLED support, but there are a number of outstanding issues to resolve, and it might not come in that version. If the module is an ESP8266 then there is a reasonable chance you can support the basic relay functioning and power monitoring depending on the chip used. |
@ColinShorts, here more pictures of the connectivity between the two boards. I guess you can separate the boards just unwelding the pins. There are white leds and RGB leds that work independently, but RGB leds seem to change all together (only one color at a time). |
Ok, it looks like the LEDs won't need fastLED. You'll just need to identify the best way to access the pins on the ESP for programming it, and then figure out which gpio pins are used to drive the relay, LEDs, power monitoring chip, and any switches. You will probably need to separate the boards to attach wires unless you can see enough of the pads on the ESP module, or there are other points you can attach to. It'd probably be best to reattach the boards temporarily using longer wires until you've got it working. I'd suggest trying your luck with the tonbux firmware and see if anything works, but you might need to change gpio assignment a few times, and you'll need to check the power chip, if fitted. Remember that the relay probably won't work unless it is attached to the mains, so the usual warnings apply: don't kill yourself or your equipment! |
Thank you @ColinShorts, I'll follow your advice. However, I'm not sure if the plug has power monitoring chip, how can I check that? |
When you split the boards, take note of the chips and compare them against the wiki |
@ColinShorts, I've made some progress. I've managed to load espurna 1.13.3 firmware with TONBUX_XSSSA06 (BLITZWOLF_BWSHP2 also seems to work) and the switch button works fine (GPIO15). Regarding leds, after pluggin the socket, the leds turn red (all of them) and when the relay switch to on, the leds turn off (and viceversa). How can I easily try different GPIOs to manage the leds? I enabled LED_SUPPORT in arduino.h, but there is no especific menu in administration web portal. |
Hello, if the led works and changes state, the GPIO is possibly correct. Probably you´re just missing
in hardware.h Else, use a code block similar to
in your hardware.h to tinker with the GPIO port number. |
Thanks @kerk1v, that worked. Now, I have to figure out how to manage all the RGBW leds. I guess 4 GPIOs are needed and GPIOP0 seems to correspond to the red leds. // LEDs
#define LED1_PIN 0 // R - 8 rgb led ring
#define LED1_PIN_INVERSE 1
#define LED2_PIN 5 // G
#define LED2_PIN_INVERSE 1
#define LED3_PIN 2 // B
#define LED3_PIN_INVERSE 1 |
That's exactly how to do it, sadly, unless you're good at following traces, trial and error is the best way to do it. If you turn off the colour picker, you can more easily identify the individual pins - I went through the same process with the iWoole light 😁 |
Ok, it's done. I've figured out the RGBW pins to control the light and works like a charm with color picker. The problem is that when RELAY_PROVIDER is RELAY_PROVIDER_LIGHT, the socket RELAY does not work because current version of ESPurna doesn't allow a mixed of dummy and real relays (See #483). @ColinShorts, @kerk1v, @xoseperez, any ideas to solve the problem? // Info
#define MANUFACTURER "TONBUX" // This should be "GBLIFE"
#define DEVICE "XSSSA06" // This should be "RGBW socket"
// Buttons
#define BUTTON1_PIN 13
#define BUTTON1_MODE BUTTON_PUSHBUTTON | BUTTON_DEFAULT_HIGH
#define BUTTON1_RELAY 1
// Relays
#define RELAY1_PIN 15
#define RELAY1_TYPE RELAY_TYPE_NORMAL
// Light RGBW
#define RELAY_PROVIDER RELAY_PROVIDER_LIGHT
#define LIGHT_PROVIDER LIGHT_PROVIDER_DIMMER
#define DUMMY_RELAY_COUNT 1
#define LIGHT_CHANNELS 4
#define LIGHT_CH1_PIN 5 // RED
#define LIGHT_CH2_PIN 14 // GREEN
#define LIGHT_CH3_PIN 12 // BLUE
#define LIGHT_CH4_PIN 4 // WHITE
#define LIGHT_CH1_INVERSE 0
#define LIGHT_CH2_INVERSE 0
#define LIGHT_CH3_INVERSE 0
#define LIGHT_CH4_INVERSE 0 |
Ok, here is an alternative configuration with LED instead LIGHT, white LEDs are linked to the relay and red, green and blue LEDs can be controlled independently via MQTT. The light configuration is commented and will work when ESPurna allows a mixed of dummy and real relays (hopefully soon). @xoseperez Maybe you want to include this configuration as a new supported hardwarde (I think it is the first that combines a rgbw light and a socket relay). In this issue there are also pictures of the hardware. // -----------------------------------------------------------------------------
// GBLIFE RGBW SOCKET
// -----------------------------------------------------------------------------
#elif defined(GBLIFE_RGBW)
// Info
#define MANUFACTURER "GBLIFE"
#define DEVICE "RGBW_SOCKET"
// Buttons
#define BUTTON1_PIN 13
#define BUTTON1_MODE BUTTON_PUSHBUTTON | BUTTON_DEFAULT_HIGH
#define BUTTON1_RELAY 1
// Relays
#define RELAY1_PIN 15
#define RELAY1_TYPE RELAY_TYPE_NORMAL
// LEDs
#define LED1_PIN 4 // White LEDs
#define LED1_PIN_INVERSE 0
#define LED1_RELAY 1
#define LED2_PIN 5 // Red LEDs
#define LED2_PIN_INVERSE 0
#define LED2_MODE LED_MODE_MQTT
#define LED3_PIN 14 // Green LEDs
#define LED3_PIN_INVERSE 0
#define LED3_MODE LED_MODE_MQTT
#define LED4_PIN 12 // Blue LEDs
#define LED4_PIN_INVERSE 0
#define LED4_MODE LED_MODE_MQTT
// Light RGBW -- Valid when ESPurna supports a mixed of dummy and real relays
//
// *** Comment or remove LEDs configuration block before uncomment this ***
//
//#define RELAY_PROVIDER RELAY_PROVIDER_LIGHT
//#define LIGHT_PROVIDER LIGHT_PROVIDER_DIMMER
//#define DUMMY_RELAY_COUNT 1
// #define LIGHT_CHANNELS 4
// #define LIGHT_CH1_PIN 5 // RED
// #define LIGHT_CH2_PIN 14 // GREEN
// #define LIGHT_CH3_PIN 12 // BLUE
// #define LIGHT_CH4_PIN 4 // WHITE
// #define LIGHT_CH1_INVERSE 0
// #define LIGHT_CH2_INVERSE 0
// #define LIGHT_CH3_INVERSE 0
// #define LIGHT_CH4_INVERSE 0 |
@xoseperez I've found an easy way to make a dummy switch (for the RGBW light) and a real switch (for the relay) work at the same time. It is necessary to make a few changes in the source code: In relay.ino comment 3 lines to force applying real relay configuration (if exists): void relaySetup() {
// Dummy relays for AI Light, Magic Home LED Controller, H801,
// Sonoff Dual and Sonoff RF Bridge
//#if DUMMY_RELAY_COUNT > 0 <---------- Comment this line
// No delay_on or off for these devices to easily allow having more than
// 8 channels. This behaviour will be recovered with v2.
for (unsigned char i=0; i < DUMMY_RELAY_COUNT; i++) {
_relays.push_back((relay_t) {0, RELAY_TYPE_NORMAL, 0, 0, 0});
}
//#else <---------- Comment this line
#if RELAY1_PIN != GPIO_NONE
_relays.push_back((relay_t) { RELAY1_PIN, RELAY1_TYPE, RELAY1_RESET_PIN, RELAY1_DELAY_ON, RELAY1_DELAY_OFF });
#endif
#if RELAY2_PIN != GPIO_NONE
_relays.push_back((relay_t) { RELAY2_PIN, RELAY2_TYPE, RELAY2_RESET_PIN, RELAY2_DELAY_ON, RELAY2_DELAY_OFF });
#endif
#if RELAY3_PIN != GPIO_NONE
_relays.push_back((relay_t) { RELAY3_PIN, RELAY3_TYPE, RELAY3_RESET_PIN, RELAY3_DELAY_ON, RELAY3_DELAY_OFF });
#endif
#if RELAY4_PIN != GPIO_NONE
_relays.push_back((relay_t) { RELAY4_PIN, RELAY4_TYPE, RELAY4_RESET_PIN, RELAY4_DELAY_ON, RELAY4_DELAY_OFF });
#endif
#if RELAY5_PIN != GPIO_NONE
_relays.push_back((relay_t) { RELAY5_PIN, RELAY5_TYPE, RELAY5_RESET_PIN, RELAY5_DELAY_ON, RELAY5_DELAY_OFF });
#endif
#if RELAY6_PIN != GPIO_NONE
_relays.push_back((relay_t) { RELAY6_PIN, RELAY6_TYPE, RELAY6_RESET_PIN, RELAY6_DELAY_ON, RELAY6_DELAY_OFF });
#endif
#if RELAY7_PIN != GPIO_NONE
_relays.push_back((relay_t) { RELAY7_PIN, RELAY7_TYPE, RELAY7_RESET_PIN, RELAY7_DELAY_ON, RELAY7_DELAY_OFF });
#endif
#if RELAY8_PIN != GPIO_NONE
_relays.push_back((relay_t) { RELAY8_PIN, RELAY8_TYPE, RELAY8_RESET_PIN, RELAY8_DELAY_ON, RELAY8_DELAY_OFF });
#endif
//#endif <---------- Comment this line In relay.ino replace this code in _relayProviderStatus function: #if DUMMY_RELAY_PROVIDER == RELAY_PROVIDER_LIGHT
// If the number of relays matches the number of light channels
// assume each relay controls one channel.
// If the number of relays is the number of channels plus 1
// assume the first one controls all the channels and
// the rest one channel each.
// Otherwise every relay controls all channels.
// TODO: test if this approach to suport a mixed of dummy and real relays works in all cases
// Reference: https://github.com/xoseperez/espurna/issues/1305
if (DUMMY_RELAY_COUNT == lightChannels()) {
//if (_relays.size() == lightChannels()) {
lightState(id, status);
lightState(true);
} else if (DUMMY_RELAY_COUNT == (lightChannels() + 1u)) {
//} else if (_relays.size() == (lightChannels() + 1u)) {
if (id == 0) {
lightState(status);
} else {
lightState(id-1, status);
}
} else {
if (id < DUMMY_RELAY_COUNT) lightState(status);
//lightState(status);
}
lightUpdate(true, true);
#endif In hardware.h include button, relay, light and optionally led configuration for the device. Switch #0 // -----------------------------------------------------------------------------
// GBLIFE RGBW SOCKET
// -----------------------------------------------------------------------------
#elif defined(GBLIFE_RGBW)
// Info
#define MANUFACTURER "GBLIFE"
#define DEVICE "RGBW_SOCKET"
// Buttons
#define BUTTON1_PIN 13
#define BUTTON1_MODE BUTTON_PUSHBUTTON | BUTTON_DEFAULT_HIGH
#define BUTTON1_RELAY 2
// Relays
#define RELAY2_PIN 15
#define RELAY2_TYPE RELAY_TYPE_NORMAL
// LEDs <--- This configuration is optional
#define LED1_PIN 4 // WHITE - 8 rgb led ring
#define LED1_PIN_INVERSE 0
#define LED1_MODE LED_MODE_MQTT
//#define LED1_RELAY 2
#define LED2_PIN 5 // RED
#define LED2_PIN_INVERSE 0
#define LED2_MODE LED_MODE_MQTT
#define LED3_PIN 14 // GREEN
#define LED3_PIN_INVERSE 0
#define LED3_MODE LED_MODE_MQTT
#define LED4_PIN 12 // BLUE
#define LED4_PIN_INVERSE 0
#define LED4_MODE LED_MODE_MQTT
// Light RGBW
// ***** Changed RELAY_PROVIDER to DUMMY_RELAY_PROVIDER *****
#define DUMMY_RELAY_PROVIDER RELAY_PROVIDER_LIGHT
#define LIGHT_PROVIDER LIGHT_PROVIDER_DIMMER
#define DUMMY_RELAY_COUNT 1
#define LIGHT_CHANNELS 4
#define LIGHT_CH1_PIN 5 // RED
#define LIGHT_CH2_PIN 14 // GREEN
#define LIGHT_CH3_PIN 12 // BLUE
#define LIGHT_CH4_PIN 4 // WHITE
#define LIGHT_CH5_PIN 2 // DARKNESS
#define LIGHT_CH1_INVERSE 0
#define LIGHT_CH2_INVERSE 0
#define LIGHT_CH3_INVERSE 0
#define LIGHT_CH4_INVERSE 0
#define LIGHT_CH5_INVERSE 0 NOTE: In files alexa.ino and migrate.ino it should also be replaced |
@etatus, thanks! Used part of your code but used a simpler approach to allow physical relays on a light device. Can you check if it's working? |
Also changed the order the relays are loaded. Now physical relays are loaded first and dummy relays afterward. I have also changed the device configuration to reflect this. |
Great news @xoseperez! I'll give a try and I'll let you know. Do I have to change any particular thing in my hardware.h? Did you preserve DUMMY_RELAY_PROVIDER variable? |
The configuration is in |
@xoseperez I confirm the changes work properly. I had to make some modifications in my configuration (physical relays go first now). Just one issue to fix: when I switch physical relay in Home Assistant, it is updated in the ESPURNA web interface (Status), but when I switch dummy relay in Home Assistant, it is not updated in the ESPURNA web interface, despite it works fine. I guess it is a problem with MQTT communication. And a final quesiton: Is it possible to get the status of normal LED sensors? You can turn them on/off, but you cannot know if they are turned on/off. // -----------------------------------------------------------------------------
// GBLIFE RGBW SOCKET
// -----------------------------------------------------------------------------
#elif defined(GBLIFE_RGBW)
// Info
#define MANUFACTURER "GBLIFE"
#define DEVICE "RGBW_SOCKET"
// Buttons
#define BUTTON1_PIN 13
#define BUTTON1_MODE BUTTON_PUSHBUTTON | BUTTON_DEFAULT_HIGH
#define BUTTON1_RELAY 1
// Relays
#define RELAY1_PIN 15
#define RELAY1_TYPE RELAY_TYPE_NORMAL
// LEDs <--- This LED configuration is optional
#define LED1_PIN 4 // WHITE - 8 rgb led ring
#define LED1_PIN_INVERSE 0
#define LED1_MODE LED_MODE_MQTT
//#define LED1_RELAY 1
#define LED2_PIN 5 // RED
#define LED2_PIN_INVERSE 0
#define LED2_MODE LED_MODE_MQTT
#define LED3_PIN 14 // GREEN
#define LED3_PIN_INVERSE 0
#define LED3_MODE LED_MODE_MQTT
#define LED4_PIN 12 // BLUE
#define LED4_PIN_INVERSE 0
#define LED4_MODE LED_MODE_MQTT
// Light RGBW
#define RELAY_PROVIDER RELAY_PROVIDER_LIGHT
#define LIGHT_PROVIDER LIGHT_PROVIDER_DIMMER
#define DUMMY_RELAY_COUNT 1
#define LIGHT_CHANNELS 4
#define LIGHT_CH1_PIN 5 // RED
#define LIGHT_CH2_PIN 14 // GREEN
#define LIGHT_CH3_PIN 12 // BLUE
#define LIGHT_CH4_PIN 4 // WHITE
#define LIGHT_CH5_PIN 2 // DARKNESS
#define LIGHT_CH1_INVERSE 0
#define LIGHT_CH2_INVERSE 0
#define LIGHT_CH3_INVERSE 0
#define LIGHT_CH4_INVERSE 0
#define LIGHT_CH5_INVERSE 0 |
Why do you have both LEDs and channels to the same GPIOs? And what does the "darkness" channel do? I thought it was a 4 channel light |
The LED configuration is just a quick way to turn on/off each channel (color) individually. It was my first attempt to work with RGBW light before being able to configure the channels. Now both configurations work simultanously without conflict. Regarding darkness channel, I'm not sure, but it seems to be the opposite of brightness (I know, it's quite absurd). You can see here how Smart Life (the default app) manages this device (basically the RGB interface shows Dark and Plain controls): https://www.lesalexiens.fr/labo-test-alexa/test-prise-connectee-gblife-rgbw-une-prise-haute-en-couleur/ |
You can also access individual light channels over MQTT under this kind of topic: About the darkness channel, it's absurd, indeed. |
Ok, I guess it's a better approach to use channels topic intead leds. BTW I read somewhere the darkness channel could refer to color saturation level. |
Mmm.. interesting. ESPurna does not have any way to specify the saturation only at the moment. I have added an enhancement ticket for that (#1415). |
I've recently adquired this smart socket that it's great because it has an USB port and RGB ambient light, but I can't find a custom firmware that can support that.
As you can see in the picture, there is a specific board on top for the RGB lights, but I guess it's still a ESP8266 to manage all the stuff.
The text was updated successfully, but these errors were encountered: