16-bit resolution pixel maps for finer coordinate detail. Existing maps will continue much the same after the update, but if you visit the mapper tab and hit save, your map will be regenerated from your source coordinates and saved in higher resolution.
Patterns with only a render3D will now work when only a 2D map is installed. By default z is centered on 2D maps.
WiFi can go passwordless - both connecting and AP.
Can update in setup mode. The /update URL will work and can be used while in setup mode. This can be helpful to recover from cases where the main page has been corrupted.
Fix issue with timesync issue when an AP PB and client PB boot up less than 5s, but more than zero. Just like what might happen if you tried to make a costume with multiple PB.
Moved webserver to another thread, should block websockets less.
Show free storage space in UI
Show network and MAC on WiFi page
Nuke NVS storage when doing a wifi reset - hopefully fix those weird wifi issues.
Shows PB name in page title and in nav bar
X, Y, Z axis lines shown on mapper preview for 3D maps. There is also a change in the preview - Y now grows away from you instead of toward you. It was flipped unintentionally before. Pixel rendering is unchanged.
Read-only editor tags. These allow you to make sections of a pattern read-only and are handy for creating instructional patterns where you don’t want some bits of code to be changed accidentally. Add <lock></lock> pairs across lines in comments, or </lock> in a comment on a single line to mark that area read only. You can toggle the locking with a button, so it’s easily reversible.
Alias === and !== so that code is more easily portable.
Coordinate transformation API lets you quickly change coordinates when using a 2D or 3D pixel map. This is handy for rotating, zooming, and scaling! See these docs for more detail.
transform(m11, m21, m31, m41, …)
rotate(a) //alias of rotateZ
This is a bugfix/stability update which helps address some issues with the update process itself.
The previous update process (used in all previous versions of V3) would download and install another copy of the main web app first before swapping it out for the new version. The idea there is you would still have a working system if the update failed mid way (loss of internet, power, crash, etc). This required a lot of extra free space, and could be very slow in some cases were space was tight or there was fragmentation, potentially causing timeouts and unsuccessful updates.
V3.18 addresses this issue by first replacing the main app with a very small recovery app (~3k), freeing up a massive chunk of space before the new version of the main web app is installed during the update process. This will work with previous versions of Pixelblaze V3 as well, so no worries if you have an older version.
In addition to freeing up space first, if something happens during the update process the recovery app can be used to configure WiFi (in the event the device was put back in setup mode), and to update / repair the firmware by applying an update again. In past updates, this required a complicated set of actions.
The recovery page is also installed at /recovery.html should the default app become unavailable.
In addition to that, if you upload a firmware update file manually using the recovery page, you can can see the progress.
Just tried to update a (standard) pb3 – it seems to have downloaded the update, then got stuck at the “loading” screen in client mode. I reset to AP mode, same behavior. ( I deleted most of the patterns beforehand this time to make sure there’d be plenty of room.)
I’m about to go down the List of Things To Try, starting with using /update to manually drop back to the previous firmware.
Update: after using curl to reconfigure wifi, was able to get back to 3.16 firmware. Is there anything I ought to check or set up differently before I try this again?
I would try updating again. I suspect its a problem with the update process rather than the version itself.
If you update again and get stuck at “loading” it would be interesting to see a browser console. Wonder if it’s the HTML page getting corrupted, or somehow the websocket connection.
BTW this version, once applied, you don’t have to go through the curl post stuff. You can upload an update even in wifi setup mode. To do that, close the capture portal, and open a brower to http://192.168.4.1/update
I kept getting a generic error message about the update failing while the file 1/2 was downloading, but after deleting most of the patterns it had no issues updating. Once I restored all of the deleted patterns, I’m showing 370K of free space on the Patterns list.