Pretty cool. When I took the train to work I made a simple stop-light with transit data. Trains ran every 10 minutes and it took me a few minutes to walk to the station. Green meant I could definitely catch the next train. Yellow meant I'd make it if I walked fast, and red meant I'd miss this train and need to wait for the next one.
Cheers, nice to know it's appreciated. Someone actually asked me to change it to say "Good Service" the other day! Whoosh...
There is a ~mirror at https://unop.uk/tube/ in case CloudFlare go down. Although as I discovered recently, this doesn't help as the API runs on them too! There's another API I could use as a backup but it's not as good.
I made something similar when I was in uni and had to catch a bus to get back home, but with my Pebble and a C application: next bus was one button press away and another press was all was needed to start a carefully calibrated double alarm for "start packing" and "leave" times
I was using a physical RGB LED so there wasn't much extra bandwidth for conveying information. I live in a cold climate so green really meant "Leave now and you'll only have to wait in the cold at the stop for 2-3 minutes". Here's the code if anyone's interested[1]. Looks like my memory wasn't quite right, I did blue/green/red with blue=wait, green=leave, red=missed.
Much better than the MTA's website... though slightly less useful if you're not me commuting to work.
What I learned from this exercise is that:
1) The estimates are consistently inaccurate; downtown trains at Chambers St. always arrive when the clock says "2" (minutes until arrival).
2) They use some sort of distributed cache that doesn't remain consistent; as you bounce between backend instances you get different results, but often the same two results. (The red/green lines under the station names indicate freshness.)
3) The clocks in the stations don't work when it's too hot, but the actual data collection/processing is fine.
That's interesting. Worked on a service based on TFL (London) data, and they were incredibly picky about ensuring people would not get misled by signage. Of course sometimes there are tradeoffs, but they had extensive rules to ensure the tradeoffs minimised negative experiences. E.g we had to take any buses off the boards if the data was more than x seconds old, never ever allow enough clock drift or other issues to cause our displays to be off by more than a certain amount, clear the whole display if we got no api response within a certain amount of time etc.
It was very annoying to implement, but as a user it is very nice to know how much thought has gone into it.
Hey folks, balena.io founder here, just chiming in to mention that Chris is one of our Hardware Hackers in Residence, and if you think that doing HW projects with all sorts of cool technologies and writing them up for the world is your dream job, we're hiring! https://balena.workable.com/j/27A101659C
Happy to answer any balena (or train station sign) related questions, of course :)
I haven't used balena but I have worked with other IoT SAAS companies in the past. All these services seem rather expensive for what you get. Other than creating an easy way to push OS updates to field devices what would I get from your service?
You can't ask a founder this and not expect a pitch, so here goes:
Having built a similar bespoke stack in the past, Balena would have been a steal! It gives you the development, provisioning, build & deployment, configuration, management, and even remote debugging workflows out of the box. On top of that, it's built to require web/cloud developer skills, not embedded skills.
To do that, we have created several companies worth of infrastructure, from a cross-architecture container build system, to a bespoke OS supporting many device types, customized docker engine for embedded use cases, container deltas for bandwidth saving, etc. Even simple things like "how do I make sure my device gets DNS in an arbitrary home network" are incredibly tricky, and balenaOS gets it right almost always.
Which brings me to my next point. We are fanatical about support. We take responsibility for our customers succeeding, which means we constantly find and improve sources of friction. Using Balena gets you that backup team, but most importantly gets you hooked up to the flow of improvements we make all the time. Cloud companies charge $15 per server per month for various devops type services. We do very similar things but for devices that are smaller, more diverse, in tougher conditions, with less reliable networking, and ask for just $1 per device per month.
In other words, when I was in the shoes of our customers, producing even a fraction of the value and piece of mind that Balena provides in house took a lot of work, which was money, and that's not accounting for the time and risk of not getting there in the end. If I found myself in that situation again, knowing Balena and not using it would essentially be negligent. Our most fanatical customers are those who have tried to build something like it themselves, because infrastructure is so easy to underestimate.
Note: I am in no way affiliated to balena, only a happy customer.
As a long time customer of balena, I can assure they are a ton for what you pay for.
* faster development times: git push and your code is built and compiled in their cloud (with real ARM servers), and downloaded from your devices. Doing CI/CD for iot is a great experience with balena.
* the support is tremendous: several times I found very specific use cases that failed or wasn't what the balena APIs where expecting, and after contacting the support, they even put me directly with the developers in charge of those areas to discuss if it makes sense to add it as a feature to balena, or if they can provide me a workaround
* again, the support: I have around 10 years of experience with Linux derived systems, but some things still are black magic to me (like debugging problems with aufs partitions). The support of balena goes to the deepest level possible to solve your problem, even if you aren't in the private support tier. You just enable access to your board to support and they get inside and try to find the problem. It's truly amazing. They are even open to discuss how to improve what they are giving you or the tools.
* total control of your fleet: need to set a flag for a client? Just set an environment variable from the api or the dashboard and each device will update its state when they come back online
* amazing tools: the balena dashboard feels as polished as their other projects, like etcher, if not even more. Any kind of need you have (remote access to the device? Proxy to a port in the device? contact the supervisor of the device from a proxy inside their VPN?) they give to you.
I have been looking at building a project on Balena OS and raspberry pi 0 W. I want to deploy it in a hard to get to place and don't want to have to replace the SD card for a good amount of time.
I was wondering if Balena OS with Balena cloud managing it puts more or less strain the the sd card write cycles than Raspbian.
Chris's application seems to write little or nothing to the sd card so in your experience how would it last? A couple years?
Hey, balenaOS has been designed for long term deployment. As such, we have a read-only partition for the hostOS. We also have a second host partition so we can update the OS remotely and atomically. In general, we've tuned all sorts of elements in this direction as our customers really don't want to run around collecting sd cards from all over the world.
Thanks,
Have you done any testing on the effect of something like leaving persistent logging on vs off. I know that writes to the state partition which is not read only.
Is there a way to push device logs to another service to keep track of them long term?
How did you come up with the pricing model of essentials vs micro-services?
Persistent logging is only there for cases we need to debug something, in other words where it's the only choice. Even so, it writes to a circular buffer so it should be reasonably safe. But it's not intended to be on by default, more like an emergency measure. We do push logs to our server to some degree, and some customers use proper devops platforms to manage their logs, but we definitely want to do more in the future.
The pricing model is along the lines of "essentials is for people looking for a better OTA solution whereas microservices is for people who consider their devices mini-servers". So it's more a difference of perspective of the customer that allows us to group features and give more to the one crowd without alienating the other crowd with high prices. Not sure if that makes sense.
Cool project thank you for sharing it! I was checking out BalenaCloud and BelenaOS and noticed you support more advanced embedded devices (such as the pi) but are there any plans on supporting lower cost IoT devices? Similar to Azure IoT hub, Amazon FreeRTOS IoT, etc?
In either case I can completely see the value in these IoT SaaS services. A lot of companies I see which want to get into IoT are experts in their own field - not networking. It is very easy to underestimate how much work it is getting everything up and running which is required for a product. You can always roll your own cloud solution later on once you gain the expertise and market fit.
We're currently focused on devices that can run Linux. The smaller devices are a different kind of challenge, and while we do have some ideas about how to achieve the same level of developer experience for them, it's not out yet. :)
That would be really amusing. Those are called Solari boards, by the way, after the manufacturer (Solari di Udine).
Maybe someone enterprising might (or has?) created a character flipping routine that mimics the search through the tiles and set it to the authentic sounds?
The attempt by that company to create their own digital version is really bad. (search youtube for it)
I don't think vestaboard ever ended up shipping. I was somewhat interested in getting one, but now I'm really glad I didn't put down a deposit. Original estimates were Dec 2018 ship date, now they say Summer 2020.
They're really cool! The original Solari
board modules are mega expensive though. I looked at getting some to make a clock, and it probably would have cost me in the thousands.
As an indirect result I now have a project in the works to make them. The concept is simple, but building them to be inexpensive is a challenge. Every extra bracket or fastener gets multiplied by _n_ modules.
Right now it's focusing on 40-character flaps (not super convent for clock-making), but it's open-source so I'm sure you could modify it for your purposes with some effort.
That's just for the enclosure. It looks like it comes out to 60-70$ depending on how you build it. I'm targeting sub $50, but it's tough. Good resource though, didn't know about those cheap geared stepper motors.
I too have been wanting to make a split-flap display. I would be interested to hear more about your project if you have any posts or resources somewhere.
I've been taking notes as I go, going to put together a slide preso at some point with stuff I learned in the process.
I'm a lazy engineer, so I avoid doing tedious hand-crafted stuff. I'm using 30pt museum board for the flaps currently (I was going to use plastic, but found that matte paper types of material work really well).
Thus most of the work has gone into designing something that's highly repeatable with minimal labor. All the cards are printed and then laser cut, the bracketry will be CNC waterjet and has a single bend, the center hub is 3D printed. I'm making it DIN rail mountable for easy installation and maintenance.
I have a small one in my office that tells the time & updates the S&P every 15 minutes. It's surprisingly loud. Especially at the top of every hour when all of the dials are flipping I've more or less gotten used to it but I have one colleague who refuses to have any meetings in my office because they find it so distracting.
There is something to be said for these kinds of vestigial remnants of technologies past. I've always been fascinated by them, and in fact this kind of thing in computer folklore -- for example parts of the docs that explain something exists "for historical reasons" -- are one of the things that got me into programming. For example the "size_t" size has pretty funny origins which I'll leave as an exercise to the reader. But this kind of thing also has a linguistic component which is also equally fascinating to me. For example how we still "dial" a phone, which then "rings" for the person being "called".
"Yep. Its origins lie in the old <std.h> header we developed at
Whitesmiths, Ltd. in the late 1970s. We used the typedef BYTES
as the type of sizeof, to be sure we could count all the bytes
in the largest declarable (or allocatable) object. X3J11 chose
size_t to follow the *_t convention that had begun to creep up
in Posix."
If you're ever in my part of the world, you should visit the Connections Museum[1]. It is truly humbling to see how far we've come. At this museum, you can dial a phone, hear the 'thinking' of all the electromechanical switching crossing the room, before the phone starts ringing.
One of my favorite examples of this is the HTTP_REFERER. Someone made a typo in the RFC in 1996; software developers a century from now may well still be spelling it "referer" as a result.
We've had a short project at some point recreating a station's big departure times flipboard in an ipad app; my colleagues went out there for a couple hours to just look at the thing, record background and noises, write down its behaviour and draw the small nuances and damages in the flippers and their contents. Over a weekend my colleague made a POC of the animation of a single unit, then in the next week the two of us copied that one over in a big grid to display departure times from the API. It was a really cool little project, and IIRC the managers of the organization we made it for would frequently just have it open on their desk or show it off to people.
I'm working on a few projects at home with ESP and RPi Zero.
It's so much fun to do your own "IoT" devices.
There's still a problem I don't know solve well, holistically. When you do something with UI there's inputs from humans (buttons, knobs, etc), the network and timers.
I'm completely lost how to coordinate that, especially when I use an LED/OLED display.
How to make sure a single screen is displayed long enough to be readable? But on the other hand how to react to all inputs? And how to deal with some inputs/triggers being more and less important (e.g. "modal" screens over static screens)? Also how to make sure not to get lost in the threading mess that I just created? The cherry on top is, some inputs require "short term memory" -- like patterns of button pressing (double/triple press/long hold) or rotary encoders.
In the end I give up implementing a lot of features.
Each task has its own stack, and can communicate with other tasks with mailboxes or shared memory (with a lock).
You'd have a task for each of the things you mention: debouncing a button, drive the display from a buffer, and application logic.
The application logic then doesn't have to worry about bounces, how long it'll take to drive the display, etc.
Modal screens over static screens is orthogonal to this though. You'd need to build a priority scheme, and only pass down events to the current on-screen view.
One thing that always annoys me with those signs is when they try to put too much information on them. You have all of the stops, fine. You then have all of the information about the train splitting which you might well need. But then they start adding information about short platforms etc. It takes several minutes for it all to scroll past. Which is super annoying if you're trying to work out if the train standing there stops at your station.
I know it's a lot less complex, but on the MBTA all of the signs only show next two trains and how long they'll take to arrive. The extra information comes in where each of the displays are.
They would, but the Pi Zero is a much better UX for people who don't deal with microprocessors on a regular basis. It has SSH, I can get in and look at logs from my desktop, wifi is standard. It all adds up - and for something like this, the power draw is not an issue, and the cost is minimal.
I think the relevant distinction that should be made is that a bloated hardware project is only going to be seen and experienced by one person, whereas a bloated website is slow for all.
I hate Electron apps as much as the next person, but it's indisputable that to get a simple desktop app deployed, Electron is easier, and to me that signifies that it serves a purpose, at least in the prototyping space.
I have like 10 ESP32's lying around my house, they're fun to tinker with, but my Raspberry Pis get a lot more attention from me because there is a substantially lower cognitive overhead with them than the ESPs. If I had a plan on selling my stuff, then yeah, the Raspberry Pi might be overkill and I'd consider going for an MCU module. However, for a fun little DIY project, I don't see how an RPi is a problem.
EDIT:
Realized I forgot to mention another point; not everyone really wants to muck with pointer arithmetic for simple things; this app was written in Python, and as far as I know, the ESP32 chips are mostly C/Arduino; I realize that there exists NodeMCU and such variants, but due to the Raspberry Pi being "Just a computer", you have access to virtually every language under the sun.
Actually esp32's are quite fun and easy to program with micropython. Something like this project should be pretty straightforward and would arguably much easier than a pi. For micropython there is only the python code, no docker containers, Linux maintenance etc. And remote development can be done over a an http repl or even using jupyter notebooks (still have to try but just read about it). Doesn't get much better than that I think
> I hate Electron apps as much as the next person, but it's indisputable that to get a simple desktop app deployed, Electron is easier
Easier than what? Considering you have to use the already ill-suited for UI HTML/CSS/JS cesspit, I'd say Electron is a lot worse for the "simple desktop app" than something like Lazarus.
Using the PI Zero over an ESP doesn't negatively impact the experience using it. Whereas a very bloated website is going to be slow to load and use. I think there is a significant difference.
On the other hand, it is also overkill to learn how to program and deal with an ESP32 if you already know some light linux sysadmining and some high level programming language to set this up.
ESP32 can run μPython which should make it quite a bit easier for those that know some high level programming language. For me using an ESP32 seems like the more reliable, secure, easier and faster solution but people have their preferences and I relate to it being a bit scary at first.
μPython is great - I am not complaining about it, but for someone who is tinkering with a project, it is different enough from Cpython to make things frustrating.
If this was a commercial project, I would agree completely (and from a BOM cost, the manufacturer would be a lot better off investing the time in the dev on a microcontroller)
A restricted port of a language isn't the same thing as the full language. On a Raspberry Pi, you have access to POSIX, system libraries, filesystems, package managers, etc...
μPython is fine, but typically a programming language is about more than just the language.
If this is being designed as a consumer device that may be true, but the ESP devices have their own issues and the pi makes for a great proof of concept!
The ESP32 boards I have were £6, including postage. Can't find a Pi Zero for less than double that when including postage costs.
They're designed for different things though - if you wanted a battery powered version that updated on a button press else slept, ESP, if you want live updates all the time, Pi is fine!
ESP32 uses less power. When you use deep-sleep, you can draw as low as 40microAmps, a sensor I've build on a ESP32 has been running for 3 months on the same battery and I expect one more out of it. The battery is a 2200mA LiPo 18650, so nothing that extraordinary either.
The Pi0W probably won't run a day on the same battery.
Though it's important to keep in mind that deep sleep can fairly long, if you use external triggers, you can go days or months in inactivity, which saves A LOT of power.
Though I do agree it depends on your use case, if you're plugged into the wall, a Pi0 might be the better option.
Dev boards, or modules to solder onto a circuit board? If you are printing your own board, then yes, the ESP32 is way cheaper. If you are just making a one-off, though, I'm not sure where it wins except in power consumption.
this are dev boards. Just look here for example: https://www.aliexpress.com/item/32656775273.html, the nodemcu dev with USB for 3,55. You can even get a fully working board with a webcam for under 5 bucks (though that does need a UART bridge, no usb included). Unmounted esp32 chips are going for as low as 2,10
I like the emergence of these cheap, fun, single function computing devices. Sure, it is useful to have a smartphone that does everything, but that doesn't help develop your internal map of reality in the same way as things like this do.
Ubuiquity can only be stretched so far in a single tool before the benefit you derive from adding yet another feature is outweighed by it becoming very slightly worse at everything else it does. Smartphones are great, but as a backup computing device, in much the same way keyring multitools are. And the best of them are still measurably worse than the best non-smartphones at actually being mobile phones.
Well, sometimes you are in Do not Disturb mode, so notifications don't come through. Also, this thing would always be on, and you simply need to glance over to see:
Next meeting in X minutes. Also my calendar is kinda full, so seeing conflicts for the next meetings would be super-cool.
...so let me get this straight. You've specifically told your computer not to remind you about meetings in the straight-forward built-in way it can, and want to build a separate overengineered reminder system out of an overpowered toy to do the same thing?
Christ. No wonder everything in our industry sucks.
As a total PI noob, it's great to see such clear and simple to follow instructions for something actually practical. Also liked the specific recommendations for the case and such - it would be really easy for someone to replicate.
Been meaning to get a PI and do something with it for years!
I remember trying to do a similar project for the bus stop at the corner of my street to know when to leave to catch the bus. It was fun, but I never really finished when I realised how big just the Pi would be (still powered by usb-a, etc).
I’m patiently waiting for a Pi Zero format for new Pi 4B (or something close...).
Regarding the size of B series, unless I need the ports, I almost always snip out the ports — don’t bother desoldering it, the ground plane in Pi acts as a massive heat sink. Instead, I snip slowly and carefully the metal housing of ports, and then wiggle the plastic bits until the break away. Reduces the size, and leaves sufficient space to put small modules in place.
For me, repeatability and ease of management - I used to be really demotivated by having to start from scratch with a Raspbian install whenever I built a project but all the prebuilt base images for different languages/OS and configuration as code due to Docker make the Pi so much nicer to use for stuff like this.
I'm working on a pi zero version of my own at the moment.
The National Rail Enquires api's (Darwin) are free to use at personal (and surprisingly large) scale. They may be SOAP but still easy enough to talk to with some simple python. https://www.nationalrail.co.uk/46391.aspx
And it made me wonder if bus transport data in my city is available for everyone - we got few displays around, two services/applications that show the current position for each line...
Why I can't use my old phones to do this is beyond me. I have one windows phone lying around and a few android phones. Everything is there in a neat package but the manufacturer make it so hard to tinker with them.
What's preventing you from using an old phone for this? There's no specific hardware (other than driving the display, which your phone already has), right?
Blame the rise of the app store. The old Windows Mobile phones were fully open and work just fine for what you want; write your app, load it onto the phone, and just launch it.
Once did a project like this that grabbed Seattle's realtime data for some bus stops around my place. It was an old Windows CE PocketPC thingy, so the tools were primitive (.NET compact framework 1.0, basically).
Maybe a bit too primitive. It worked pretty well for about a year, until I found that the CompactFlash WiFi adapter was only 802.11b and there was nothing newer available that was compatibility with the PocketPC. It ended up being a choice between keeping the gadget running, or being able to run my WiFi network at 802.11g speeds with modern (WPA) security, so the latter won out.
For a one off project, why wouldn't an old android phone work? It isn't that hard to sideload an app onto the device, and apps can be developed to comm with external devices through USB OTG adapters.
