eternityforest

An experimental mesh network protocol, that is still very much pre alpha and missing some features.

The big thing I wanted to try is automatic global routing via MQTT.

Everything is globally routable. You can roam around between gateway nodes, as long as all the gateways are on the same MQTT server.

And there's a JavaScript implementation that connects directly to MQTT. So you can make a sensor, go to the web app, type the sensor's channel key, and see the data, without needing to create any accounts or activate or provision anything.

https://github.com/EternityForest/LazyMesh#

I start with the standards. What file types and protocols and external tools do I want to support? How do I make Git and SyncThing understand my files?

How do I build this on an unmodified system with unmodified popular and trusted libraries?

How do I make sure that users don't have to modify my project to use it, unless they are going to be contributors?

If I'm truly just building for myself, which almost never happens, I look at resuability. If I have to learn a new tool, what's the most general one, that I'm likely to be glad I learned when I'm doing some other project?

That is pretty much what I do, although my "thin generic program" is still very beta.

I follow the narrow waist principle, and basically have all communication in the form of setting and subscribing to "tag points", plus getting their metadata.

The controllers have some ability to run logic, in the form of web editable "If you are in this state, every frame, set this variable to this expression", and they have a generic UI to set and view all the variables.

But I don't have any legacy controllers to deal with, just ESP32s.

If I do run into legacy stuff, I just leave it alone, my main controller lets you write plugins that make whatever device you want appear as one of these tag point based devices, so I keep as much of the flexibility as possible in nice version controllable python.

I have spent over ten years (Mostly a few hours a week or less, it's pretty much done except when I want a new feature) developing a haunted house and room escape tech stack...

It's mostly the same as general home automation, except with a lot more need for audio, digital signage, DMX lighting, and media features.

And things have to be reliable on a budget. A raspi on an SD card is what you get, anything more takes away from much more important things.

Plus, live programmability, observability and diagnostics, and things like that are critical. Stuff might go wrong and you only have five minutes to fix it. This might involve actually changing game logic. It shouldn't, but it might anyway.

If you can't, you need to at least be able to take manual override control.

And you have to be able to show others how to use it extremely quickly, possibly over the phone.

Nobody dies if it goes wrong, so you can afford more complexity than industrial SCADA, but you still want much higher reliability than people expect from consumer tech.

There's a lot of automated testing, and thinking about edge cases, but not as much low level first principles work, although the firmware on remote embedded controllers has a bit more of that.

You can live with the 99.9999% (or whatever the case may be, I highly doubt anyone has real numbers for a lot of this stuff) reliability of an average complex framework, but something that can't handle a USB getting unplugged and replugged in a different port is unacceptable.

https://github.com/EternityForest/KaithemAutomation/tree/mas...

They're pretty much just upscaling and interpolating right? They can't fill in anything that's not actually there, like you could with a model that understands "Hey this tree is a actually just a PS2 era low poly model, but here's a picture of what it should look like, make it fit somehow"

I wonder if they'll ever start doing the graphics with AI.

Could you render the scene in the simplest most efficient way possible, then train a special model that takes that picture, along with the coordinates of lights, depth maps, text descriptions of materials, etc, and adds detail?

I wonder if people will start getting into ham radio for the same reason?

Unless there's a fault with the fridge of some sort.

This seems like one of the most interesting P2P projects out there.

It seems like it could be a really nice backend sync engine for offline first apps, aside from the lack of official support for Android.

> Test code doesn’t have its own test code

I would love it if we had better tools to make testing the tests explicit, line inline "This is what this code shouldn't do and it's a problem if there's no test that could catch it if it does" blocks.

Programmatically manipulating it and validating it gets harder though.

The Lourdes vs Lourdes issue could be partially solved by adding some context when searching.

Show the population and average number of other people going there, or a few pictures of the area, or even just have an LLM review what you're about to do.

I think the best GUI UXes always make the object you're going to act on visible in detail with context, they don't let you do anything to something you can't observe.

Like a file manager, not only can you restore from trash, you if you can see the file itself, you can also see the other stuff in the same folder, probably a thumbnail, maybe the modification date and the size, etc.

The file manager enforces a two way conversation, it's hard to act on an object without observing it.

For entertainment related stuff where you want really deep themability, a lot of popular frameworks seem to rely too much on non semantic classes that make it hard.

Maybe it's beneficial from a human factors perspective to have one font for printouts and screens?

Atkinson Hyperlegible is very specifically designed for visual accessibility, and it's what I use in my automation app, both for accessibility and on the assumption that it's probably also a good general purpose high reliability font.

But another comment pointed out that B612 might be specifically tested in conditions with vibration and fatigue and other factors like that. I wonder how Atkinson compares?

How would the novelty versions have been powered?

Would they have been running on batteries using a mechanical buzzer type relay to drive an induction coil?

I think what we actually need is a new standard for light bulbs with modular separate driver electronics, smart controls, and the actual LEDs.

Low voltage would mean a whole bunch of extra cables and connectors and single points of failure, and then you'd probably still need switching regulators at the point of load anyway.

Wow, if this is as good as it looks, I suspect I'll be using it quite a bit in the future, especially once it gets a brush engine!

Yes but each stack layer has to remove the waste heat from the inefficiency of all the previous layers, so usually you see them laid out in a pyramid

It seems like the "Photo and offsets" approach is pretty commonly used, and I can't personally say I have any complaints, even though the CLI enjoyers might disagree.

Maybe it could be paired with a basic image generator for common layouts?

Or maybe it could just have a set of selectable hardcoded layout engines, since "counterclockwise from upper left" and "across then down" cover a lot of things.

"Base64 of an images plus and offsets table" could just be a layout type, and people could submit PRs for anything else.

Maybe it could be something like: Your pin(or callout) Tables

Your Sections, which could have an image and some text

Your Images, that would either be literal pictures or rendering instructions that reference a table

So you could have a complete cheat sheet for any device on one page.

I'd have a hard time imagining gas pumps using just an AVR, because they have some pretty large LCD screens and fancy cryptography for tap to pay.

And I'd imagine anything that big and expensive would use Ethernet or something, rather than messing around with any low level serial link business.

But one could just make an embedded Linux based controller as one of the standard modules.

This is really cool!

I especially love the ability to flip and reverse things, since I try to avoid comparing any two objects in different orientations, to cut down on mistakes.

It would be really cool if the community had a more general purpose open standard interactive diagramming tool for this sort of thing.

I guess the easy way would be to mark up photographs with pin locations, which would map to pins in a table, allowing for multiple tables in a document.

I'm not sure how you'd capture the data in a way that could be rendered to something like a screen reader or a more abstract diagram though, without a lot of complexity and edge cases.

Would it be enough to just verbally describe the mapping between pin numbers and the physical layout, as in "Across then down, starting at upper left", or would you need a meta data scheme for that?

Everyone has an individual level of random line noise.

There's a whole field of human factors engineering that seems to agree "just being careful" is not a reasonable strategy by itself.

I have one brain, and the world contains multiple objects, which exist at the same time and don't take turns in an orderly fashion.

There will always be something I'm not consciously focusing on, and there is large individual variance in how well people can do things automatically.

It seems a bit similar to https://omnitools.app/, would it be best to consolidate some of this work?

In a perfect world this stuff would all be standardized and modular, with documented replacement parts.

Nearly all random consumer items could be done with about 15 different PCBs, total, with a dollar or two of extra cost from unused features.

A fan and a frother and a keyboard cleaning blower are all just USB chargers with a BLDC driver.

A microwave and a washing machine can share the same controller, people probably won't complain too much about the extra cost if they understand that it means the board will always be replaceable, even 50 years from now.

They could even run some kind of bytecode VM that they just don't change, so the same firmware still works in different CPUs.

Everything could be open, optionally smarthome integrated with a firmware update, and swappable like IBM PC parts.

It doesn't appear to be the kind of things businesses do, but from a technical and consumer perspective it seems totally feasible.

Is HA ready for non-hobbyists yet?

It always seems like you need $100+ dollars of hardware to run it well, not just a pi and an SD card.

It seems like it's a lot better now, but until recently it didn't seem like it was anywhere near PLC grade reliability.

Is it up to the level where you could install it at a non-technical users house and expect it to run for five years without maintenance?

Wow, I'd love to add this to my control app for escape rooms, if those Wago controllers were a bit more affordable!

I looked at a bunch of these tiny languages, and ported several of them to the ESP32, contributed some enhancements for CircuitPython.... but eventually settled on tinyexpr, and just... Not having any data types besides numbers.

TinyExpr is very fast, it's just an expression parser, and when you pair it with a state machine engine, you can do stuff like:

"While you are in state 4, if pin Y changes, set machines.foo.state5 to 1".

Which is perfectly sufficient for most "Add a bit of configurability" tasks, I can edit behavior from my phone and make small tweaks.

Anything beyond that I would much rather just do in C++, with access to all my nice dev tools and LLMs and debuggers and linters and version control.

I really like the idea of a full language on a microcontroller, but... You usually need so many bindings and application specific functions that you always wind up needing some C++ code anyway.

I also looked at ESPHome, which is super impressive, very nice to use, but light on runtime web UI configurability, the protocol is nonstandard, and the Python client libs used to have frequent breaking changes.

https://github.com/EternityForest/ArduinoCogs

You need to track individual subscribers at that point, which uses lots of ram and could use lots of airtime, heuristics like resending until you get 1 reply like Meshtastic don't work well.

If there's receive window timing issues you can't assume two nodes right next two each other will get the same subset of packets most of the time.

My solution is just to resend every message four times, and not bother with protocol layer reliability for BLE at all, the packet rate is low and all the acknowledgements use airtime anyway.

A lot of people really enjoy writing on paper. I never really got into it seriously, because it requires a lot of focus and effort, but it seems like such a cool idea.

You might get more interest if you include handwriting too.