mikew

Hi Theo, I've been fighting through some other issues with 2 remote master brick+wifi stacks where they are dropping off the network for some reason. I have a feeling that my access point isn't playing nicely with them for some reason (or seems to get confused until I reboot 1 of the stacks and then the other one miraculously re-appears on the network). Anyhow, to remove the no route to host messages I went back to basics with my openhab config and only configured the red brick running openhab and the stack controlling the LED strip. Of course it worked perfectly, so I put back my entire config and it continues to work flawlessly. I made one change between starting this thread and testing your update, which was to update my install from 1.8.1 -> 1.8.3 to get the Hue updates. At this point, the only thing that comes to mind is a corrupted jar file that was manifesting itself in the LED operations but not the calls to Temp/Humidity bricklets (I haven't included other bricklets into Openhab yet, so maybe those would have been weird as well). I didn't see anything new related to Tinkerforge in the 1.8.2 or 1.8.3 in the OpenHab release notes. Thank you for all the support in trying to help identify this strange problem. Mike

Hi Theo, While trying to work on this, I got my config back to a simi-working state, but was logging: 2016-05-28 01:55:50.571 [ERROR] [.t.internal.TinkerforgeBinding] - COMMAND no tinkerforge device found for command for item uid: oVW subId: Kit_ledgroup1 2016-05-28 02:02:38.873 [ERROR] [.t.i.m.i.MBrickletLEDStripImpl] - "leds" option missing or empty, items configuration has to be fixed! everytime I tried to do anything with the LEDs. I stumbled upon this link https://github.com/theoweiss/openhab/wiki/Bricklet-LED-Strip and the config sample there is working perfectly: Color led1 (Colorize) {tinkerforge="uid=jGu, leds=0|1|4-6|8-9, colorMapping=rbg"} Not sure why the updated wiki documentation wasn't working for me, but it now is with proper color mapping. Thanks, Mike

Hi Theo, I cut and pasted pretty much straight out of the openhab binding tutorial: This is my kitched LED strip: tinkerforge:Kit_ledstrip.uid=oVW tinkerforge:Kit_ledstrip.type=bricklet_ledstrip tinkerforge:Kit_ledstrip.frameduration=100 tinkerforge:Kit_ledstrip.chiptype=ws2812 tinkerforge:Kit_ledstrip.clockfrequency=1000000 tinkerforge:Kit_ledstrip.colorMapping=brg <-- changed to my mapping order tinkerforge:Kit_ledstrip.subDevices=Kit_ledgroup1 tinkerforge:Kit_ledgroup1.uid=oVW tinkerforge:Kit_ledgroup1.subid=Kit_ledgroup1 tinkerforge:Kit_ledgroup1.type=ledgroup tinkerforge:Kit_ledgroup1.leds=0|1-43 In my items file: Color led1 "Counter Light" <slider> (GF_Kitchen) {tinkerforge="uid=oVW, subid=Kit_ledgroup1"} Yet, when I connect to OpenHab, it shows the same colors as if I use the brick viewer and try to set them via RGB values, it doesn't want to re-map them to the specified color mapping of brg. Thanks, Mike

I saw a thread from 2014 about the LED Bricklet not mapping the colors correctly to the WS2812, but didn't see a fix for it. I am having the same issue with the strip I just connected. It seems that mine is wired for Blue-Green-Red. If I used brick viewer, I only see the ability to test RGB format. How do I tell the bricklet the proper order of the channels? I also wanted to integrate this into OpenHab and tried setting this via: tinkerforge:ledstrip.colorMapping=bgr but that seemed to have no effect. I've double checked and my master brick and all the bricklets are on the latest firmware. Thanks, Mike

Hi Equinox, Thank you for the clarifciation about powering it while connected to my PC as that helped me narrow down the issue. As I was testing, I found out that it did not like the hyphen character my original SSID name. The only restriction I found on the SSID in the documentation was "The SSID can be 32 ASCII characters long (quotation mark is not allowed)". Thanks, Mike

Hi, I'm trying to get a very basic stack working over wifi. So far it is just the master brick, the wifi-extension, and a temperature bricklet. I've connected the stack to my laptop and can configure the wifi extension for a DHCP client, entering in the appropriate SSID and passphrase, but the green light for associating just keeps blinking. I've tried it powered from my laptop via USB and from a 2A 5W wall wart to rule out a power issue, but it continues to sit in the associating state. I've even removed the bricklet, but have the same issue. How do I troubleshoot this issue to see where the problem lies? I'm testing within ~10 feet of my access point. The wifi extension is on top of the master brick. If I set it to AP mode with a static IP address, the green LED continues to blink and I do not see the SSID being broadcast. If I use the API to poll the master.get_wifi_status and the return values are: WifiStatus(mac_address=(0, 0, 0, 0, 0, 0), bssid=(0, 0, 0, 0, 0, 0), channel=0, rssi=0, ip=(0, 0, 0, 0), subnet_mask=(0, 0, 0, 0), gateway=(0, 0, 0, 0), rx_count=0, tx_count=0, state=2). Thanks, Mike