Closed btsimonh closed 1 year ago
DeviceGroup support, at least for power, dimmer value, and rgb/cw channel syncing. https://github.com/arendst/Tasmota/blob/development/tasmota/support_device_groups.ino
I don't know enough about embedded device programming to create a PR, but you could reference my work in progress python project here if the tasmota ino is confusing (I still need to add ack tracking logic and rgb channel support) https://github.com/LightConstrue/TasmotaDGR
LED Driver support, I have a cloudcutter bulb that uses 2 pins to a led driver. I still need to dissect the bulb further to find out which it is, there are a few led driver drivers in tasmota that could be referenced for this.
DDP support for rgb bulbs: https://github.com/arendst/Tasmota/blob/development/tasmota/xdrv_04_light.ino#L1668
there's also an addressable led ddp function in another file, but would need addressable led support first.
@MoogleTroupe - thanks for posting :). I had a quick look at TAS DeviceGroup - it's basically a multicast protocol to share values? I've never used in it TAS, but do have two TAS tuya dimmers which could link up, and two RGB LED bk controllers, and one RGBWW bk controller.... I'm not sure about multicast support in the BK SDK yet. The 'DDP' stuff is a simple UDP control... Any idea what the actual protocol is? (could it be Lifx?)
I had a quick look at TAS DeviceGroup - it's basically a multicast protocol to share values?
yes, it is to share state (with selective control on inbound/outbound).
I've never used in it TAS, but do have two TAS tuya dimmers which could link up, and two RGB LED bk controllers, and one RGBWW bk controller....
set this on your dimmers and then test changing one, watch what the other does automagically:
BackLog SetOption85 1; DevGroupName test; DevGroupShare 3,3
I'm not sure about multicast support in the BK SDK yet.
the Tuya app uses broadcast to find these devices, I'd be surprised if there isn't also some kind of multicast thing in the sdk.
The 'DDP' stuff is a simple UDP control... Any idea what the actual protocol is? (could it be Lifx?)
DDP is a standard light protocol, like DMX and e1.31 and art net. DDP is mainly, a simplified one. It is supported by WLED, Kauf bulbs, xLights, Tasmota, and other projects. Supporting it should be a special mode that bypasses saving changes to flash or anything, as by design it will be accepting roughly 20 packets/changes per second for light show purposes.
@btsimonh our sdk supports multicast, you just need to enable igmp flag in the lwip 2 library. I think that all our platforms based on lwip 2 can support multicast. I am not sure about lwip 1 platform - xr809. I am already doing prelimary device groups testing
@MoogleTroupe sharing power state, brightness, color will be support. Device groups incoming and outcoming flags as well. Anything else important?
Hi,
I just set up a power socket with BK7231N
(brand: Nous A1 - I have photos of it's guts if anyone interested 😀 - getting access to serial port pads is rather difficult without decent soldering skills , programming via python only).
For tasmota compatibility I miss those options (in MQTT) from Tasmota:
Topic
- define device name in MQTT - currently it's called ShortName
(I think it should be renamed to keep up with tasmota 🙃 )FullTopic
where I can define layout with %prefix%
and %topic%
- I have custom FullTopic layout (e.g.: esp/theRoom/%topic%/%prefix%
- different than tasmota use by default). Tasmota have 3 prefixes: [1] cmnd
, [2] stat
, [3] tele
- those can be configured but for now 99,9% ppl keep those default 😄 .POWERx
where x is output number, accepted values should be ON
or 1
, OFF
or 0
(text state should be case-insensitive). This should be in topic: <FullTopic>/POWERx
(where %prefix% == stat
),<FullTopic>/POWERx
(where %prefix% == cmnd
), with value ON/OFF/0/1
to control output (if output have negative logic then inversion should be taken care in firmware) .Most of this already mentioned @btsimonh
Basically I'd love to get at least possibility to define my own FullTopic
(or it's base?) because right now this my socket have node at root on MQTT broker (\Socket\...
, while I would want this to be \home\bkt\Socket\...
) what breaks down the logic of my configuration.
@saper-2 Any chance you can share how you disassembled your Nous A1, after removing the triangle screw from the front, I don't seem to be able to pull out the circuitry, and I don't see any more screws. Also where are those serial port pads? Thanks.
@saper-2 Any chance you can share how you disassembled your Nous A1, after removing the triangle screw from the front, I don't seem to be able to pull out the circuitry, and I don't see any more screws. Also where are those serial port pads? Thanks.
You can't pull it out 😑. I desoldered top board with socket contacts and bkt chip. Under this white silicone are pads to which is soldered vertical board that connect bottom board (relay+power supply) to top board, and there is a single wire soldered to "H1" pad too (it's rather thick wire). Best attempt to remove top board is to desolder it first from that vertical board, peel off antenna, and once board "wiggles" , grab with pliers on socket contacts, start heating with solder iron H1 padn and pull the board using pliers, then you can remove solder from the H1 easily on desk. I used transformer solder iron because it can heat up faster bigger things (that draw more heat from solder iron tip). Once you remove solder from it you can remove top board with bkt. Don't forget to peel off the wifi antenna from case.
@saper-2 Any chance you can share how you disassembled your Nous A1, after removing the triangle screw from the front, I don't seem to be able to pull out the circuitry, and I don't see any more screws. Also where are those serial port pads? Thanks.
You can't pull it out 😑. I desoldered top board with socket contacts and bkt chip. Under this white silicone are pads to which is soldered vertical board that connect bottom board (relay+power supply) to top board, and there is a single wire soldered to "H1" pad too (it's rather thick wire). Best attempt to remove top board is to desolder it first from that vertical board, peel off antenna, and once board "wiggles" , grab with pliers on socket contacts, start heating with solder iron H1 padn and pull the board using pliers, then you can remove solder from the H1 easily on desk. I used transformer solder iron because it can heat up faster bigger things (that draw more heat from solder iron tip). Once you remove solder from it you can remove top board with bkt. Don't forget to peel off the wifi antenna from case.
Awesome! It worked. I gently hammered the internal components out with a hammer, and it worked. @saper-2 What python script did you use to flash the firmware? I tried with hid_download_py-master but no luck. Do you need do press any buttons on the device or change the default baud rate or something for this to work? Also, I'm using the firmware "OpenBK7231N_QIO_1.15.121.bin" with this, but first I'm trying to read the existing firmware, but it says, "Cannot get bus", even though I can see RX/TX output.
EDIT: Never mind, a bit of wiggling with the cables got the flashing process working and I have it flashed!! Awesome! Thanks for the help!
@rkkoszewski Awesome! It worked. I gently hammered the internal components out with a hammer, and it worked. @saper-2 What python script did you use to flash the firmware? I tried with hid_download_py-master but no luck. Do you need do press any buttons on the device or change the default baud rate or something for this to work? Also, I'm using the firmware "OpenBK7231N_QIO_1.15.121.bin" with this, but first I'm trying to read the existing firmware, but it says, "Cannot get bus", even though I can see RX/TX output.
EDIT: Never mind, a bit of wiggling with the cables got the flashing process working and I have it flashed!! Awesome! Thanks for the help!
I somewhat have bad feelings about using hammer with electronics , especially one that control 230VAC with few-Amps current. Well that's your choice 😃
I think I flashed it like described here: https://github.com/openshwprojects/OpenBK7231T_App#flashing-for-bk7231n , but I don't remember exactly. I think you might need to hold down or short something to GND to enter bootloader 🤔 . I very likely used a RPi that was lying around not used, and ofc ft232-uart module 😄 ( so I certainly used uartprogram
command) - I did it only once. Since then I just avoid all non-esp based devices - I mostly gone already in ZigBee & z2m - whenever I need for some smart switch/relay I buy zigbee one. 😁 I managed to hunt down 2pcs SP111 in September in local mediaexpert 😁.
Also I think I read somewhere, that you can't read flash from BK7321N - but as you probably noticed that I didn't care a 💩 about it - I just hate all cloud-based software/firmware (especially chinese one 😛 ). If I'd not success flashing bk7231 then it would be just next e-waste 🤷♂️ .
Few months has passed and now we have full Tasmota JSON emulation. Even ioBroker Sonoff plugin works. The get-reply MQTT system also works. The POWER, Dimmer, Color, etc commands are also working. Tasmtoa Control is compatible with OBK now. Tasmota Device Groups are also supported.
I think it's safe to close this issue now. Much more cool stuff is coming soon!
https://www.youtube.com/watch?v=x4p3JHXbK1E&t=3s&ab_channel=Elektrodacom
What do we NEED?
we currently have MQTT commands, specifically
cmnd/<name>/CMND
: where CMND is case insensitive.cmnd/<name>/POWER
accepts 0-100 for setting channel 0cmnd/<name>/POWERn
accepts 0-100 for setting channel ncmnd/<name>/color
accepts #xx or #xxyy or #xxyyzz or #xxyyzzaa ox #xxyyzzaabb Each 2 digit hex sets a value in a PWM channel in channel order. 2 digit hex is converted from 0-255 to 0-100 to set the channel.We currently do not publish TAS style (i.e. no
stat/<name/CMD
Please attach comments here for 'nice to haves'....