Here’s what’s new:
- Coordinate transformation API - see below!
- 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
render3Dwill now work when only a 2D map is installed. By default
zis 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.
!==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.