Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Design some labels to display on things #447
(...and now hopefully in the right part of the interweb...)
I took a look at the Dymo framework support and now have the QRCodifier rendering labels.
What do you think should go on these things? How should they look? Interact with the wiki?
Hmm in fact maybe we could have these Q/R codes go to a node-red endpoint which could tweet "Somebody scanned X" and redirect to the relevant place. Cor.
I like the idea of having QR on the labels. Just a thought but using QR codes in a recent application I ran into an issue with mobile QR code readers on iOS. Those that read the code and open it in the app loop through any logic twice whereas those that open it in the browser only run the logic once. This lead to double logging and necessitated further workaround code to prevent it. I only mention this in case you get double Tweets with no obvious reason.
I've been taking a look at this with a view to seeing what I can do with a small OLED display on an ESP8266 running MicroPython.
The display I have my eye on is this which at 64x48 pixels may be pushing the envelope on what can be done with 2D codes.
Unfortunately it seems as though mobile phone code scanners tend not to support the micro QR code format. Luckily there are others available so I've been looking at Aztec.
There's an Aztec code generator here
With this I can, for example, fit a link to the DoES wiki into a code 54x54 in size including 2 pixels of padding around the edges.
You can use QRafter to scan this on iOS and it'll give you the option to open the link to the DoES wiki.
So then I started looking into what we can do with shortening the URL and providing some kind of forwarding flexibility to allow management and configuration. This should then allow us to fit into the available 64x48 pixels.
So firstly I set up a node-red flow consisting of an http input node, a function node, and an http output node. The flow listens for incoming requests on http://nodered.dynamicdevices.co.uk:1880/aztec then extracts a parameter 'n' from the GET command line and returns a redirect which is currently configured to go to https://github.com/DynamicDevices/aztec/wiki/Assets#N where N is the value taken from the incoming request.
Over at the redirection target I've set up a simple test wiki page with a list of headers corresponding to asset numbers
So this enables us to provide a parameterised URL into our node-red flow which results in a redirect to an element of a wiki page (or indeed we could make this more comprehensive and redirect to multiple locations based on some kind of mapping).
Lastly I then needed a way to create shortened URLs which would support pass-through of HTTP GET parameters. It appears not all the shortening services support this. However I did manage to find https://tr.im which does provide this service.
So then I created a shortened URL tr.im/azt which maps through to the node-red HTTP endpoint at http://nodered.dynamicdevices.co.uk:1880/aztec which then in turn redirects to https://github.com/DynamicDevices/aztec/wiki/Assets
The last piece of the puzzle was to create some Aztec codes which could then be used to trigger the redirection.
Asset 1 - tr.im/azt?n=1
Asset 5 - tr.im/azt?n=5
Asset 123456 - tr.im/azt?n=123456
You should find that using QRafter on those Aztec codes enables you to browse to the appropriate section of the asset wiki page.
Now I just need to see if this actually works when displayed on an ESP8266 attached OLED...
So how long before we've got a working version of Berg's "Clock for Robots" in DoES? http://berglondon.com/blog/2011/09/22/clocks-for-robots/ :-D
@amcewen ok this is fun...
I created a node-red flow which takes a "text" parameter on the HTTP GET line and returns the QR code for it. So the ESP8266 can pull down the QR image data instead of generating it