Graphic glitch introduced by v0.0.7

I think either by this commit or this commit some graphic glitch has been introduced regarding the pico display since moving from release v0.0.6 to v0.0.7.
The glitch is visible in this video. It works flawlessly when using v.0.0.6.
Any ideas as to why?

FWIW I've been chasing some weird behavior (crashes, hangs) that seem an awful lot like Python and C not respecting each others boundaries. It seems to trigger when writing near the end of the display buffer. I've been trying to come up with a minimal proof-of-bug, but that's been difficult because it depends on which Python variables are declared etc. Making the display buffer widthheight4 fixes the problem though. If I get a nice, simple and reliably bad test-case, I'll post it.

Yea did see that also. Mine was only at the last few lines, so I declared 10 lines more for  the buffer :)

I finally witnessed this for myself when working on #107. This has all the hallmarks of the stack creeping up over a display buffer allocated at the bottom of the heap, but for some reason isn't as incredibly crashy as I would expect.
Re-running an example from Thonny by pressing only the "Play" button - presumably re-starting the script without a reset - will break it pretty quickly, though. I have to manually reset my Pico more often than not.
This is - as you say @agoodney - really difficult to reliably replicate. A lot of the problem might be due to memory fragmentation - since nobody expects to have to write MicroPython as defensively as they write C for a small micro - and can be mitigated by tiptoeing around the problem.
Take this code for example:
import gc
import micropython
gc.collect()

test = [x for x in range(8*1024)]
micropython.mem_info()
print(len(test))

test = test[10:]
micropython.mem_info()
print(len(test))

gc.collect()
micropython.mem_info()

On CPython you wouldn't bat an eyelid. Sure, dropping some items from the front of a list to create a circular buffer might be a little blunt, but it would work.
On MicroPython, though, we see a - relatively - huge chunk of our RAM allocated right after test = test[10:] because this creates a copy, and removes the reference to the previous list:
# Initial memory
stack: 508 out of 7936
GC: total: 192064, used: 37520, free: 154544
 No. of 1-blocks: 36, 2-blocks: 10, max blk sz: 2048, max free sz: 5050
8192

# Memory after `test = test[10:]`
stack: 508 out of 7936
GC: total: 192064, used: 70288, free: 121776
 No. of 1-blocks: 38, 2-blocks: 10, max blk sz: 2048, max free sz: 3245
8182

# Memory after `gc.collect()`
stack: 508 out of 7936
GC: total: 192064, used: 37456, free: 154608
 No. of 1-blocks: 34, 2-blocks: 10, max blk sz: 2046, max free sz: 3245

So the defensive approach in this case might be to use:
for x in range(10):
    test.pop(0)

This might seem jarring and unpythonic... but it uses 16 bytes of memory instead of 32k!
These are extreme, synthetic examples but these temporary memory allocations- even when they are garbage collected- do not come at zero cost. The resulting memory fragmentation will eventually result in no single, large enough, contiguous block of memory existing for a given allocation and then everything falls apart.
Normally this wouldn't be such a big deal, the Pico and most popular MicroPython boards have plenty of RAM... but then we're eating 64k just for the display buffer.
I've waffled a bit here and I'm unsure if memory fragmentation is actually exacerbating or causing this, but I think it's along the same lines.

I'm getting the same graphical issues and some ludicrous errors that are obviously caused by major memory corruption (and I'm not even multithreading or anything) such as:
TypeError: 'list' object isn't subscriptable
And on the official balls demo file (after running thermometer.py, then pressing stop in thonny and then running demo.py):
AttributeError: 'Ball' object has no attribute 'x'
or
Traceback (most recent call last):   File "<stdin>", line 42, in <module> AttributeError: 'int' object has no attribute 'x'
And finally in my own code (even when plugging in the pico with no main.py and then running the file with the thonny play button):

It also has a tendency to mess up the display exactly like @slabua posted and then suddenly stop running the code and stop responding to thonny at all
The pico display is a buggy mess, I've ordered a new pico to double check that the problem isn't there because I've never dealt with such a fustrating disaster as this

I tried using uploading the uf2 file from https://github.com/pimoroni/pimoroni-pico/releases/tag/v0.0.6 since you're talking about a glitch introduced in v0.0.7 but it makes no difference

It sounds like your issues are related to MicroPython/Thonny - though it could conceivably be a slightly fried Pico I haven't exactly been careful with mine, and haven't seen anywhere near the level of bonkers you describe.
That said I've had some weird out-of-memory errors which appear to have been related to my distros (old) version of Thonny quietly smashing code onto the Pico via the REPL. Updating to 3.3.6 (https://github.com/thonny/thonny/releases) seems to have fixed this and gave me an inkling that "MicroPython Generic" is not compatible with the Pico:
WARNING: Could not sync device's clock: can't import name RTC
WARNING: Could not validate time: can't import name RTC

These suggest Thonny was trying to run code on the Pico to sync the clock and switching to use "MicroPython (Rasberry Pi Pico)", which appears not to do this, has helped.

The following code- at least for me- reliably replicates a region of memory being drawn over the screen. They appear to share the same region of memory, but micropython.mem_info claims they do not.
import machine
import picodisplay as display
import time
import random
import micropython

overflow = 4800 # 240 * 10 * 2 (extra 10 rows)

width = display.get_width()
height = display.get_height()

# Create a bytearray for the display buffer
display_buffer = bytearray(width * height * 2)

# Before overlap allocation
# micropython.mem_info(1)

# Why does data written here appear on the display!?
overlap = bytearray(overflow)

# After overlap allocaton
# micropython.mem_info(1)

display.init(display_buffer)
display.set_backlight(1.0)

n = 0
while True:
    # Fill the "overlay" byearray with random noise
    # This will appear at the bottom of the screen!?!?
    # micropython.mem_info shows these buffers *do not* overlap in memory
    overlap[random.randint(0, overflow-1)] = random.randint(0, 255)

    # Verify the display is actually 135 tall
    display.set_pen(0, 0, 255)
    display.rectangle(0, 0, 10, 10)

    # Draw *something* to the display
    display.set_pen(0, 255, 0)
    display.rectangle(0, 40, 240, 30)
    display.set_pen(255, 0, 0)
    display.text( "test {}".format(n), 1, 40, 240, 4 )

    # Verify the display is actually 135 tall
    display.set_pen(0, 0, 255)
    display.rectangle(0, 125, 10, 10)

    display.update()
    n += 1

If I inspect display_buffer for contents immediately after drawing, the data is usually found at a rather extreme offset:
import picodisplay as display

width = display.get_width()
height = display.get_height()

display_buffer = bytearray(width * height * 2)
display.init(display_buffer)

# Draw something in the display
display.set_pen(255, 255, 255)
display.rectangle(0, 0, 10, 10)

# Find it in the buffer
for x in range(len(display_buffer)):
    if display_buffer[x] > 0:
        print(x, display_buffer[x-10:x+10])
        print("Data found at offset: {}".format(x))
        break

This suggests that C++ and MicroPython don't even agree about which region of memory the display buffer is in, much less respect any boundaries. From the perspective of both languages they are operating normally, but C++ is "seeing" the buffer as being offset.
MicroPython ca3d51f on 2021-03-31; Raspberry Pi Pico with RP2040
Type "help()" for more information.
>>> %Run -c $EDITOR_CONTENT
3200 bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff')
Data found at offset: 3200

This is why enlarging the buffer, or allocating a dummy empty bytearray after it works since it gives a buffer zone for that disagreement.

Your piece of code doesn't cause any strange behaviour for me. Also, when I comment out the pimironidisplay.update() function my own code no longer crashes suggesting that the weird crashes and the display update code are linked. The fact that I even get those weird errors and crashes suggests that the display updating is overwriting micropython memory, not just that random memory is overwriting the display buffer.
My code results in the display getting worse and crashing (if you wait for the number being print to reach 8000 or so)
Try copy the files in this zip onto the pico in the same filestructure and then run mainly.py
test.zip

FWIW the example code from Gadetoid does not appear to cause corruption on my Pico. I'm running Thonny 3.3.4 and my Pico version string is "MicroPython v1.14-113-g73fce1cd6-dirty".
Repo found here: https://github.com/agoodney/micropython
This is micropython + the Pimoroni CI patches to get the modules to build. I wanted the FAT fs for an SD card.

The following code- at least for me- reliably replicates a region of memory being drawn over the screen. They appear to share the same region of memory, but micropython.mem_info claims they do not.
import machine
import picodisplay as display
import time
import random
import micropython

overflow = 4800 # 240 * 10 * 2 (extra 10 rows)

width = display.get_width()
height = display.get_height()

# Create a bytearray for the display buffer
display_buffer = bytearray(width * height * 2)

# Before overlap allocation
# micropython.mem_info(1)

# Why does data written here appear on the display!?
overlap = bytearray(overflow)

# After overlap allocaton
# micropython.mem_info(1)

display.init(display_buffer)
display.set_backlight(1.0)

n = 0
while True:
    # Fill the "overlay" byearray with random noise
    # This will appear at the bottom of the screen!?!?
    # micropython.mem_info shows these buffers *do not* overlap in memory
    overlap[random.randint(0, overflow-1)] = random.randint(0, 255)

    # Verify the display is actually 135 tall
    display.set_pen(0, 0, 255)
    display.rectangle(0, 0, 10, 10)

    # Draw *something* to the display
    display.set_pen(0, 255, 0)
    display.rectangle(0, 40, 240, 30)
    display.set_pen(255, 0, 0)
    display.text( "test {}".format(n), 1, 40, 240, 4 )

    # Verify the display is actually 135 tall
    display.set_pen(0, 0, 255)
    display.rectangle(0, 125, 10, 10)

    display.update()
    n += 1

If I inspect display_buffer for contents immediately after drawing, the data is usually found at a rather extreme offset:
import picodisplay as display

width = display.get_width()
height = display.get_height()

display_buffer = bytearray(width * height * 2)
display.init(display_buffer)

# Draw something in the display
display.set_pen(255, 255, 255)
display.rectangle(0, 0, 10, 10)

# Find it in the buffer
for x in range(len(display_buffer)):
    if display_buffer[x] > 0:
        print(x, display_buffer[x-10:x+10])
        print("Data found at offset: {}".format(x))
        break

This suggests that C++ and MicroPython don't even agree about which region of memory the display buffer is in, much less respect any boundaries. From the perspective of both languages they are operating normally, but C++ is "seeing" the buffer as being offset.
MicroPython ca3d51f on 2021-03-31; Raspberry Pi Pico with RP2040
Type "help()" for more information.
>>> %Run -c $EDITOR_CONTENT
3200 bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff')
Data found at offset: 3200

This is why enlarging the buffer, or allocating a dummy empty bytearray after it works since it gives a buffer zone for that disagreement.

My new pico just arrived and your example causes the corruption for me too but only when I've run an example program like thermometer.py, then pressed stop on thonny and then run your example code:
https://streamable.com/r1ef84

When running my own code (without stopping previous code or anything, just plugging this BRAND NEW replacement pico straight in, pressing stop and then running it) I get this error:

Then I add these 5 lines of inconsequential nonsense

and I get this error instead:

Then I nonsensicate further:

And (deja vu, be warned) we get this error:

What on earth is going on. My code is the same as it was before in that previous zip I uploaded.

I can confirm that after being freshly powered on, the example from Gadgetoid does not show corruption.
However, if you run the temperature.py demo first, then 'stop' in Thonny, then Gadgetoid's example will show corruption.
Hitting ctrl-d to soft-reboot the Pico does not fix the issue.
Yay! This feels like progress.

I accidentally reproduced this problem with pimoroni-pico-micropython v0.1.1 and the pico explorer balls_demo.py
With v0.0.6 I can get up to 500 Balls going slowly around the explorer display.
With v0.1.1 I got the error: ‘int’ object has no attribute ‘x’
It is definitely corrupting memory, in this case the balls object list.
When I change the code to allocate 3 bytes per pixel for the display:
display_buffer = bytearray(width * height * 3)  # 2-bytes per pixel (RGB565)
the problem goes away, however I can only allocate 100 Balls before it runs out of memory because of the huge display_buffer.
I reported the same issue on the Pimoroni forum, mostly just for devilment.
This looks like a fundemental object memory management problem which needs to be fixed asap, otherwise you can't trust any program which dynamically allocates objects to behave as expected.

I reported these problems on the Pimoroni Forum on 23 Feb. I've had all the strange messages and corrupted bottom edge of the display since that time.
https://forums.pimoroni.com/t/large-programs-on-pico-explorer-display-problem/16401
But nobody followed it up.
I'm very glad someone else is pushing for a fix.

This looks like a fundemental object memory management problem which needs to be fixed asap, otherwise you can't trust any program which dynamically allocates objects to behave as expected.

It smells like this to me, too, but since we're doing "Kinda Weird Things" with the MicroPython firmware by baking in our own C libraries I'm not confident enough that we haven't borked something up ourselves to point the finger upstream.
Replicating this weirdness in pure MicroPython would certainly help narrow things down.
This sort of deep-routed memory weirdness problem really blows my understanding of C/C++/Embedded C/MicroPython thoroughly out of the water and I'm somewhat at a loss here.

Just to annoy everybody, I can't reproduce the same problem any more!
v0.1.1 is now working just fine with the explorer balls_demo.py and 500 Balls without any problems at all!
All I did (I think) was swap v0.0.6 alpha and V0.1.1 a couple of times on the same pico I've been using, messed with balls_demo.py and then put it back to the original code and then I noticed it had started working "all on its own".
I didn't nuke the internal file system between v0.1.1 and v0.0.06 and I do have a few explorer demo scripts stored there.
How do you erase the entire pico flash memory to clean it all up? Is there an erase uf2 which I should be using?
Now I'm suspecting Thonny again (I don't know why) and/or other subtle problems in the internal micropython file system for trying to run half-overwritten code. Possibly? Maybe? Clutching at straws. Seriously, I give up....

Below is a link to the uf2 file which erases the contents of the flash on the Pico..
I hope this helps
https://www.raspberrypi.org/documentation/rp2040/getting-started/static/6f6f31460c258138bd33cc96ddd76b91/flash_nuke.uf2

Any progress on this issue?

I'm still having the same problem.

I ran a copy of the workout script:
Raspberry Pi Pico & Pico Explorer Workout : 15 Steps - Instructables
Followed by this font program from Les Wright
import math
import picoexplorer as display
Initialise display with a bytearray display buffer
buf = bytearray(display.get_width() * display.get_height() * 2)
display.init(buf)
sets up a handy function we can call to clear the screen
def clear():
display.set_pen(0,0,0)
display.clear()
display.update()
clear()
def ring2(cx,cy,r):   # Centre (x,y), radius
for angle in range(0, 90, 2):  # 0 to 90 degrees in 2s
y3=int(rmath.sin(math.radians(angle)))
x3=int(rmath.cos(math.radians(angle)))
display.pixel(cx-x3,cy+y3)  # 4 quadrants
display.pixel(cx-x3,cy-y3)
display.pixel(cx+x3,cy+y3)
display.pixel(cx+x3,cy-y3)
#ASCII Character Set
cmap = ['00000000000000000000000000000000000', #Space
'00100001000010000100001000000000100', #!
'01010010100000000000000000000000000', #"
'01010010101101100000110110101001010', ##
'00100011111000001110000011111000100', #$
'11001110010001000100010001001110011', #%
'01000101001010001000101011001001101', #&
'10000100001000000000000000000000000', #'
'00100010001000010000100000100000100', #(
'00100000100000100001000010001000100', #)
'00000001001010101110101010010000000', #*
'00000001000010011111001000010000000', #+
'000000000000000000000000000000110000100010000', #,
'00000000000000011111000000000000000', #-
'00000000000000000000000001100011000', #.
'00001000010001000100010001000010000', #/
'01110100011000110101100011000101110', #0
'00100011000010000100001000010001110', #1
'01110100010000101110100001000011111', #2
'01110100010000101110000011000101110', #3
'00010001100101011111000100001000010', #4
'11111100001111000001000011000101110', #5
'01110100001000011110100011000101110', #6
'11111000010001000100010001000010000', #7
'01110100011000101110100011000101110', #8
'01110100011000101111000010000101110', #9
'00000011000110000000011000110000000', #:
'01100011000000001100011000010001000', #;
'00010001000100010000010000010000010', #<
'00000000001111100000111110000000000', #=
'01000001000001000001000100010001000', #>
'01100100100001000100001000000000100', #?
'01110100010000101101101011010101110', #@
'00100010101000110001111111000110001', #A
'11110010010100111110010010100111110', #B
'01110100011000010000100001000101110', #C
'11110010010100101001010010100111110', #D
'11111100001000011100100001000011111', #E
'11111100001000011100100001000010000', #F
'01110100011000010111100011000101110', #G
'10001100011000111111100011000110001', #H
'01110001000010000100001000010001110', #I
'00111000100001000010000101001001100', #J
'10001100101010011000101001001010001', #K
'10000100001000010000100001000011111', #L
'10001110111010110101100011000110001', #M
'10001110011010110011100011000110001', #N
'01110100011000110001100011000101110', #O
'11110100011000111110100001000010000', #P
'01110100011000110001101011001001101', #Q
'11110100011000111110101001001010001', #R
'01110100011000001110000011000101110', #S
'11111001000010000100001000010000100', #T
'10001100011000110001100011000101110', #U
'10001100011000101010010100010000100', #V
'10001100011000110101101011101110001', #W
'10001100010101000100010101000110001', #X
'10001100010101000100001000010000100', #Y
'11111000010001000100010001000011111', #Z
'01110010000100001000010000100001110', #[
'10000100000100000100000100000100001', #
'00111000010000100001000010000100111', #]
'00100010101000100000000000000000000', #^
'00000000000000000000000000000011111', #_
'11000110001000001000000000000000000', #`
'00000000000111000001011111000101110', #a
'10000100001011011001100011100110110', #b
'00000000000011101000010000100000111', #c
'00001000010110110011100011001101101', #d
'00000000000111010001111111000001110', #e
'00110010010100011110010000100001000', #f
'000000000001110100011000110001011110000101110', #g
'10000100001011011001100011000110001', #h
'00100000000110000100001000010001110', #i
'0001000000001100001000010000101001001100', #j
'10000100001001010100110001010010010', #k
'01100001000010000100001000010001110', #l
'00000000001101010101101011010110101', #m
'00000000001011011001100011000110001', #n
'00000000000111010001100011000101110', #o
'000000000001110100011000110001111101000010000', #p
'000000000001110100011000110001011110000100001', #q
'00000000001011011001100001000010000', #r
'00000000000111110000011100000111110', #s
'00100001000111100100001000010000111', #t
'00000000001000110001100011001101101', #u
'00000000001000110001100010101000100', #v
'00000000001000110001101011010101010', #w
'00000000001000101010001000101010001', #x
'000000000010001100011000110001011110000101110', #y
'00000000001111100010001000100011111', #z
'00010001000010001000001000010000010', #{
'00100001000010000000001000010000100', #|
'01000001000010000010001000010001000', #}
'01000101010001000000000000000000000' #}~
]
def printchar(letter,xpos,ypos,size,charupdate):
origin = xpos
charval = ord(letter)
#print(charval)
index = charval-32 #start code, 32 or space
#print(index)
character = cmap[index] #this is our char...
rows = [character[i:i+5] for i in range(0,len(character),5)]
#print(rows)
for row in rows:
#print(row)
for bit in row:
#print(bit)
if bit == '1':
display.pixel(xpos,ypos)
if size==2:
display.pixel(xpos,ypos+1)
display.pixel(xpos+1,ypos)
display.pixel(xpos+1,ypos+1)
xpos+=size
xpos=origin
ypos+=size
if charupdate == True:
display.update()
def delchar(xpos,ypos,size,delupdate):
if size == 1:
charwidth = 5
charheight = 9
if size == 2:
charwidth = 10
charheight = 18
display.set_pen(0,0,0)
display.rectangle(xpos,ypos,charwidth,charheight) #xywh
if delupdate == True:
display.update()
def printstring(string,xpos,ypos,size,charupdate,strupdate):
if size == 2:
spacing = 14
else:
spacing = 8
for i in string:
printchar(i,xpos,ypos,size,charupdate)
xpos+=spacing
if strupdate == True:
display.update()
#display one char at a time, like an old serial term...
test1 = "Hello World!!"
display.set_pen(255,0,0)
printstring(test1,0,0,2,True,False)
#display string fast
test2 = "Les Wright 2021"
display.set_pen(0,255,0)
printstring(test2,0,20,2,False,True)
#display one char at a time, like an old serial term...
test3 = 'abcdefghijk'
display.set_pen(0,0,255)
printstring(test3,0,60,2,True,False)
#display one char at a time, like an old serial term...
test4 = 'lmnopqrstuvwxyz'
display.set_pen(0,0,255)
printstring(test4,0,80,2,True,False)
#display one char at a time, like an old serial term...
test5 = 'ABCDEFGHIJKLM'
display.set_pen(0,0,255)
printstring(test5,0,100,2,True,False)
#display one char at a time, like an old serial term...
test6 = 'NOPQRSTUVWXYZ'
display.set_pen(0,0,255)
printstring(test6,0,120,2,True,False)
#display blocks of text fast
test7 = '`~!@#$%^&*()_-+=['
printstring(test7,0,140,2,False,False)
test8 = ']\{}|;':"<>?,./'
printstring(test8,0,160,2,False,False)
display.update()
display.set_pen(255,255,0)
ring2(20,220,20)
display.update()
spinner = '-|/-|/'
for i in range(50):
for x in spinner:
display.set_pen(255,255,0)
printchar(x,220,20,2,True)
delchar(220,20,2,True)
I also lost communication between Thonny and the Pico several times. (Unplug, plug in, click on STOP)
So, this is still a major problem with large scripts.

I'm still having the same problem.

I ran a copy of the workout script:
Raspberry Pi Pico & Pico Explorer Workout : 15 Steps - Instructables
Followed by this, updated to Explorer and extended, font program from Les Wright
'''
Fonts for the pico display!
Les Wright 2021
V 1.1
Update with a suggestion from Steve Borg:
https://forums.pimoroni.com/t/pico-display-and-fonts/16194/18

"Refactor it slightly so that the various functions take an optional parameter to tell it
whether to do a display.update() you can get it so it draws much more quickly.
That way those that like the teleprompter type output can leave it to update after each character
and those that don’t could update after each string."

printchar naw has the extra parameter: Charupdate (Boolean (True/False)
printchar(letter,xpos,ypos,size,charupdate)
delchar has the same
delchar(xpos,ypos,size,delupdate)

Printstring has two extra args charupdate and strupdate (Boolean (True/False)
printstring(string,xpos,ypos,size,charupdate,strupdate)
These say whether to call display.update()on individual chars (slow) or on the entire string (fast)
You can set them both to false if you want, send multiple lines, then do a display.upadte() manually if you like
(see example code below)

'''
import math

import picoexplorer as display
# Initialise display with a bytearray display buffer
buf = bytearray(display.get_width() * display.get_height() * 2)
display.init(buf)

# sets up a handy function we can call to clear the screen
def clear():
    display.set_pen(0,0,0)
    display.clear()
    display.update()

clear()

def ring2(cx,cy,r):   # Centre (x,y), radius
    for angle in range(0, 90, 2):  # 0 to 90 degrees in 2s
        y3=int(r*math.sin(math.radians(angle)))
        x3=int(r*math.cos(math.radians(angle)))
        display.pixel(cx-x3,cy+y3)  # 4 quadrants
        display.pixel(cx-x3,cy-y3)
        display.pixel(cx+x3,cy+y3)
        display.pixel(cx+x3,cy-y3)

#ASCII Character Set
cmap = ['00000000000000000000000000000000000', #Space
        '00100001000010000100001000000000100', #!
        '01010010100000000000000000000000000', #"
        '01010010101101100000110110101001010', ##
        '00100011111000001110000011111000100', #$
        '11001110010001000100010001001110011', #%
        '01000101001010001000101011001001101', #&
        '10000100001000000000000000000000000', #'
        '00100010001000010000100000100000100', #(
        '00100000100000100001000010001000100', #)
        '00000001001010101110101010010000000', #*
        '00000001000010011111001000010000000', #+
        '000000000000000000000000000000110000100010000', #,
        '00000000000000011111000000000000000', #-
        '00000000000000000000000001100011000', #.
        '00001000010001000100010001000010000', #/
        '01110100011000110101100011000101110', #0
        '00100011000010000100001000010001110', #1
        '01110100010000101110100001000011111', #2
        '01110100010000101110000011000101110', #3
        '00010001100101011111000100001000010', #4
        '11111100001111000001000011000101110', #5
        '01110100001000011110100011000101110', #6
        '11111000010001000100010001000010000', #7
        '01110100011000101110100011000101110', #8
        '01110100011000101111000010000101110', #9
        '00000011000110000000011000110000000', #:
        '01100011000000001100011000010001000', #;
        '00010001000100010000010000010000010', #<
        '00000000001111100000111110000000000', #=
        '01000001000001000001000100010001000', #>
        '01100100100001000100001000000000100', #?
        '01110100010000101101101011010101110', #@
        '00100010101000110001111111000110001', #A
        '11110010010100111110010010100111110', #B
        '01110100011000010000100001000101110', #C
        '11110010010100101001010010100111110', #D
        '11111100001000011100100001000011111', #E
        '11111100001000011100100001000010000', #F
        '01110100011000010111100011000101110', #G
        '10001100011000111111100011000110001', #H
        '01110001000010000100001000010001110', #I
        '00111000100001000010000101001001100', #J
        '10001100101010011000101001001010001', #K
        '10000100001000010000100001000011111', #L
        '10001110111010110101100011000110001', #M
        '10001110011010110011100011000110001', #N
        '01110100011000110001100011000101110', #O
        '11110100011000111110100001000010000', #P
        '01110100011000110001101011001001101', #Q
        '11110100011000111110101001001010001', #R
        '01110100011000001110000011000101110', #S
        '11111001000010000100001000010000100', #T
        '10001100011000110001100011000101110', #U
        '10001100011000101010010100010000100', #V
        '10001100011000110101101011101110001', #W
        '10001100010101000100010101000110001', #X
        '10001100010101000100001000010000100', #Y
        '11111000010001000100010001000011111', #Z
        '01110010000100001000010000100001110', #[
        '10000100000100000100000100000100001', #\
        '00111000010000100001000010000100111', #]
        '00100010101000100000000000000000000', #^
        '00000000000000000000000000000011111', #_
        '11000110001000001000000000000000000', #`
        '00000000000111000001011111000101110', #a
        '10000100001011011001100011100110110', #b
        '00000000000011101000010000100000111', #c
        '00001000010110110011100011001101101', #d
        '00000000000111010001111111000001110', #e
        '00110010010100011110010000100001000', #f
        '000000000001110100011000110001011110000101110', #g
        '10000100001011011001100011000110001', #h
        '00100000000110000100001000010001110', #i
        '0001000000001100001000010000101001001100', #j
        '10000100001001010100110001010010010', #k
        '01100001000010000100001000010001110', #l
        '00000000001101010101101011010110101', #m
        '00000000001011011001100011000110001', #n
        '00000000000111010001100011000101110', #o
        '000000000001110100011000110001111101000010000', #p
        '000000000001110100011000110001011110000100001', #q
        '00000000001011011001100001000010000', #r
        '00000000000111110000011100000111110', #s
        '00100001000111100100001000010000111', #t
        '00000000001000110001100011001101101', #u
        '00000000001000110001100010101000100', #v
        '00000000001000110001101011010101010', #w
        '00000000001000101010001000101010001', #x
        '000000000010001100011000110001011110000101110', #y
        '00000000001111100010001000100011111', #z
        '00010001000010001000001000010000010', #{
        '00100001000010000000001000010000100', #|
        '01000001000010000010001000010001000', #}
        '01000101010001000000000000000000000' #}~
]

def printchar(letter,xpos,ypos,size,charupdate):
    origin = xpos
    charval = ord(letter)
    #print(charval)
    index = charval-32 #start code, 32 or space
    #print(index)
    character = cmap[index] #this is our char...
    rows = [character[i:i+5] for i in range(0,len(character),5)]
    #print(rows)
    for row in rows:
        #print(row)
        for bit in row:
            #print(bit)
            if bit == '1':
                display.pixel(xpos,ypos)
                if size==2:
                    display.pixel(xpos,ypos+1)
                    display.pixel(xpos+1,ypos)
                    display.pixel(xpos+1,ypos+1)
            xpos+=size
        xpos=origin
        ypos+=size
    if charupdate == True:
        display.update()

def delchar(xpos,ypos,size,delupdate):
    if size == 1:
        charwidth = 5
        charheight = 9
    if size == 2:
        charwidth = 10
        charheight = 18
    display.set_pen(0,0,0)
    display.rectangle(xpos,ypos,charwidth,charheight) #xywh
    if delupdate == True:
        display.update()

def printstring(string,xpos,ypos,size,charupdate,strupdate):
    if size == 2:
        spacing = 14
    else:
        spacing = 8
    for i in string:
        printchar(i,xpos,ypos,size,charupdate)
        xpos+=spacing
    if strupdate == True:
        display.update()

#display one char at a time, like an old serial term...
test1 = "Hello World!!"
display.set_pen(255,0,0)
printstring(test1,0,0,2,True,False)

#display string fast
test2 = "Les Wright 2021"
display.set_pen(0,255,0)
printstring(test2,0,20,2,False,True)

#display one char at a time, like an old serial term...
test3 = 'abcdefghijk'
display.set_pen(0,0,255)
printstring(test3,0,60,2,True,False)

#display one char at a time, like an old serial term...
test4 = 'lmnopqrstuvwxyz'
display.set_pen(0,0,255)
printstring(test4,0,80,2,True,False)

#display one char at a time, like an old serial term...
test5 = 'ABCDEFGHIJKLM'
display.set_pen(0,0,255)
printstring(test5,0,100,2,True,False)

#display one char at a time, like an old serial term...
test6 = 'NOPQRSTUVWXYZ'
display.set_pen(0,0,255)
printstring(test6,0,120,2,True,False)

#display blocks of text fast
test7 = '`~!@#$%^&*()_-+=['
printstring(test7,0,140,2,False,False)
test8 = ']\\{}|;\':"<>?,./'
printstring(test8,0,160,2,False,False)
display.update()

display.set_pen(255,255,0)
ring2(20,220,20)
display.update()

spinner = '-\|/-\|/'
for i in range(50):
    for x in spinner:
        display.set_pen(255,255,0)
        printchar(x,220,20,2,True)
        delchar(220,20,2,True)

I also lost communication between Thonny and the Pico several times. (Unplug, plug in, click on STOP)
So, this is still a major problem with large scripts.

I think I just ran into this issue with Pimoroni Pico LiPo and Explorer Base - my code fails reliably with v0.2.3 after 14 iterations, with:
Traceback (most recent call last):
  File "<stdin>", line 39, in <module>
TypeError: unsupported types for __mul__: 'float', ''

It seems to work OK if I increase the display buffer to * 3.
Code:
# This example shows how to read the voltage from a LiPo battery connected to Pimoroni Pico LiPo, and uses this reading to calculate how much charge is left in the battery.
# It then displays the info on the screen of Pico Display or Pico Explorer.
# With Pimoroni Pico LiPo, you can read the battery percentage while it's charging!
# Remember to save this code as main.py on your Pico if you want it to run automatically.

from machine import ADC, Pin
import utime
import picoexplorer as display      # change "picodisplay" to "picoexplorer" if you're using a Pico Explorer

# Set up and initialise display
buf = bytearray(display.get_width() * display.get_height() * 2)
display.init(buf)
#display.set_backlight(0.8)         # comment out this line if you have a Pico Explorer as it doesn't have a controllable backlight

vsys = ADC(29)                      # reads the system input voltage
charging = Pin(24, Pin.IN)          # reading GP24 tells us whether or not USB power is connected
conversion_factor = 3 * 3.3 / 65535

full_battery = 4.2                  # these are our reference voltages for a full/empty battery, in volts
empty_battery = 2.8                 # the values could vary by battery size/manufacturer so you might need to adjust them

while True:
    voltage = vsys.read_u16() * conversion_factor
    percentage = 100 * ((voltage - empty_battery) / (full_battery - empty_battery))
    if percentage > 100:
        percentage = 100

    # draws the battery
    display.set_pen(0, 0, 0)
    display.clear()
    display.set_pen(190, 190, 190)
    display.rectangle(0, 0, 220, 135)
    display.rectangle(220, 40, 20, 55)
    display.set_pen(0, 0, 0)
    display.rectangle(3, 3, 214, 129)
    display.set_pen(0, 255, 0)

    # draws a green box for the battery level
    display.rectangle(5, 5, int((210 / 100) * percentage), 125)

    # adding text
    display.set_pen(255, 0, 0)
    if charging.value() == 1:         # if it's plugged into USB power...
        display.text("Charging!", 15, 90, 240, 4)

    display.text('{:.2f}'.format(voltage) + "v", 15, 10, 240, 5)
    display.text('{:.0f}%'.format(percentage), 15, 50, 240, 5)

    # low battery alarm (Pico Explorer only, you'll need to have GP0 and AUDIO connected with a jumper wire)
    display.set_audio_pin(0)
    if percentage < 5:              # if the battery is less than 5%
        display.set_tone(262)         # then make an annoying noise
    display.update()
    utime.sleep(0.5)

I'm still having the same problem with the Pimoroni UF2.
I've think I've found a solution with a pure Micropython ST7789 library. See my post and code here:
https://forums.pimoroni.com/t/pico-explorer-screen-corruption-and-communication-crashes/18173
I hope a few people will give it a try.

I ended up getting the following working quite easily.
https://github.com/peterhinch/micropython-nano-gui

Thank you. That looks really comprehensive. I will give it a try. Just wish the Pimoroni UF2 could be fixed so newbies are not put off.

Just wish the Pimoroni UF2 could be fixed so newbies are not put off.

You and me both. 😭😭😭😭

I'm a newbie and this issue has definitely put me off.
I get the same screen corruption and memory problems.  Judging from the time this issue has been around it seems Pimoroni aren't going to do anything about it.
I'm planning to try the Micropython ST7789 library solution suggested by tonygo.

Have fun, please let others know how you get on.

It took some fresh eyes on this problem to finally see what was happening and - hopefully - fix it. See: https://github.com/pimoroni/pimoroni-pico/pull/250
Thank you @ZodiusInfuser 🥇  - despite this staring me in the face, and being so close I couldn't see the wood for the trees.
For anyone wanting to try this fix, you can grab the MicroPython build from CI, here:
https://github.com/pimoroni/pimoroni-pico/suites/5297692052/artifacts/164346006
I know this whole thing has been a drawn out travesty. Thank you for providing test cases and sorry for taking so long and for this being a bit of a showstopper for displays.
If anyone's still hanging on we'd appreciate some feedback!

This link appears to be broken - 404 error:
https://github.com/pimoroni/pimoroni-pico/suites/5297692052/artifacts/164346006
Regards
Tony Goodhew

On 15 February 2022 at 12:41 Philip Howard @.***> wrote:
It took some fresh eyes on this problem to finally see what was happening and - hopefully - fix it. See: #250 https://github.com/pimoroni/pimoroni-pico/pull/250

Thank you @ZodiusInfuser https://github.com/ZodiusInfuser 🥇 - despite this staring me in the face, and being so close I couldn't see the wood for the trees.

For anyone wanting to try this fix, you can grab the MicroPython build from CI, here:

https://github.com/pimoroni/pimoroni-pico/suites/5297692052/artifacts/164346006

I know this whole thing has been a drawn out travesty. Thank you for providing test cases and sorry for taking so long and for this being a bit of a showstopper for displays.

If anyone's still hanging on we'd appreciate some feedback!

—
Reply to this email directly, view it on GitHub https://github.com/pimoroni/pimoroni-pico/issues/89#issuecomment-1040226377 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3K7VOLTORV3MVN45QWPCLU3JCWVANCNFSM4Y2V4Z6Q .
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .
You are receiving this because you commented.Message ID<EMAIL_ADDRESS>

The link is working OK for me - I think you might need to be logged in to Github to be able to download artifacts?

Thanks

Thanks @helgibbons I keep forgetting that fact :facepalm:

Sorry Phil, I've still got a problem.
See here:
https://forums.pimoroni.com/t/pico-explorer-screen-corruption-and-communication-crashes/18173

@tonygo That was my mistake. PicoExplorer uses a different code section than the two PicoDisplays so did not have the fix applied. I have now run your test case and fixed the glitch. Could you test this build to confirm? https://github.com/pimoroni/pimoroni-pico/suites/5400141396/artifacts/170277436

@Zodiusinfuser Thank you very much. That works properly with these test scripts on my set up.

Fixes merged and released in - https://github.com/pimoroni/pimoroni-pico/releases/tag/1.18.2
Hopefully that's everything!
Thank you all involved, and sorry it took us so darned long!

So happy we now have it fixed and available to all.
Perhaps a note on the shop description to ensure users update their UF2?

Perhaps a note on the shop description to ensure users update their UF2?

Probably a good idea, @helgibbons?

Aye aye - I've added notes to Display Pack, Display Pack 2.0 and Pico Explorer👍

Thanks
Tony

On 01 March 2022 at 12:08 Hel Gibbons @.***> wrote:
Aye aye - I've added notes to Display Pack, Display Pack 2.0 and Pico Explorer 👍

—
Reply to this email directly, view it on GitHub https://github.com/pimoroni/pimoroni-pico/issues/89#issuecomment-1055374723 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3K7VJY4BTKQV7EQP6QZ2TU5YCDRANCNFSM4Y2V4Z6Q .
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>


fix(service): Fix querying for a column on multiple conditions

resolves issue where multiple conditions for the same column (e.g. createdAt_lte and createdAt_gte used simultaneously) use the same parameter value

Sweet, looks good. Thanks for the fix!

:tada: This PR is included in version 2.0.0-beta.13 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[question]  Trigger scene with fibaro key fob

Just starting to play with zwavejs2mqtt, and so far so good.
But I am struggling with some of mye scene controllers. The fibaro key fob includes with no issues. And it creates several devices in Home Assistant. But when I press a button it only changes state once, and stays at that state. Before when I used zwave2mqtt it would jump back to "standby" or inactive, and just get the activated state for a second or so.
Is there something I am missing or is there something wrong here?

@haavardNO Could you provide some logs? BOth zwavejs and zwavejs2mqtt?

@haavardNO Could you provide some logs? BOth zwavejs and zwavejs2mqtt?

Yes, I can try.
I can at least pull some logs from the UI of zwavejs2mqtt. How can I get the logs from zwavejs?

Yes, I can try.
I can at least pull some logs from the UI of zwavejs2mqtt. How can I get the logs from zwavejs?

@haavardNO If you are using docker dev tag, you will find them in store folder if you enable log to file in settings

@haavardNO If you are using docker dev tag, you will find them in store folder if you enable log to file in settings

@haavardNO which version of zwavejs2mqtt are you using?
The best way for now to trigger automations on scene button presses is to read the event bus, rather than reading a state change.
Here is an example of an central scene trigger, using a zooz scene switch:
  trigger:
  - platform: event
    event_type: state_changed
    event_data:
      entity_id: sensor.outdoor_frontpath_scene_state_001_scene
  condition:
  - condition: template
    value_template: '{{ trigger.event.data.new_state.state == ''3'' }}'

@haavardNO which version of zwavejs2mqtt are you using?
The best way for now to trigger automations on scene button presses is to read the event bus, rather than reading a state change.
Here is an example of an central scene trigger, using a zooz scene switch:
  trigger:
  - platform: event
    event_type: state_changed
    event_data:
      entity_id: sensor.outdoor_frontpath_scene_state_001_scene
  condition:
  - condition: template
    value_template: '{{ trigger.event.data.new_state.state == ''3'' }}'

@jcam I can try with your template. But if I have activated scene 3, it will hold that value (at least in developer tools). So if there is no change, can the trigger fire?
I am running the latest versions of both Home assistant and zwavejs2mqtt.

@jcam I can try with your template. But if I have activated scene 3, it will hold that value (at least in developer tools). So if there is no change, can the trigger fire?
I am running the latest versions of both Home assistant and zwavejs2mqtt.

Yes the trigger will still fire.
From the developer tools instead of looking at States, go to the Events tab.
In the bottom box enter state_changed, then click start listening.
When you push your scene 3 button, you should see the event trigger with each press, even if the old state and new state are the same.

Yes the trigger will still fire.
From the developer tools instead of looking at States, go to the Events tab.
In the bottom box enter state_changed, then click start listening.
When you push your scene 3 button, you should see the event trigger with each press, even if the old state and new state are the same.

@robertsLando and @jcam  I am running in to some challanges getting to that log file. I dont know how to access the store folder. I am running zwavejs2mqtt in docker. I have not been able to trigger an automation with the example above.
When I send a scene command (number 4) on the keyfob I get this in the UI debug:
10:00:56.692 SERIAL « 0x010b00040047055b0359800437 (13 bytes) 10:00:56.694 SERIAL » [ACK] (0x06) 10:00:56.696 DRIVER « [Node 071] [REQ] [ApplicationCommand] └─[CentralSceneCCNotification] sequence number: 89 key attribute: KeyPressed scene number: 4 10:00:56.701 CNTRLR [Node 071] [~] [Central Scene] scene[004]: 0 => 0 2021-01-12 10:00:56.702 INFO ZWAVE: Node 71: value updated: 91-0-scene-004 0 => 0 10:00:56.703 CNTRLR « [Node 071] received CentralScene notification { "nodeId": 71, "ccId": "Central Scene", "ccCommand": "0x03", "payload": "0x598004" }
In home assistant I get the following event:
Event 0 fired 10:05 AM: {     "event_type": "state_changed",     "data": {         "entity_id": "sensor.nodeid_71_scene_state_004_scene",         "old_state": {             "entity_id": "sensor.nodeid_71_scene_state_004_scene",             "state": "0",             "attributes": {                 "id": "71-91-0-scene-004",                 "nodeId": 71,                 "commandClass": 91,                 "commandClassName": "Central Scene",                 "endpoint": 0,                 "property": "scene",                 "propertyName": "scene",                 "propertyKey": "004",                 "type": "number",                 "readable": true,                 "writeable": false,                 "label": "Scene 004",                 "min": 0,                 "max": 255,                 "list": true,                 "states": [                     {                         "text": "KeyPressed",                         "value": 0                     },                     {                         "text": "KeyReleased",                         "value": 1                     },                     {                         "text": "KeyHeldDown",                         "value": 2                     },                     {                         "text": "KeyPressed2x",                         "value": 3                     },                     {                         "text": "KeyPressed3x",                         "value": 4                     }                 ],                 "value": 0,                 "lastUpdate":<PHONE_NUMBER>702,                 "friendly_name": "garage-keyfob_scene_state_004_scene"             },             "last_changed": "2021-01-12T08:50:05.601602+00:00",             "last_updated": "2021-01-12T09:00:56.721616+00:00",             "context": {                 "id": "1c560e95956793342d470841f350a1a6",                 "parent_id": null,                 "user_id": null             }         },         "new_state": {             "entity_id": "sensor.nodeid_71_scene_state_004_scene",             "state": "0",             "attributes": {                 "id": "71-91-0-scene-004",                 "nodeId": 71,                 "commandClass": 91,                 "commandClassName": "Central Scene",                 "endpoint": 0,                 "property": "scene",                 "propertyName": "scene",                 "propertyKey": "004",                 "type": "number",                 "readable": true,                 "writeable": false,                 "label": "Scene 004",                 "min": 0,                 "max": 255,                 "list": true,                 "states": [                     {                         "text": "KeyPressed",                         "value": 0                     },                     {                         "text": "KeyReleased",                         "value": 1                     },                     {                         "text": "KeyHeldDown",                         "value": 2                     },                     {                         "text": "KeyPressed2x",                         "value": 3                     },                     {                         "text": "KeyPressed3x",                         "value": 4                     }                 ],                 "value": 0,                 "lastUpdate":<PHONE_NUMBER>770,                 "friendly_name": "garage-keyfob_scene_state_004_scene"             },             "last_changed": "2021-01-12T08:50:05.601602+00:00",             "last_updated": "2021-01-12T09:05:32.781012+00:00",             "context": {                 "id": "cfa27fe2a33a1c2936b5c6bccca5bce3",                 "parent_id": null,                 "user_id": null             }         }     },     "origin": "LOCAL",     "time_fired": "2021-01-12T09:05:32.781012+00:00",     "context": {         "id": "cfa27fe2a33a1c2936b5c6bccca5bce3",         "parent_id": null,         "user_id": null
And the trigger I have set up is as follows
`
alias: Garage open keyfob test
description: Open garage from keyfob
trigger:

platform: event
event_type: state_changed
event_data:
entity_id: sensor.nodeid_71_scene_state_004_scene
condition:
condition: template
value_template: 'value_template: ''{{ trigger.event.data.new_state.state == ''0''
}}'
action:
service: script.garage_open_if_closed
data: {}
mode: single
`

@robertsLando and @jcam  I am running in to some challanges getting to that log file. I dont know how to access the store folder. I am running zwavejs2mqtt in docker. I have not been able to trigger an automation with the example above.
When I send a scene command (number 4) on the keyfob I get this in the UI debug:
10:00:56.692 SERIAL « 0x010b00040047055b0359800437 (13 bytes) 10:00:56.694 SERIAL » [ACK] (0x06) 10:00:56.696 DRIVER « [Node 071] [REQ] [ApplicationCommand] └─[CentralSceneCCNotification] sequence number: 89 key attribute: KeyPressed scene number: 4 10:00:56.701 CNTRLR [Node 071] [~] [Central Scene] scene[004]: 0 => 0 2021-01-12 10:00:56.702 INFO ZWAVE: Node 71: value updated: 91-0-scene-004 0 => 0 10:00:56.703 CNTRLR « [Node 071] received CentralScene notification { "nodeId": 71, "ccId": "Central Scene", "ccCommand": "0x03", "payload": "0x598004" }
In home assistant I get the following event:
Event 0 fired 10:05 AM: {     "event_type": "state_changed",     "data": {         "entity_id": "sensor.nodeid_71_scene_state_004_scene",         "old_state": {             "entity_id": "sensor.nodeid_71_scene_state_004_scene",             "state": "0",             "attributes": {                 "id": "71-91-0-scene-004",                 "nodeId": 71,                 "commandClass": 91,                 "commandClassName": "Central Scene",                 "endpoint": 0,                 "property": "scene",                 "propertyName": "scene",                 "propertyKey": "004",                 "type": "number",                 "readable": true,                 "writeable": false,                 "label": "Scene 004",                 "min": 0,                 "max": 255,                 "list": true,                 "states": [                     {                         "text": "KeyPressed",                         "value": 0                     },                     {                         "text": "KeyReleased",                         "value": 1                     },                     {                         "text": "KeyHeldDown",                         "value": 2                     },                     {                         "text": "KeyPressed2x",                         "value": 3                     },                     {                         "text": "KeyPressed3x",                         "value": 4                     }                 ],                 "value": 0,                 "lastUpdate":<PHONE_NUMBER>702,                 "friendly_name": "garage-keyfob_scene_state_004_scene"             },             "last_changed": "2021-01-12T08:50:05.601602+00:00",             "last_updated": "2021-01-12T09:00:56.721616+00:00",             "context": {                 "id": "1c560e95956793342d470841f350a1a6",                 "parent_id": null,                 "user_id": null             }         },         "new_state": {             "entity_id": "sensor.nodeid_71_scene_state_004_scene",             "state": "0",             "attributes": {                 "id": "71-91-0-scene-004",                 "nodeId": 71,                 "commandClass": 91,                 "commandClassName": "Central Scene",                 "endpoint": 0,                 "property": "scene",                 "propertyName": "scene",                 "propertyKey": "004",                 "type": "number",                 "readable": true,                 "writeable": false,                 "label": "Scene 004",                 "min": 0,                 "max": 255,                 "list": true,                 "states": [                     {                         "text": "KeyPressed",                         "value": 0                     },                     {                         "text": "KeyReleased",                         "value": 1                     },                     {                         "text": "KeyHeldDown",                         "value": 2                     },                     {                         "text": "KeyPressed2x",                         "value": 3                     },                     {                         "text": "KeyPressed3x",                         "value": 4                     }                 ],                 "value": 0,                 "lastUpdate":<PHONE_NUMBER>770,                 "friendly_name": "garage-keyfob_scene_state_004_scene"             },             "last_changed": "2021-01-12T08:50:05.601602+00:00",             "last_updated": "2021-01-12T09:05:32.781012+00:00",             "context": {                 "id": "cfa27fe2a33a1c2936b5c6bccca5bce3",                 "parent_id": null,                 "user_id": null             }         }     },     "origin": "LOCAL",     "time_fired": "2021-01-12T09:05:32.781012+00:00",     "context": {         "id": "cfa27fe2a33a1c2936b5c6bccca5bce3",         "parent_id": null,         "user_id": null
And the trigger I have set up is as follows
`
alias: Garage open keyfob test
description: Open garage from keyfob
trigger:

platform: event
event_type: state_changed
event_data:
entity_id: sensor.nodeid_71_scene_state_004_scene
condition:
condition: template
value_template: 'value_template: ''{{ trigger.event.data.new_state.state == ''0''
}}'
action:
service: script.garage_open_if_closed
data: {}
mode: single
`

I'm working on this: https://github.com/zwave-js/zwavejs2mqtt/pull/215

I'm working on this: https://github.com/zwave-js/zwavejs2mqtt/pull/215

@robertsLando excellent.
Just FYI, it is exactly the same behavior on my Aeotech Wallmote.

@robertsLando excellent.
Just FYI, it is exactly the same behavior on my Aeotech Wallmote.

the trigger condition looks like it picked up a copy paste error:
value_template: 'value_template: ''{{ trigger.event.data.new_state.state == ''0''
}}'
it shouldn't be value_template: 'value_template ...
if you're editing it through the UI mode, set that field to just {{ trigger.event.data.new_state.state == '0' }}

the trigger condition looks like it picked up a copy paste error:
value_template: 'value_template: ''{{ trigger.event.data.new_state.state == ''0''
}}'
it shouldn't be value_template: 'value_template ...
if you're editing it through the UI mode, set that field to just {{ trigger.event.data.new_state.state == '0' }}

@jcam that did the trick. When I look at it now it looks obvious. I guess I should convert to just edit it the code. Right now I am doing a little of both...
Thanks for spotting it.

@jcam that did the trick. When I look at it now it looks obvious. I guess I should convert to just edit it the code. Right now I am doing a little of both...
Thanks for spotting it.

I bounce back and forth between UI mode and code too. I think I prefer the UI mode, and then just look at code if UI doesn't work.

I bounce back and forth between UI mode and code too. I think I prefer the UI mode, and then just look at code if UI doesn't work.

Not sure if it is relevant if @robertsLando is working on a fix. But I have some strange behaviour with the solution described by @jcam . Two times today when I have restarted home assistant, the garage door has opened... The last time I checked the loggs, and found the following:
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.components.mqtt] Timed out waiting for mid 1
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.components.mqtt] Timed out waiting for mid 2
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.helpers.event] Error while processing state changed for binary_sensor.kitchen_multisensor_05_contact
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 257, in _async_state_change_dispatcher
hass.async_run_hass_job(job, event)
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 198, in state_change_listener
hass.async_run_hass_job(
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/config/custom_components/entity_controller/__init__.py", line 550, in sensor_state_change
if self.matches(new.state, old.state):
AttributeError: 'NoneType' object has no attribute 'state'
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.helpers.event] Error while processing state changed for binary_sensor.attic_multisensor_06_contact
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 257, in _async_state_change_dispatcher
hass.async_run_hass_job(job, event)
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 198, in state_change_listener
hass.async_run_hass_job(
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/config/custom_components/entity_controller/__init__.py", line 550, in sensor_state_change
if self.matches(new.state, old.state):
AttributeError: 'NoneType' object has no attribute 'state'
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.helpers.event] Error while processing state changed for binary_sensor.bedroom_multisensor_07_contact
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 257, in _async_state_change_dispatcher
hass.async_run_hass_job(job, event)
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 198, in state_change_listener
hass.async_run_hass_job(
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/config/custom_components/entity_controller/__init__.py", line 550, in sensor_state_change
if self.matches(new.state, old.state):
AttributeError: 'NoneType' object has no attribute 'state'
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.helpers.event] Error while processing state changed for binary_sensor.bedroom_multisensor_07_contact

2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-001 already exists - ignoring sensor.nodeid_71_scene_state_001_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-002 already exists - ignoring sensor.nodeid_71_scene_state_002_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-003 already exists - ignoring sensor.nodeid_71_scene_state_003_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-004 already exists - ignoring sensor.nodeid_71_scene_state_004_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-005 already exists - ignoring sensor.nodeid_71_scene_state_005_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-006 already exists - ignoring sensor.nodeid_71_scene_state_006_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-007 already exists - ignoring sensor.nodeid_71_scene_state_007_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-008 already exists - ignoring sensor.nodeid_71_scene_state_008_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-009 already exists - ignoring sensor.nodeid_71_scene_state_009_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-010 already exists - ignoring sensor.nodeid_71_scene_state_010_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-011 already exists - ignoring sensor.nodeid_71_scene_state_011_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-012 already exists - ignoring sensor.nodeid_71_scene_state_012_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-128-0-level already exists - ignoring sensor.nodeid_71_battery_level
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-slowRefresh already exists - ignoring sensor.nodeid_71_scene_state_slowrefresh

I have disabled the garage open automation for now :-). Anyone who can explain what is happening?

Not sure if it is relevant if @robertsLando is working on a fix. But I have some strange behaviour with the solution described by @jcam . Two times today when I have restarted home assistant, the garage door has opened... The last time I checked the loggs, and found the following:
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.components.mqtt] Timed out waiting for mid 1
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.components.mqtt] Timed out waiting for mid 2
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.helpers.event] Error while processing state changed for binary_sensor.kitchen_multisensor_05_contact
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 257, in _async_state_change_dispatcher
hass.async_run_hass_job(job, event)
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 198, in state_change_listener
hass.async_run_hass_job(
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/config/custom_components/entity_controller/__init__.py", line 550, in sensor_state_change
if self.matches(new.state, old.state):
AttributeError: 'NoneType' object has no attribute 'state'
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.helpers.event] Error while processing state changed for binary_sensor.attic_multisensor_06_contact
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 257, in _async_state_change_dispatcher
hass.async_run_hass_job(job, event)
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 198, in state_change_listener
hass.async_run_hass_job(
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/config/custom_components/entity_controller/__init__.py", line 550, in sensor_state_change
if self.matches(new.state, old.state):
AttributeError: 'NoneType' object has no attribute 'state'
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.helpers.event] Error while processing state changed for binary_sensor.bedroom_multisensor_07_contact
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 257, in _async_state_change_dispatcher
hass.async_run_hass_job(job, event)
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 198, in state_change_listener
hass.async_run_hass_job(
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/config/custom_components/entity_controller/__init__.py", line 550, in sensor_state_change
if self.matches(new.state, old.state):
AttributeError: 'NoneType' object has no attribute 'state'
2021-01-12 20:00:23 ERROR (MainThread) [homeassistant.helpers.event] Error while processing state changed for binary_sensor.bedroom_multisensor_07_contact

2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-001 already exists - ignoring sensor.nodeid_71_scene_state_001_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-002 already exists - ignoring sensor.nodeid_71_scene_state_002_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-003 already exists - ignoring sensor.nodeid_71_scene_state_003_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-004 already exists - ignoring sensor.nodeid_71_scene_state_004_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-005 already exists - ignoring sensor.nodeid_71_scene_state_005_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-006 already exists - ignoring sensor.nodeid_71_scene_state_006_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-007 already exists - ignoring sensor.nodeid_71_scene_state_007_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-008 already exists - ignoring sensor.nodeid_71_scene_state_008_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-009 already exists - ignoring sensor.nodeid_71_scene_state_009_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-010 already exists - ignoring sensor.nodeid_71_scene_state_010_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-011 already exists - ignoring sensor.nodeid_71_scene_state_011_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-scene-012 already exists - ignoring sensor.nodeid_71_scene_state_012_scene
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-128-0-level already exists - ignoring sensor.nodeid_71_battery_level
2021-01-12 20:00:25 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID zwavejs2mqtt_0xdecb2da9_71-91-0-slowRefresh already exists - ignoring sensor.nodeid_71_scene_state_slowrefresh

I have disabled the garage open automation for now :-). Anyone who can explain what is happening?

The restart triggering the garage is due to a bug in the current version where it stores the button "pressed" state, and "sets" it again when restarting.
@robertsLando has fixed this bug with his latest commits. I am testing that build out now

The restart triggering the garage is due to a bug in the current version where it stores the button "pressed" state, and "sets" it again when restarting.
@robertsLando has fixed this bug with his latest commits. I am testing that build out now

Remember to remove the retained message from your broker. TO do this you have to use mqtt explorer

Remember to remove the retained message from your broker. TO do this you have to use mqtt explorer

@robertsLando I see that the latest release addressed #215. So this should solve the issues with the keyfob I assume. But will I still have to listen for event change, or can it trigger on state change?
I am running zwavejs2mqtt as a docker image on a rpi, as many others I assume. What is the easies and fastest way to update the version I am running? Previously I have done it by duplicating the image in portainer, but I am not sure this is the easiest way :).

@robertsLando I see that the latest release addressed #215. So this should solve the issues with the keyfob I assume. But will I still have to listen for event change, or can it trigger on state change?
I am running zwavejs2mqtt as a docker image on a rpi, as many others I assume. What is the easies and fastest way to update the version I am running? Previously I have done it by duplicating the image in portainer, but I am not sure this is the easiest way :).

o this should solve the issues with the keyfob I assume. But will I still have to listen for event change, or can it trigger on state change

It will only trigger on state change but the message will not be retained. If there was some message retained previously on your broker them should be cleaned

I am running zwavejs2mqtt as a docker image on a rpi, as many others I assume. What is the easies and fastest way to update the version I am running? Previously I have done it by duplicating the image in portainer, but I am not sure this is the easiest way :).

You should do a docker pull to get latest updated image. I suggest you to  use the dev tag

o this should solve the issues with the keyfob I assume. But will I still have to listen for event change, or can it trigger on state change

It will only trigger on state change but the message will not be retained. If there was some message retained previously on your broker them should be cleaned

I am running zwavejs2mqtt as a docker image on a rpi, as many others I assume. What is the easies and fastest way to update the version I am running? Previously I have done it by duplicating the image in portainer, but I am not sure this is the easiest way :).

You should do a docker pull to get latest updated image. I suggest you to  use the dev tag

I can confirm that both my keyfob and wallcontroller now works with standard state change in Home Assistant.
Thanks for the fix.
And I must also say that my zwave network is much more responsive with zwavejs2mqtt compared to zwave2mqtt. When activating big scenes with many nodes it act instantly, compared to the other version that is much slower.

I can confirm that both my keyfob and wallcontroller now works with standard state change in Home Assistant.
Thanks for the fix.
And I must also say that my zwave network is much more responsive with zwavejs2mqtt compared to zwave2mqtt. When activating big scenes with many nodes it act instantly, compared to the other version that is much slower.

@robertsLando has there been any retain policy changes recently? I just updated to the 1.0.1 version, and my garage opened by itself again...

@haavardNO maybe you just restarted the application? In that case when the value is added it is sent. Also check mqtt explorer to see if it is retained or not

@robertsLando I have done some more testing and yes you are correct. The behaviour occurs when zwavejs2mqtt is restarted. This is a bit scary since the application / rpi can restart for several reasons. And especially when I dont sit and wait for it :)
When restarted zwavejs2mqtt restores the value back to 0. I think zwave2mqtt used a slightly different approach. There the state would be set to "inactive" until a button was pressed, and it got the scene state. Could that be the reason for why this did not happen in that version?

@haavardNO Could you open an issue to keep track of this? I should skip sending cached values for stateless valueId (like this one) when application starts


feat(flags): add missing MessageFlags values

Summary
The suppress notifications option is from discord/discord-api-docs#5910.
Bitshifted values seemed to have been missed in #911 as this is a flag

Checklist

[x] If code changes were made then they have been tested.

[x] I have updated the documentation to reflect the changes.
[x] I have run task pyright and fixed the relevant issues.

[ ] This PR fixes an issue.
[x] This PR adds something new (e.g. new method or parameters).
[ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
[ ] This PR is not a code change (e.g. documentation, README, ...)

Is that not what #979 is?


Addresses field in the /addresses/utxos

We need to add addresses field in the /addresses/utxos which is handy if being queried by the payment credentials.

Done & done.


Throws error in step_definitions.ts if specPattern is outside the project root

Current behavior

My project references features from outside the project root.
Eg. specPattern: '../../../../features/**/*.feature'
This causes the library to throw an error from this check
Desired behavior
Allow the spec files to exist outside the project root.
This check seems purely arbitrary and doesn't actually prevent any problems.

Test code to reproduce
define a path outside the project root in  specPattern

Versions

Cypress version: 11.0.1
Preprocessor version:  14.0.0
Node version: 16.15.0

Checklist

[x] I've read the FAQ.
[x] I've read Instructions for logging issues.
[x] I'm not using<EMAIL_ADDRESS>(package name has changed and it is no longer the most recent version, see #689).

[..] and doesn't actually prevent any problems.

You may be completely right, but I'm wary with these changes nonetheless. Have you tried removing it? Using eg. patch-package is pretty easu to make lasting changes circumventing upstream.

@badeball Yes indeed commenting out this check does eliminate the error and allows the tests to run as expected.

Removing this creates the issue of calculating common ancestor paths when there are multiple test roots, including one outside of the project root. This isn't a problem I'd like to visit now, so I've decided to let the assertion remain.


Fix mapStateToProp condition on ToastContainer

Proposed Changes
_.findWhere always return null because it try to deeply match {id: 'someID'} with IToastsState https://github.com/coveo/react-vapor/blob/master/packages/react-vapor/src/components/toast/ToastReducers.ts#L7-L10
This cannot works because it will always be missing the toasts property of IToastsState.
See: https://underscorejs.org/#findWhere
What I think would be the correct behavior is a match by id, which is done through the use of _.where: https://underscorejs.org/#where
Potential Breaking Changes
Should be already fully broken, so no breaking I guess?
Acceptance Criteria

[?] The proposed changes are covered by unit tests - Didn't find UT for the react part?
[?] The potential breaking changes are clearly identified - Not really, Idk how it was used before.
[X] README.md is adjusted to reflect the proposed changes (if relevant) - Not relevant.

I'm sorry for this hasty PR, indeed this was a mistake from my side.


No confirms on sent BTC

I sent 0.25BTC this morning at 08:12 CT.  As of 13:00 CT, there are no confirmations although the trans has been seen by 30 peers.  System is Windows7 Pro, MultiBit 0.5.18
Blockchain.info:  https://blockchain.info/tx-index/21a8d6742912328c02360ba22313f0be27608fc031e2973745b96da2da1a1f85
Blockchain Explorer:  https://blockexplorer.com/tx/21a8d6742912328c02360ba22313f0be27608fc031e2973745b96da2da1a1f85
I have closed & reopened the wallet numerous times.

It is unconfirmed in MultiBit because it is unconfirmed on the Bitcoin network (as per your 2 links at pixel time).
If you have a look in the smartbit explorer (https://www.smartbit.com.au/tx/21a8d6742912328c02360ba22313f0be27608fc031e2973745b96da2da1a1f85) you can see that the transaction fee rate is 10 satoshi/ byte.
This is a bit on the low side and hence the miners are choosing to mine transactions with higher fee rates.
You will just have to be patient.

Why you closed this topic Mr Gary .
More and more people have big problems with Multibit and you have not done nothing .
You remember me , 3 years ago Multibit eat my BTC ( APROX 1 BTC ) and noone gived me an explication .
İ know who are you and trust me , i have not forget what you and your friend done .
You have any solution for my problem or i need to take other actions ??
Thank you

Why you closed this topic Mr Gary .
More and more people have big problems with Multibit and you have not done nothing .
You remember me , 3 years ago Multibit eat my BTC ( APROX 1 BTC ) and noone gived me an explication .
İ know who are you and trust me , i have not forget what you and your friend done .
You have any solution for my problem or i need to take other actions ??
Thank you

you may reach www.btc2doge.org there is bugs in the old wallet


transaction docs missing!

Hi there, I've been through all the docs, but I can't find anything about how JCypher deals with transactions?
Is this missing from the docs?
Thanks,
Joe

Hi Joe,
currently every query is performed as a single transaction. A distinct transaction interface (begin, commit, rollback) will be part of one of the upcoming releases (2.7.0 or 2.8.0).
Best regards,
Wolfgang
-----Original Message-----
From: Dr Josef Karthauser<EMAIL_ADDRESS>To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>Sent: Wed, Jul 15, 2015 10:44 PM
Subject: [jcypher] transaction docs missing! (#4)

Hi there, I've been through all the docs, but I can't find anything about how JCypher deals with transactions?
Is this missing from the docs?
Thanks,
 Joe
—
Reply to this email directly or view it on GitHub.

Ahha, I guessed it was something like that.
I’m currently using SpringDataNeo4j - and want to get away from Spring as soon as possible. JCypher looks like an ideal candidate! :)
:)
Cheers,
Joe

On 16 Jul 2015, at 15:02, Wolfgang Schuetzelhofer<EMAIL_ADDRESS>wrote:
Hi Joe,
currently every query is performed as a single transaction. A distinct transaction interface (begin, commit, rollback) will be part of one of the upcoming releases (2.7.0 or 2.8.0).
Best regards,
Wolfgang
-----Original Message-----
From: Dr Josef Karthauser<EMAIL_ADDRESS>To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>Sent: Wed, Jul 15, 2015 10:44 PM
Subject: [jcypher] transaction docs missing! (#4)

Hi there, I've been through all the docs, but I can't find anything about how JCypher deals with transactions?
Is this missing from the docs?
Thanks,
Joe
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub .

Hi Joe,
sorry for my slow response, but I was on vacation on a sailing trip in the adreatic sea.
I will make a transaction api part of the next JCypher release (2.7.0)
Best regards,
Wolfgang
-----Original Message-----
From: Dr Josef Karthauser<EMAIL_ADDRESS>To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>Cc: Wolfgang Schuetzelhofer<EMAIL_ADDRESS>Sent: Thu, Jul 16, 2015 04:06 PM
Subject: Re: [jcypher] transaction docs missing! (#4)

Ahha, I guessed it was something like that.
I’m currently using SpringDataNeo4j - and want to get away from Spring as soon as possible. JCypher looks like an ideal candidate! :)
:)
Cheers,
Joe

On 16 Jul 2015, at 15:02, Wolfgang Schuetzelhofer<EMAIL_ADDRESS>wrote:

Hi Joe,

currently every query is performed as a single transaction. A distinct transaction interface (begin, commit, rollback) will be part of one of the upcoming releases (2.7.0 or 2.8.0).

Best regards,

Wolfgang

-----Original Message-----

From: Dr Josef Karthauser<EMAIL_ADDRESS>

To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>

Sent: Wed, Jul 15, 2015 10:44 PM

Subject: [jcypher] transaction docs missing! (#4)

Hi there, I've been through all the docs, but I can't find anything about how JCypher deals with transactions?

Is this missing from the docs?

Thanks,

Joe

—

Reply to this email directly or https://github.com/Wolfgang-Schuetzelhofer/jcypher/issues/4">view it on GitHub.https://github.com/notifications/beacon/AHI-30O87VRRYnM6L4jb7VvTXq2IOr9Mks5odr2wgaJpZM4FZZcf.gif">;

—

Reply to this email directly or view it on GitHub <https://github.com/Wolfgang-Schuetzelhofer/jcypher/issues/4#issuecomment-121966247>;.

—
Reply to this email directly or view it on GitHub.

Very nice! :) Welcome back, and thanks for your feedback.
Merci,
Joe

On 19 Jul 2015, at 14:09, Wolfgang Schuetzelhofer<EMAIL_ADDRESS>wrote:
Hi Joe,
sorry for my slow response, but I was on vacation on a sailing trip in the adreatic sea.
I will make a transaction api part of the next JCypher release (2.7.0)
Best regards,
Wolfgang
-----Original Message-----
From: Dr Josef Karthauser<EMAIL_ADDRESS>To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>Cc: Wolfgang Schuetzelhofer<EMAIL_ADDRESS>Sent: Thu, Jul 16, 2015 04:06 PM
Subject: Re: [jcypher] transaction docs missing! (#4)

Ahha, I guessed it was something like that.
I’m currently using SpringDataNeo4j - and want to get away from Spring as soon as possible. JCypher looks like an ideal candidate! :)
:)
Cheers,
Joe

On 16 Jul 2015, at 15:02, Wolfgang Schuetzelhofer<EMAIL_ADDRESS>wrote:

Hi Joe,

currently every query is performed as a single transaction. A distinct transaction interface (begin, commit, rollback) will be part of one of the upcoming releases (2.7.0 or 2.8.0).

Best regards,

Wolfgang

-----Original Message-----

From: Dr Josef Karthauser<EMAIL_ADDRESS>

To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>

Sent: Wed, Jul 15, 2015 10:44 PM

Subject: [jcypher] transaction docs missing! (#4)

Hi there, I've been through all the docs, but I can't find anything about how JCypher deals with transactions?

Is this missing from the docs?

Thanks,

Joe

—

Reply to this email directly or https://github.com/Wolfgang-Schuetzelhofer/jcypher/issues/4">view it on GitHub.https://github.com/notifications/beacon/AHI-30O87VRRYnM6L4jb7VvTXq2IOr9Mks5odr2wgaJpZM4FZZcf.gif">;

—

Reply to this email directly or view it on GitHub <https://github.com/Wolfgang-Schuetzelhofer/jcypher/issues/4#issuecomment-121966247>;.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub .

Hi Joe,
JCypher 2.7.0 has been released today.
It now provides a transaction API. It's usage is documented in the wiki at:
P08 Transactions
Best regards,
Wolfgang
-----Original Message-----
From: Dr Josef Karthauser<EMAIL_ADDRESS>To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>Cc: Wolfgang Schuetzelhofer<EMAIL_ADDRESS>Sent: Mon, Jul 20, 2015 1:41 am
Subject: Re: [jcypher] transaction docs missing! (#4)
Very nice! :) Welcome back, and thanks for your feedback.
Merci,
Joe

On 19 Jul 2015, at 14:09, Wolfgang Schuetzelhofer<EMAIL_ADDRESS>wrote:
Hi Joe,
sorry for my slow response, but I was on vacation on a sailing trip in the adreatic sea.
I will make a transaction api part of the next JCypher release (2.7.0)
Best regards,
Wolfgang
-----Original Message-----
From: Dr Josef Karthauser<EMAIL_ADDRESS>To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>Cc: Wolfgang Schuetzelhofer<EMAIL_ADDRESS>Sent: Thu, Jul 16, 2015 04:06 PM
Subject: Re: [jcypher] transaction docs missing! (#4)

Ahha, I guessed it was something like that.
I’m currently using SpringDataNeo4j - and want to get away from Spring as soon as possible. JCypher looks like an ideal candidate! :)
:)
Cheers,
Joe

On 16 Jul 2015, at 15:02, Wolfgang Schuetzelhofer<EMAIL_ADDRESS>wrote:

Hi Joe,

currently every query is performed as a single transaction. A distinct transaction interface (begin, commit, rollback) will be part of one of the upcoming releases (2.7.0 or 2.8.0).

Best regards,

Wolfgang

-----Original Message-----

From: Dr Josef Karthauser<EMAIL_ADDRESS>

To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>

Sent: Wed, Jul 15, 2015 10:44 PM

Subject: [jcypher] transaction docs missing! (#4)

Hi there, I've been through all the docs, but I can't find anything about how JCypher deals with transactions?

Is this missing from the docs?

Thanks,

Joe

—

Reply to this email directly or https://github.com/Wolfgang-Schuetzelhofer/jcypher/issues/4">view; it on GitHub.https://github.com/notifications/beacon/AHI-30O87VRRYnM6L4jb7VvTXq2IOr9Mks5odr2wgaJpZM4FZZcf.gif">;;

—

Reply to this email directly or view it on GitHub <"; target="_blank">https://github.com/Wolfgang-Schuetzelhofer/jcypher/issues/4#issuecomment-121966247>;;.

—
Reply to this email directly or view it on GitHub.;

—
Reply to this email directly or view it on GitHub ;.

—
Reply to this email directly or view it on GitHub.

Cheers Wolfgang.
Looking forward to evaluating it. :)
Anything to get off spring! :)
Joe

On 24 Aug 2015, at 16:56, Wolfgang Schuetzelhofer<EMAIL_ADDRESS>wrote:
Hi Joe,
JCypher 2.7.0 has been released today.
It now provides a transaction API. It's usage is documented in the wiki at:
P08 Transactions
Best regards,
Wolfgang
-----Original Message-----
From: Dr Josef Karthauser<EMAIL_ADDRESS>To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>Cc: Wolfgang Schuetzelhofer<EMAIL_ADDRESS>Sent: Mon, Jul 20, 2015 1:41 am
Subject: Re: [jcypher] transaction docs missing! (#4)
Very nice! :) Welcome back, and thanks for your feedback.
Merci,
Joe

On 19 Jul 2015, at 14:09, Wolfgang Schuetzelhofer<EMAIL_ADDRESS>wrote:
Hi Joe,
sorry for my slow response, but I was on vacation on a sailing trip in the adreatic sea.
I will make a transaction api part of the next JCypher release (2.7.0)
Best regards,
Wolfgang
-----Original Message-----
From: Dr Josef Karthauser<EMAIL_ADDRESS>To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>Cc: Wolfgang Schuetzelhofer<EMAIL_ADDRESS>Sent: Thu, Jul 16, 2015 04:06 PM
Subject: Re: [jcypher] transaction docs missing! (#4)

Ahha, I guessed it was something like that.
I’m currently using SpringDataNeo4j - and want to get away from Spring as soon as possible. JCypher looks like an ideal candidate! :)
:)
Cheers,
Joe

On 16 Jul 2015, at 15:02, Wolfgang Schuetzelhofer<EMAIL_ADDRESS>wrote:

Hi Joe,

currently every query is performed as a single transaction. A distinct transaction interface (begin, commit, rollback) will be part of one of the upcoming releases (2.7.0 or 2.8.0).

Best regards,

Wolfgang

-----Original Message-----

From: Dr Josef Karthauser<EMAIL_ADDRESS>

To: Wolfgang-Schuetzelhofer/jcypher<EMAIL_ADDRESS>

Sent: Wed, Jul 15, 2015 10:44 PM

Subject: [jcypher] transaction docs missing! (#4)

Hi there, I've been through all the docs, but I can't find anything about how JCypher deals with transactions?

Is this missing from the docs?

Thanks,

Joe

—

Reply to this email directly or https://github.com/Wolfgang-Schuetzelhofer/jcypher/issues/4">view; it on GitHub.https://github.com/notifications/beacon/AHI-30O87VRRYnM6L4jb7VvTXq2IOr9Mks5odr2wgaJpZM4FZZcf.gif">;;

—

Reply to this email directly or view it on GitHub <"; target="_blank">https://github.com/Wolfgang-Schuetzelhofer/jcypher/issues/4#issuecomment-121966247>;;.

—
Reply to this email directly or view it on GitHub.;

—
Reply to this email directly or view it on GitHub ;.

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub https://github.com/Wolfgang-Schuetzelhofer/jcypher/issues/4#issuecomment-134260843.


minor: default error message should contain the quick fix that works in ~99% cases

Suggest the command that can fix the issue, so that users unfamiliar with the plugin can do the quick fix.

Hi @jkremser : I will merge your PR as soon as the tests pass. Thanks!

Hi @jkremser : I will merge your PR as soon as the tests pass. Thanks!

You will need to rebase too ;-)

tests need to be updated too.


Restore stream position in ArchiveFactory.IsArchive

closes #870

By resetting the stream position after the archive check, the stream position will be restored to its original value after the method returns.

Thanks!


Cannot subscripe to Launchpad Service

I tried many ways to find the Launchpad Service and it doesn't show up anywhere. I am using BTP Free trial account.

I adopted the service naming from "SAP Launchpad Service" to "SAP Build Work Zone" (branch "s4hc-int").
I fully understand your ask to build and deploy the sample application on a BTP trial account. However, we are currently focusing on the integration with S/4HANA Cloud and assume a productively usable customer or partner BTP account.


feat: Added modern workflow for SurfGear packages

Changes

Added FVM for version management
Added version pick for actual workflow
Fixed package exports to minimize analysis errors

Note

Only analysis errors that left - is deprecation warnings, they must be fixed in separate PR

Codecov Report

:exclamation: No coverage uploaded for pull request base (dev@128ffd3). Click here to learn what that means.
 Consider uploading reports for the commit bf71163 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             dev       #87   +/-   ##
=======================================
  Coverage       ?   100.00%
=======================================
  Files          ?         4
  Lines          ?       254
  Branches       ?         0
=======================================
  Hits           ?       254
  Misses         ?         0
  Partials       ?         0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Adding local HTML file as custom service

Hi there, yesterday I've discovered Ferdi and it's really awesome.
After adding several services, I wanted to add a SPA HTML (Angular based) app as a local file, that doesn't need a server to work.
However, the URL gets rejected - no matter if it's the (Windows) filesystem path, or adding the "file://" prefix.
I was already sweeping through the web and reading this repo for possible solutions.
Any workaround would be much appreciated.
Cheers.

I researched this a bit further. A fix is needed on this line unfortunately. But, yes, a local web server will bypass this current limitation. Tx


Travis configuration, tox env list and README update.

Restore Django 1.8 configuration instructions.
Update to Travis and tox config files to test newest versions first.

Rebased, tox configuration changes are redundant after rebase.

LGTM


Link Rot: donottrack-doc.com

Tracking the Link Rot of donottrack-doc.com

This was fixed with 559b6e1


Missing build object gc ?

/area monitoring
/area test-and-release
/kind dev
Expected Behavior
build controller handle the delete event from build informer, and do somthing like that in the case of build timeout
https://github.com/knative/build/blob/846036c8b91df25fa57da4d48a8ae5f9129c81f0/pkg/controller/build/controller.go#L286-L289
Actual Behavior
https://github.com/knative/build/blob/846036c8b91df25fa57da4d48a8ae5f9129c81f0/pkg/controller/build/controller.go#L135-L140
lack of DeleteFunc handler impl

DeleteFunc is triggered when build object is deleted(AFAIK). How does implementing Deletefunc address timedout build GC?
If build is timedout I do not think we want to delete the build itself. It is valuable to hold onto the build status because it contains information of failure.
The only use case I could think of cleaning up builds is when user has piled up too many objects over time and want to cleanup. For this use case I could see an operator configuring like a month(or more) after which builds are automatically updated. Are you thinking of this use case ? or am I misunderstanding this altogether.

thanks for reply @shashwathi , no, i miss something ... the pod of build will set the ownerReferences
https://github.com/knative/build/blob/846036c8b91df25fa57da4d48a8ae5f9129c81f0/pkg/builder/cluster/convert/convert.go#L352-L359
and if the build resource is deleted by user, gcController (in kube-controller) will delete the pod belongs to it

// List of objects depended by this object. If ALL objects in the list have
// been deleted, this object will be garbage collected.
OwnerReferences []OwnerReference

currently, DeleteFunc is useless in my opinion ...