forkineye / espixelstick Goto Github PK

While diagnosing another issue, I was using a value of 25,21,2 (set by MQTT) The light did not light at all. if I disabled gamma correction, the light worked properly. So I knew that the gamma adjustment was adjusting these values down to zero. 25 is quite far from zero to get no action on the light. I would be more understanding if 2 resulted in no light. A proper gamma curve should light the light with all non-zero values. It appears that a LUT is being used similar to that published by adafruit: https://learn.adafruit.com/led-tricks-gamma-correction/the-quick-fix This really isn't a good gamma curve for lighting because there's too much deadband. This method is more appropriate for graphics. A more in depth practical guide on gamma adjustment can be found here: https://hackaday.com/2016/08/23/rgb-leds-how-to-master-gamma-and-hue-for-perfect-brightness/

Hello! Thank you for your code! I have been using it on some ESP8266 breakout boards with great success!

I recently tried using a D1 Mini board (esp8266) that seems to have trouble with the bitbanging that is used to control the pixel data line. Is it possible to rework the code to control the pixels with either DMA or UART? My problem is that the pixels will light the assigned color, but they will stay on for about 2-3 seconds and then flash off for about a second, and the cycle repeats. I believe this is because of the bitbanging on gpio2, which also has the blue led of the esp8266 module? Maybe you have some other insight as to what is causing this issue?

Here is a thread detailing some work done on WS2812 leds using DMA on the ESP8266 (and D1 Mini) boards, as well as a link to the Makuna NeoPixelBus Library that seems more up to date for current ESP8266 boards.

Makuna/NeoPixelBus#88

https://github.com/Makuna/NeoPixelBus

If it's not possible to incorporate a DMA option, perhaps it is possible to change the pin that the bitbanging occurs on?

If you enable a testing mode, e.g. Rainbow, then reload the interface it looks like testing mode is disabled but the output isn't responding to incoming data.

Options.

1. Update interface to show current testing status (would require a way for the client to get current test settings, e.g. colours, column counts, etc)
2. Disable testing mode on a new connection. As current testing status is sent to client on load a notification could be shown that testing is disabled.

I think on balance Option 2 might be the best choice. It would be simpler than Option 1 and I think an unexpected exit from test mode is better than unexpectedly being in test mode. Again I'm happy to do this once it's decided on the best route.

Should we ensure any missing data is set to black ?

Add the ability to multiply pixel inputs for "grouped" outputs. For example, "group by 10" would generate 10 pixel outputs for every pixel input (3 channels) received via E1.31.

I loaded the newest version on my 3 Pixelsticks from renard. Works great. Loaded it on the renard ESP module and it works. Tried to go into serial settings and it say DMX not Renard. Tried to change and save but goes back to old settings. Most of the fields will not stay. Is this a problem????

From http://forkineye.com/espixelstick-v2-assembly-usage-manual/#comment-1593

i found one silly spot on your “ESPSFlashTool.jar”
when ssid & password’s value return values in string type make sure all characters are convert in string.

Ex:- i have 2 ssid in my Lab
esp is trying to join “Kmlu0027s_Lab” rather then
SSID 1:- Kml’s_lab
SSID 2:- Kml’s_Guest

& “u0027s” >> is UNICODE value of ( ‘ )
https://chars.suikawiki.org/string?s=%5Cu0027

The Github version of the feature-ws2801 wasn't able to compile, so I merged it with the master. This is working as expected now. But as I am using APA102 I was wondering if you are going to add support for this. The leds are full white now and I am not able to control them.

I am using a Wemos d1 mini. Connected data to gpio 2 and the clock pin to TX.

I have a string of 80 leds ws2812b hooked up to an esp-01e that is loaded with ESPixelStick 1.3. I've successfully managed to set everything and can run sequences from xLights (4.2.25) & FPP (1.7). But there is one big problem that I've failed to fix.

With any sequence I run the whole string flickers with random colors in during the sequence. As soon as no more data is send the flickering stops (and the leds keep their last color). So the issue somehow seems related with the processing of data.

One thing that sort of helps is to set the Pixel Count / PPU somewhere around 50 or lower. It doesn't fix it but at least the flickering rarely occurs then.

Also turning Gamma map on/of makes a difference. When Gamma map is on the flickering is much less, it looks like only some pixels flickr. Whilst when Gamma map is off the every pixel seems to flickr.

I've ran out of clues how to debug / fix this issue so I hope anyone here can give me some pointers.

It would be nice to have a mode where the ESPixelStick code could be set up to be able to provide a digital trigger to be used for (external) relay control. I'm thinking simple on/off control of a power circuit. This would likely be more relevant in MQTT mode, but I suppose it could be equally valuable with an sACN data source. I realize that with the current ESPixelStick V2 boards, this is limited to only one output. Maybe two, I don't know if the C line is connected to an output of the ESP.
If going down this route, a logical extension of the idea would be to also allow these to also be used as inputs. In this case, sACN wouldn't be relevant, but it could certainly publish an MQTT topic with their state.

Hi just trying to program a Wemos D1 mini, with your firmware.
All goes good.
But when i try to connect my browser to it it says "page not found"
when i try "192.168.0.199/conf" i get this
{"device":{"id":"ESPixelStick","mode":0},"network":{"ssid":"Aaron","ip":[192,168,1,10],"netmask":[255,255,255,0],"gateway":[192,168,1,1],"dhcp":true,"ap_fallback":false},"e131":{"universe":1,"channel_start":1,"channel_count":510,"multicast":false},"pixel":{"type":0,"color":0,"gamma":true}}
Its like is not have the html files and that upload says all good?

Maybe a checkbox to enable it and leave the dropdown to focus on running effects ?

What do you think ?

Sometimes, configuration data fails to show up in the web UI. Root cause is unknown, however configuration receipt verification / re-querying should be done to prevent this from happening.
Example: https://diychristmas.org/vb1/showthread.php?7969-ESPixelStick-WiFi-Renard-amp-Pixel-Control-from-XLights&p=88776&viewfull=1#post88776

I was trailing this firmware with some new ws2813 strip and found it to be acting intermittently like it was having a data problem.
After some research it seems while for the most part these new chips are similar to ws2811, the reset time between frames is longer (possibly to allow it to refactor the data and pass it though on the backup line) so while ws2811 supports minimum 50us reset time, the ws2813 chips require 300us as per these comments http://doityourselfchristmas.com/forums/showthread.php?44920-connect-2-kinds-of-pixels-after-each-other-possible-or-not&p=442708#post442708
All ws281x chips should work at 300us so it might be as simple a fix as changing line 73 in PixelDriver.h to 300L.
Or split up the selection dialog and add in a new ws2813/ws2818 option.

If you don't beat me to it, at some point in the new year I will learn how to build from source and test this myself :)
Thanks for the awesome firmware and making it open source.

When loading the web site for configuration, I was presented with a message indicating a Web Socket failure. Upon further inspection, socket server was returning a 500 error.

I was able to get the Websocket to function again by using the older version of ESPAsyncWebServer from 11/21/16.

Well, here's the result of hours lost today. Bought some ESP-01 from Amazon : https://www.amazon.com/gp/product/B01EA3UJJ4/ref=oh_aui_detailpage_o02_s01?ie=UTF8&psc=1

And they would not boot after getting flashed by Arduino. Even 'Blink' doesn't work.

After troubleshooting and pulling hair out, seems the flash chip only supports DOUT mode. Google reveals more people running into the problem. So if we release binaries for future releases, we may have to have an option to let the user select flash mode and just instruct them to cycle it till one works for them.

Hi,
Sorry if this is not the place, I didn't find your forum to post this request.

Thanks again for sharing this great software. Our Xmas tree was magic this year as I used your software on a Wemos D1 mini with XLight sequencer. Work perfectly.

I was wondering if it is possible to use other available GPIO on the ESP8266 and assign it to a universe/DMX Channel. My goal is add a relay or dimmer (if PWM possible) to control other normal light.
Thanks

Please add MQTT support,

so people will be able to control their leds via a home automation controller (Openhab, Domoticz, Node-red, etc.). MQTT is now a standarized protocol. And you could expose it in webconfig - https://github.com/ESP8266nu/ESPEasy these guys use same type of webconfig and have MQTT for their sensors.

http://doityourselfchristmas.com/forums/showthread.php?39166-ESPixelStick-E1-31-WiFi-Pixel-Controller&p=413124#post413124

I'm guessing the latest commits have caused this:

I suspect the web hi now only gets RGB colour order so it's reordering code can be stripped away.

If so, want a pull request to fix the web ui ?

Hi there - great work on this project. It's so good I'm
Basically I'm about to kill my own and extend this instead

I've just added e1.31 support to https://github.com/hyperion-project/hyperion.ng/pulse and it works great.

Some Hyperion users need >170 LEDs so I need to look at some options and I'm curious as to your thoughts on some approaches

1. we already have a raw protocol which is good for about 500 LEDs (limited by no UDP reassembly support in the ESP). It should be easy to add another listener.
2. use multiple universes ? Could we map universe 1 to the 1st 170 LEDs, universe 2 to the next 170 LEDs and so on?
3. violate the DMX protocol and simply send more LEDs ?

Thoughts on preferred approach both in general and what you'd consider merging ?

Thanks again !

I'm having issues using multicast mode through Layer 3 switches, routers and APs. It works for a few minutes, than all nodes stop receiving data at once. Power cycling the ESPs fixes the issues for another few minutes.

If I rewire the network between my show data source and the AP to use layer 2 switches it works fine.

I can't confirm this because I don't have anything to capture WIFI traffic to confirm, but i suspect after the timeout my layer 3 switch and router will send out a IGMP query request, get nothing back and then stop all multicast data from transversing. This is probably an issue with the ESP multicast driver, but i wonder if we call udp.beginMulticast() at a set interval we can work around the issue by sending IGMP join requests more than once.

I first ran into this problem with a simple setup, and realized just my AP was doing IGMP snopping and after not getting any responses to query messages would also stop letting the multicast data through.

And leads to a crash loop.

I suspect the oneifidosconnect is being called and trying to auto reconnect which won't work

Sorry somthing happent.
No i am runnen on a windows system

With v2 update multiple universe output became practically unusable.

1. Calculation of offsets based on UNIVERSE_LIMIT constant which is equal to 512, but in fact there is 510 usable full RGB channels per universe. Since crossing universe boundary within one pixel is practically unusable in real world and commonly used software like Jinx! or QLC+ just skips channels that cannot be used for pixel data at the end of universe, ESPixelStick shifts colors of each next universe (in v1 this scenario worked just fine, to be said).
2. When Start Channel setting is > 1, random flickering renders instead of actual pixel data on universes after the first one. Start/end position calculations in pixels buffer were correct only for zero offset scenario.

See #24 PR for proposed fixes for both problems.

Hey there,

I'm having some trouble compiling ESPixelStick-3.0rc3 using Arduino 1.8.5 and ESP8266 2.4.0-rc2. I installed all the required libraries straight from github. After making the change to #include <ESPAsyncE131.h> I'm getting a lot of errors related to RingBuf *pbuff

I couldn't get them to look reasonable here so here is a pastebin of the whole thing

One thing I wasn't able to get back and solve before the merge is tracking packet errors in serial mode. The code will crash if error tracking statements are uncommitted. I'm sure it's a simple mistake on my part but I have not been able to fix it yet. Its stable now, but does not do sequence error tracking in serial mode.

Currently I'm running the latest master branch. I see the option to update the firmware OTA. Now I'm just wondering which file I should upload as the data/www files have to be uploaded separately to SPIFFS.

Does this serve any purpose that hostname can't fulfil ?

A) New interface is super slick, great job.
B) I had some trouble getting gulp to work again, I had to individually install every module included at the top of the gulpfile.js. Too tired to figure out why. If it's not my fault, maybe we should update the instructions?
C) The pixel refresh rate display is showing NaN for me. See screenshot.

Once again, awesome.

was this ever added? will it ever be?

It would be nice to have ArtNET support. I already have code that acts as ArtNET node and outputs to serial if that helps.

I was replacing my trusty ESP01e board this weekend that had run on firmware 1.3 for over a year through storm and weather in my garden without any problems. I switched to a Wemos D1 mini (clone), flashed firmware 2.0 and I ran into a problem in which the lights would flicker randomly during an animation. At first I thought I was the same problem I had with the ESP01 in the beginning where I flashed on 80mhz instead of 160mhz but that wasn't the case.

The problem was that I ripped out the logic level converter 3.3v <-> 5v that I used in the ESP01e setup and connected the data channel straight to the Wemos D4 pin (GPIO2). I had driven (long) ws2812 strings straight from the Wemos with succes earlier so I though the logic level converter would make things just more complicated. But in this specific case removing the converter caused the string to flicker. Probably the high voltage provided on the data line by the wemos isn't stable enough in this case. Not sure why it works without any problems in other situaties but my conclusion isn that without the logic level converter you can get lucky but don't bet on it.

(Wouldn't this be something for a/the wiki?)

Increase WS2811 reset timing from 50us to 250-300us due to IC production change - https://www.facebook.com/paul.zhang.7927/posts/696424867210866

If the device is power cycled while in a state set by MQTT, the device will return to sACN mode and any set color will be lost. The MQTT values should be persisted in NVRAM so that the set color and on/off state is restored on boot.

When using static IP configuration, the network status tab displays the gateway for the netmask.

Hello,

I have used your other E131 code and applied the fix that someone has commented on here to stop the sACN start codes from flashing all channels at the priority setting intermittently.

However, the ESPixelStick code is doing the same but I cannot figure out how to ignore the start code packets.

Is someone able to point me in the right direction, or apply a fix directly?

Thanks

I'm attempting to get universe spanning working, I have a spiral tree with 336 WS2812B's, if I set it to Universe 9 (this fits with the rest of my configuration), PPU is set to 170 and pixels is set to 336, the performance drops incredibly, maybe 1-2fps and it doesn't listen to universe 10. If I keep the number of pixels at 170 or below it behaves just fine.

If you enable/disable multicast on the Device Setup tab and save changes the change isn't implemented until the next reboot.

Options.

1. Move Enable Multicast to Wireless Setup tab which forces reboot on change.
2. Detect change of setting and force reboot (need to tell the client that it is now waiting on a reboot rather than an update)
3. Force Multicast enabled it still responds to unicast in that status.

I think option 1 is the best unless you think 3 wouldn't cause any issues. I'm happy to implement any once it's decided.

Can I ?

I need the structure definitions in some other work I'm doing and this would make it easier

I am on the new v3.0 beta. I upgraded from 2.0 with no problems. I am new to Pixelstick. I tried to switch the SSID and password from the Web UI, but it will not allow me to save it. Is that a bug or as designed?

It seems that an espixelstick with a current valid config will retain this after an over the air reflash.

Is this a feature ?

Could we make it optional ?

Having DMX output option would be awesome.

I've been testing w/ an ETC Eos system, Luminair, as well as MAD Mapper, and they don't seem interface well with the Pixelstick Firmware. I can't get the PixelStick to respond to any of these Pro Level aplications/hardware without putting the Pixel Stick into multicast mode which of course currently supports one universe.

None of these pieces of software have a unicast mode. Is there planned support for multiple universes in muliticast? I'm trying to control a 256 Pixel Panel with a single controller. using either an EOS lighing console or MAD Mapper.

Would it be possible to add the possibility in your software to be able to configure several types of led according to their position. For example 1 to 20 RGB and then 21 to 50 BGR then 51 to 70 RGB.

Thank's

Web pages that reside in flash crash went sent by the server. This issue only occurs when built on Linux and Mac machines. There is support sending pages from PROGMEM in the ESP8266 Arduino WebServer library, but it's not yet in the stable release.

Or they don't take effect

Perhaps move the config to the Wireless section ?

It's a network thing and there's more screen real estate there than the device tab (especially with my PWM stuff!)

I was working on a similar project but have decided to ditch it and base it on yours.

Below is what I have done or wanted to do that yours doesn't. Are you interested in PRs or violently against:

1. UDP raw protocol support - listen on another port which just has unframed raw RGB data. (done)
2. a UDP ascii interface to control and query status (done, but mostly useful for testing)
3. web interface to view current led colours (cute but more diagnostic than useful)
4. simple web UI to directly manipulate the colour of the strip (not started yet)

Thanks !

Hello!

I've previously used V1.3 of your firmward on some D1 Mini's (esp8266-based) and was able to compile in the arduino ide with no issue.

I have installed all of the libraries that are listed on the github page, but keep running into errors when compiling in the ide. Specifically, it is looking for an E131async.h file to include but can't find one. Any suggestions? Would this be located in a library and somehow the library didn't install properly?

Is it also necessary to follow up build/flashing with uploading web files to the device, or if I'm custom compiling in ide and uploading that way, are they already included? When I compiled and used V1.3, everything was done with the compile and upload button in the ide and it just worked from the get go.

Also, am I able to flash the pre-compiled firmware for a PixelStick on one of these D1 Mini's? Or do I need to custom compile my own build?

Thank you for your help!