activate servetickle via python about blink1 HOT 13 OPEN

well it did not get resolved at all -since there is no "update" for the existing blink(1) mk1 - u have to live with the slight blink - but be shure to change the order of the commands.

first: activate the servertickle
second: set the color you like.

another hint: set the servertickle timeout at least to double the time of the time you send the live-signal - so the pattern does not start, if you just missed a couple of millisecs for the live-signal.

cu
gsynedra

from blink1.

OK, i found out that the servertickle resets the color to none - can i prevent this?

i want blink(1) to display green until i instruct it otherwise, but still have a servertickle all 3 seconds.

currently i reset blink(1) every 2 seconds with the servertickle, and have to set it to green again - which gives me some nasty pulsing of the led.

from blink1.

so basicly my question is:

why is there an "off()" command in the firmware when executing the servertickle?

from blink1.

The servertickle function is meant to be a deadman's switch for an alert color pattern to play, with the assumption that normally the blink(1) would be off, or being periodically set to another color. If the "off()" wasn't there, there's the chance a slightly delayed turning off of servertickle would put the blink(1) in a state of showing an alert color when the server is actually fine.

The main design goal was to allow a daemon / cronjob something like this:

while [ 1 ] ; do
blink1-tool -t 5000  --servertickle 1   # turn on servertickle to timeout in 5 seconds
blink1-tool -m 0  --green                  # otherwise everythings fine
sleep 5
done

But now that I see how you're using it, I think it would be good to have an option to disable the "off()". We're working on an updated version of blink(1) and I'll see about including that in the new firmware.

from blink1.

well, exactly what i'm doing!

i just tried your approach, and i have the same bone to pick!

if i'm not mistaken, the desired output of your script would be, that it continously shows the green led, until the script dies.

but it does not do this.

instead it flashes every 5 seconds from green to off to green again. (actually with a "sleep 5" it also flashes to the saved pattern - but if you use "sleep 3" it still flashes to off)

also i don't get the problem you are describing:
your example shows the problem, the servertickle command will get called every 5 and a bit seconds - caus it takes time to call the --green. so why not setting the -t to 5500 ? isn't it the callers responisbility to make sure the tickle is not "slightly delayed" and if so - just increase the timeout?

from blink1.

ok, after reconsidering i get your point - but:

wouldn't this be solved, if the "off()" call is just when you turn servertickle off?

from blink1.

Agreed. After looking at this again, I think having it just for servertickle off is the right way to go. I'll update the firmware source for the next iteration of blink(1).

This doesn't help you, unfortunately. If you're handy with an AVR-ISP programmer, I can walk you through how to update your blink(1). Or, if you live in the US, we could arrange a swap via USPS. Contact me via email at tod at thingm.com if you'd like to go this route.

from blink1.

hi there,i already sent you an email, but u didn't reply yet, so here i am again...

we have an arduino at hand and it might work with that.so please respond to my email. On the other hand we have one damaged blink(1) (blue led not responding anymore) and are about to order another bunch of the blink(1) - i sent you details via mail

Just another thing:

I'm still not convinced 100% that calling "off()" should be placed in the servertickle at all. I can see that there is the need to set it to off when you call "servertickle 0" - but then you can easily call "--off" on your own.

BUT if you want to just call "servertickle 0" and want too keep the i.e. green led on the whole time - it will flicker, even when you call the "--green" imediatly afterwards.

In my point of view - calling "off()" in the servertickle is just not what a user would expect that would happen - and since blink(1) heavyly lacks documentation (well, after you read the firmware code, that's not that big of a problem...) it is just not what i would do. And the scenario you described in the issue can easaly be amendet when calling "off" just before the "servertickle 0".

from blink1.

anybody?

from blink1.

Say, how did this get resolved? I have an original blink, and was hoping to use servertickle to act as a dead man's switch while also keeping a consistent color display.

My use case: I'm updating blink once a second to show the health of a system. I want to display steady colors that move slowly throw the color spectrum, so as not to catch the eye for minor updates. If I stop updating, I love the idea that the blink can automatically go into a blinking red to show that the updater failed. But I can't find a way to use it that doesn't cause the blink to, well, blink every second.

Is there some way I can solve this?

from blink1.

Hi @wpietri,

Which blink(1) library are you using? If you're using the Python3 one that you can install with 'pip', then you can do it by hand with something like:

from blink1.blink1 import Blink1

blink1 = Blink1()
tickle_millis = 1000

tickle_time = int(tickle_millis / 10)
tt_hi = (tickle_time & 0xff00) >> 8
tt_lo = (tickle_time & 0x00ff) 
blink1.write( [1, 'D', 1, tt_hi, tt_lo, 0,0,0] )

(Hey @salimfadhley, could you verify if this is correct and help me fill out the python library? I can do the heavy lifting and testing if you can do the publishing to pip)

from blink1.

Hi, @todbot. I'm actually using the command line. My code currently looks like:

def show_color(color):
    call(["blink1-tool", "-q", "--rgb", color, "--millis", "800"])
    call(["blink1-tool", "--servertickle", "1,1", "-t", "10000"]) # refresh the watchdog

I'm glad to switch to the Python 3 library, though. Could you point me at the docs for whatever protocol the blink1.write method is using? Thanks!

from blink1.

Thanks for the update, @gsynedra. In my case, the slight blink is problematic; I'd rather have the risk of a false green than a regular visual twitch. So I'll just leave this alone for now.

@todbot, did this get fixed in the blink(1) now on the market? If so, I'll order a couple of those.

from blink1.