@Anticimex said in 
Sensebender Gateway:
MY_CORE_ONLY
Just curious, what does "MY_CORE_ONLY" do? The library mentioned that it should be enabled " if you want to use core functions without loading the framework" . What are the core functions and what is the framework?
Switching to TO92 elements is a great idea and will make soldering much easier to do. However, LE33 still has 0.5 mA supply current and will not be a good choice for battery powered sensors. The TO92 package will always be ON per spec sheet: http://www.st.com/content/ccc/resource/technical/document/datasheet/98/09/12/54/6e/d1/45/36/CD00000545.pdf/files/CD00000545.pdf/jcr:content/translations/en.CD00000545.pdf
The modification I made previously used XC6206 regulator that only requires 1uA supply current. It works pretty well for my battery powered sensors. However, it does not offer a TO92 package. It will be great if someone can suggest an ultra-low supply current voltage regulator in TO92 package.
@ted Hello! Can you share the Eagle file of your version of pcb? I mean this one: http://dirtypcbs.com/view.php?share=19651&accesskey=2e5e31a83bf6fe21510c3bc438e12df7
Sorry for the extreme late response. I've busy with work in the past half year. Hope you still find the attached file useful.
https://dl.dropboxusercontent.com/u/13998152/modified_jBoard-panalize_4x4_hole.brd
@n1ck1355
my only solution is to use two radios, one receives command from the gateway and the other sending command to the bulbs. it might be doable with just 1 arduino by using softSPI.
@n1ck1355
sorry for the delay. Here is what I learned from https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol
Basically, the mi controller will receive text string and convert them into HEX format and send it to the bulb. The text string should be formatted as the following (+ added for easy of reading, no '+' in the actual command):
ID + color + brightness + button code + seq
The ID is the ID of the bulb to be controlled, it is six byte in ASCII but will be converted into 3 byte HEX before sending to the bulb.
color, brightness and button code are each 2 byte in ASCII and will be converted into 1 byte HEX and send to bulb.
Seq is 2 byte in ASCII but it appears that you can just use "00".
To change color, you need to send a color code (e.g.: "00"=purple, "1B"=red, "40"=yellow,e tc) and using button code "OF".
To change back to white, you use "04" as color code and "13" as button code.
The detailed button code definition can be found here:
https://cdn.hackaday.io/images/1224221432724803073.jpg
Hope this helps.
@n1ck1355 @Jason-Brunk
sorry i'm been really busy with job recently. I used openhab to send the payload to V_VAR1 and S_CUSTOM. When I get home tonight, I'll post the openhab rule file so people can get some sense how to control color.
@Iraklis-Kourtis
The controller is all you need to control the lights. It does not need wifi bridge
@Łukasz-Kostrzewa
sorry for the delay. you need to send the unpair command right after turning on the light. see https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol
@alexsh1
The regulator on the board (AMS1117) consumes several mA at idle. You may need to find an alternative that has uA level quiescent current. I modified the board to use a XC6206 serial LDO (1uA standby current, see my previous post). I have the board manufactured by dirtypcb and have made sensors. Will test the battery life soon.
@Łukasz-Kostrzewa
The way I'd suggest is to modify the program to add more switches, each switch uses a different remote ID. Alternatively, you can use your controller to generate the necessary command string (with custom ID specific to the bulbs you want to control) and send it to the custom node as an ASCII string. The custom node will relay whatever command it receives to the bulbs.
@Łukasz-Kostrzewa
Each bulb is associated with a particular 'remote ID'. Bulbs having the same remote ID will repond to all commands having the same remote ID. Therefore, you can simply pick a different(or the same) remote ID to pair with a second bulb, and the second bulb can be controlled separately(or simultaneously) with the first one. I have not tried it but that should work according to the mi-bulb protocol.
The milight uses a speical command, it is not likely to be compatible with the standard RGB light module in domoticz. The information about the milight protocol can be found here: https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol
I used openhab to assemble the command string for S_CUSTOM. Using the S_CUSTOM, you can control as many bulb as you want (by using different remote ID field in the milight protocol), although I only have 1 bulb. The node receives the milight protocol in plain ASCII string and convert the string to HEX before sending it out to the bulb. Hope this helps.
@Cliff-Karlsson
I don't know. Let us know what you find out. 
To unpair, you turn on the power to the bulb and send 'off' command within seconds.
@Cliff-Karlsson
You have to program your controller to produce the command string and send it to the node. The command string is transmitted as a ASCII string to the 'custom' node. See https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol for the command format. Sorry I don't use domoticz.
@Cliff-Karlsson
thanks, the original post was updated to clarify this.
@Cliff-Karlsson
To pair, turn on the light switch, and send 'ON' command within 2-3 seconds. If successful, you will see the light flash on and off a couple of times.
The repeater-node simply relay any command it receives from the controller (I use openhab) to the light wirelessly. There is no physical wire connection between the node and milight.
Assuming the on-air protocols are the same, yes.
I only have the RGB-W light bulb and were able to control it without ever using the remote controller.
@Cliff-Karlsson
Yes, it is possible to keep track of the bulb state from the controller.
As to the switching speed, it is almost instantaneous (<<1 s). You can for sure add another node, but that will make the whole thing much more complicated to build.
@Sweebee
Do you mind sharing your library again? The link is no longer working.
I modified the design to use a XC6206 serial LDO (1uA standby current). I placed an order with dirtypcb. You can find the design here: http://dirtypcbs.com/view.php?share=19651&accesskey=2e5e31a83bf6fe21510c3bc438e12df7
Will update when I get the board on hand.
Very nice. The only downside I can think of is that AMS1117 is power hungry. Is there a pin compatible regulator with uA level standby current?
oops. I forgot to attach the modified nrf24 library.
Somehow the module that simulates PL1167 is not compatible with mysensors' nrf24 library; instead, it requires the nrf24 library found here: http://tmrh20.github.io/RF24 , which, strangely, is not compatible with mysensors. So I end up with using two different nrf24 libraries, one for mysensor and the other for simulating PL1167. To make this work, I have to change the variable/file names of one of the libraries. Maybe there is something I didn't do correctly. Anyway, if you import the following library, it should work. 0_1460766143691_RF_24-master.zip
@Cliff-Karlsson
Yes, I can control RGB color as well. The node can relay any command from the gateway to the Mi Bulb. It can implement the full capability of the original remote controller. The format of the MI protocol can be found here: https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol . The node receives the command as a ASCII string; it then convert it to HEX format and send it to the bulb.
MiLight is a radio controlled RGB-W LED light bulb. You can buy them from ebay or aliexpress for about $10-$15 a piece. The light bulb is controlled by a handheld controller. The RF chip used in these lights are PL1167 but fortunately, people have reverse engineered the RF protocol (see https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol) and have developed code to control these lights using a NRF24 radio.
I have adapted these code to control these light bulbs using a mysensors module, which also serves as a repeater node. Once it receives command from the gateway, it switches to a different operation mode to simulate PL1167 and send commands to control the LED bulb. Afterwards, the sensor switches back to NRF24 mode and serve as repeater.
The code currently supports two modes of operation: (1) turn the white light on/off using a light switch node; and (2) relay any command that is supported by the MI protocol using a custom sensor node.
You need to 'pair' the light bulb with the controller the first time using it (UPDATE: you can do the pairing using the repeater node. No need to buy a separate wifi or wireless controller). To do so, turn on the power switch and send 'on' command to the light bulb within couple of seconds. The led bulb will flash a couple of times if the paring is successful.
If you have multiple LED lights, you can assign each light with the same or different remote ID so you can control them as a group or individually.
The code can be downloaded here (also see below for required library):
0_1460251721914_open_Mi_Light_Controller_repeater.zip
@Harry-Gomez
What if you modify start.sh and start openhab from console? I'm not a linux expert; could it be that the usb driver was initiated after /etc/init.d is processed ?
@Harry-Gomez
From https://github.com/openhab/openhab/wiki/Serial-Binding
If you are using non standard serial ports you have to adapt start.sh to have the serial port included. the java command line should then include the following parameters:
-Dgnu.io.rxtx.SerialPorts=/dev/ttyAMA0
whereas ttyAMA0 is the path to your serial port. Please be aware to change all scripts you might use for startup (debug, automatic start in linux,...)
whereas ttyAMA0 is the path to your serial port. Please be aware to change all scripts you might use for startup (debug, automatic start in linux,...)
@mntlvr I'm excited to see that mysensors is working with attiny. However, when I compile your code for UNO (can't compile for attiny85 on my IDE), I see the code is about 16kb, much larger than the size of the available memory in attiny85. Did you use a different library?
