Hello,
i programmed different (macros) presets. But i can only define one of them as ‘alexa on’ and one as ‘alexa off’ preset. Is it possible to get more?
My idea is to use different voice commands for different scenarios.
Now i had an idea. wled is integrated as hue. And the hue-colour-definitions in alexa are not all usefull (e.g. rose, lavendel, lachs). And now my question to @Aircoookie and all the other developers, would it be possible, to define a preset that can be called by a colour change. Thanks to the api-integration in presets this would open “new worlds”
Hi!
I don’t know why I get an email about your post now, sorry for not getting back for the last 8 MONTHS
Seeing that this is still relevant, executing certain presets/macros when setting some “useless” colors could be a cool idea. Of course you kind of need to create a mental map as to which color corresponds to which preset, so it’s more of a workaround. What I would love most is a proper WLED Alexa skill that allows running presets in an intuitive way. The problem is that Amazon still doesn’t support that without a cloud infrastructure
I’ll think about color-activated presets!
That is the magic of the internet! No, its because i edited this post today and included your name.
thanks for your response!
a skill would be the best solution but i understand the cloud problem. normally a few presets would be enough and the useless colors are a thing I can good give up.
Did you get any further on this? When I tell Alexa to change color it changes one of the colors in the preset animation running.
It doesn’t clear or set the solid color. Is there a way to set something.
@Aircoookie Maybe this discussion should be moved to Enhancements Category?
@siggel I have tried repeatedly to use the flasher to pull down both versions of the D1 Mini bin file you created, and the WLED SSID never shows up. In fact all that happens is a boot loop on the D1 mini device that keeps telling me the checksum.
I’m using ESPhome Flaster 1.1.0 because all other versions are blocked by Windows currently. I really want to use your version but I’m not sure how to get it loaded on my device. Can you help please?
Thanks
@kirktindel Only times that I saw such misbehaviour was when I reused the D1 mini with very different firmwares (WLED and non-WLED ones) without erasing memory first. Have you tried flashing the original WLED image first and did that succeed? If that does not work either, the problem seems to be in your setup and you should next erase all previous data (for my D1 mini I googled for an empty 4MB image, other tools may have built-in erasing functionality). Then flash and configure the original WLED again to be sure that your setup works. Finally flash my image over it (which will then find and use the original WLED configuration).
Note: Flashing and configuring the original WLED image intermediately just helps to be sure, that the general flashing procedure works. It is no prerequisite for flashing my special Alexa version.
@siggel Yes, this is a known working ESP8266 with 4mb memory. When I use that same ESP Flasher program to upload the latest WLED release, it works fine and I see the WLED-AP SSID even before it’s been power cycled. When I use the two bin files on the page you referenced in the link above, it seems to push the software okay but I notice the following behavior:
#1: Blue LED on the board doesn’t stay lit, only blinks for about 1/8th of a second every ~7 seconds (it stays lit solid with current WLED release)
#2: WLED-AP SSID never shows up (it shows up on current WLED)
#3: The ESP Flasher serial monitor shows repeated resets of the ESP8266 even after power-cycle
(text under “Showing Logs” repeats every few seconds):
Using ‘COM3’ as serial port.
Writing at 0x00078000… (100 %)Wrote 746320 bytes (504504 compressed) at 0x00000000 in 45.0 seconds (effective 132.7 kbit/s)…
Hash of data verified.
Leaving…
Hard Resetting…
Done! Flashing is complete!
Showing logs:
[07:58:40]s$[07:58:40] ets Jan 8 2013,rst cause:4, boot mode:(3,6)
[07:58:40]
[07:58:40]wdt reset
**[07:58:40]load 0x4010f000, len 3584, room 16 **
[07:58:40]tail 0
[07:58:40]chksum 0xb0
[07:58:40]csum 0xb0
[07:58:40]v3969889e
[07:58:40]~ld
[07:58:48]
[07:58:48] ets Jan 8 2013,rst cause:4, boot mode:(3,6)
[07:58:48]
[07:58:48]wdt reset
**[07:58:48]load 0x4010f000, len 3584, room 16 **
[07:58:48]tail 0
[07:58:48]chksum 0xb0
[07:58:48]csum 0xb0
[07:58:48]v3969889e
[07:58:48]~ld
[07:58:57]
[07:58:57] ets Jan 8 2013,rst cause:4, boot mode:(3,6)
[07:58:57]
[07:58:57]wdt reset
**[07:58:57]load 0x4010f000, len 3584, room 16 **
[07:58:57]tail 0
[07:58:57]chksum 0xb0
[07:58:57]csum 0xb0
[07:58:57]v3969889e
[07:58:57]~ld
@siggel Also, if it matters - this is the black PCB ESP8266 30-pin 2-button. I’ve got probably 30 or 40 of these laying around, I’ve tried on multiple different boards and the most current WLED release bin files works great, the ones I actually want (yours) have this same behavior. I asked a friend to try on his and he gets the same thing. Can you try it on one of yours and see if you also get the same behavior? If not, I’m wondering what may be different about your hardware? The one I’m trying this on now was just taken out of the package brand new as of a few minutes ago.
Oh, and one last thing… thank you! I can’t wait to get this working. What a great idea!
@kirktindel Problem confirmed, please see my github repo issue #1 for updates
Version V3 published in my github fork. Looks like also my early posts here about that fork for extended Alexa capability are considered unwanted promotion now.
I’m really willing to join my fork back to the original repository but my implementation focused on D1 mini only. I came along a lot of branches in the code (for other devices?) that I neither understood nor could test them. So before merging back some things should be clarified that I repeat from one of my deleted posts:
- What do you think about this proposal in general, are there technical obstacles that I did not care about?
- Do you prefer additional device names in the Alexa configuration or what do you think about the idea to directly reuse the preset names?
- Anyone wanting to help out here? My solution serves all my son’s needs but there seems to be a certain demand in the community for this feature so I’m willing to contribute further. While I can try some parts on my own, I think configuring and storing further names somewhere in the address space would have to be decided and implemented by someone more familiar with the address layout. And my focus is only on Alexa, I have no idea whether it could/should be applied to other interfaces too.
.
@siggel Do you have a link to your github so I can check it out? I’m not quite clear on your implementation of this, but is it something like the feature request I’ve posted here?
Also, I have Hue lights too and in app you can set custom scene names as detailed here. Then you say to Alexa something like “turn on concentrate on bedroom light” to enable that scene. It may be that’s only possible with a proper Hue hub however. Is that what you have implemented instead?
Thanks.
Andy
Hi Andy,
probably my fork would help with your feature request. Some of my previous posts here had been deleted because of “promoting” my link, so please just look for the repositories of my nickname there and look into the releases. Attention: I have only D1mini available there.
What my fork basically does: For each of the first nine presets in WLED it will create a separate Alexa device with the same name. So for the example in your post you could say “Alexa, turn Rainbow Gutter on” If you want to change brightness etc. that should work via the normal Alexa device name configured in WLED as the original WLED Alexa device is still there working with the original code.
Hope I could help,
siggel
Nice. Thanks. My github-fu was weak before! The deleted posts must be why this thread seemed fragmented. Hopefully aircookie will eventually integrate the feature or something similar into the main project.
I use the wemos d1 mini too (or the generic copies from Aliexpress anyway).
Thanks very much.
Andy
Apologies first off for reviving an old thread.
Since github.com/siggel/WLED
is now nearly 2000 commits behind, I’m wondering if there’s an alternative approach?