The firmware contractor vanished after v1.0. The device team and the app team meet only in the bug tracker. And the estimate grew a decimal place since the prototype. We take hardware products from bare metal to the cloud as one team, deliberately, and in writing.
For hardware startups, product companies, and engineering teams building sensors, controllers, and connected devices.
Firmware, edge software, connectivity, and the cloud companion: the layers a connected device needs. We work across all of them; the project on record is the NutriCent chiller logger, a prototype, and each card says how far it has got.
ESP32 in C on ESP-IDF. The project on record, the NutriCent chiller logger, runs on a classic ESP32 and also builds for the ESP32-S3 and the RISC-V ESP32-C3, neither of which it has run on yet. A task watchdog restarts a wedged task instead of letting it hang, and the reading spool survives the restart. Diagnostics today are a serial console and the dashboard: no status LED, no remote diagnostics yet.
So far, Python on a Raspberry Pi rather than custom images. The NutriCent BLE gateway listens to temperature sensors and posts one median reading per window; its logic passes 22 unit tests, but its BLE scan and upload have never run on hardware. We have not yet built a Yocto or Buildroot image, brought up a custom board, or shipped a field update.
Wi-Fi and HTTPS, written for the outage rather than the demo. The logger saves every reading to flash before sending, deletes it only once the server confirms, retries with backoff from 30 seconds to 15 minutes, and tags each reading so a resend never counts twice. On a real board it joined Wi-Fi, reconnected from saved settings after a reset, set its clock, and passed a certificate-checked TLS handshake with the production server; it has not yet been tested through an outage. BLE so far means Bench’s own peripheral and the unrun gateway. No LoRa or MQTT work yet.
The part that makes a device useful to the people it serves. For NutriCent: readings checked against each sensor’s own limits, an alert on the manager’s phone, an email to the owner if nobody acknowledges within 30 minutes, and a multi-site dashboard that flags a sensor gone quiet. A test alert from production reached a real Android phone in Chrome. No fleet management or over-the-air updates yet; the flash layout keeps two app slots so OTA can be added without a USB reflash.
A connected device is only as good as the firmware, cloud and app behind it.
Salix builds all three, like the chiller logger we made for NutriCent.
Our ESP32 firmware reads a temperature probe every 60 seconds.
It sends one median reading every 15 minutes, so a door held open is ignored.
Each reading is saved to flash first, and deleted only once the server confirms it.
It goes over HTTPS with its own device key, and a resend never counts twice.
In the cloud, every reading is checked against that chiller's own limits.
When a reading is out of range, managers get an alert on their phone.
If nobody acknowledges it within 30 minutes, the owner is emailed too.
The dashboard shows every site, and flags a sensor that has gone quiet.
Our Bench rig automates hardware tests: power cycles, button presses, voltages.
The logger is still a prototype, but a real board already reaches the live server securely.
Salix. Firmware, cloud and app, from one team.
What has run on real hardware, what has not, and what we have not done at all. Every hardware claim here comes from a dated verification record.
ESP32 firmware that reads a probe every 60 seconds and posts a 15-minute median to NutriCent. On a real ESP32 it booted, joined Wi-Fi, set its clock by SNTP, and reached the production server with its per-device key accepted. Testing on that board found and fixed a fault that would have stopped a probe fitted after the first read from ever being found. It has not yet read a real probe in service or delivered a reading.
The backend checks each reading against that sensor’s limits, alerts managers, and emails the owner if nobody acknowledges within 30 minutes. A test alert sent from production reached the owner’s Android phone in Chrome. Not yet verified: delivery with Chrome fully closed, or on an iPhone.
No embedded product has shipped, and there are no named hardware clients. Nothing here has run on batteries, on a custom Linux image, or through an OTA rollout, and we have not yet taken over someone else’s codebase. If your project leans on one of these, the scoping sprint says so in writing.
Bench is our hardware-in-the-loop test rig: ESP32 firmware that turns the board into remotely controlled relays, button presses, voltage readings, and a BLE peripheral, plus a Python library, CLI, and pytest plugin that drive it, so hardware checks done by hand become repeatable tests. The rig firmware is verified on a real ESP32, and 34 tests pass against a simulated rig. The working rig is breadboarded; its carrier PCB is routed but not yet reviewed or ordered, and no test recipe has yet run against a real device. We build it around your device.
Embedded work priced off a menu is a warning sign. Ours runs in three steps, and the first one exists to make the second one honest.
Time-boxed and fixed price: $4,500 NZD for five days, or $8,000 NZD for ten (no GST, as Salix Limited is not GST-registered). We review your architecture and constraints, build a risk register, and produce an estimate you can hold us to. The day count is agreed before we start, so neither of us discovers halfway through that “a week or two” meant something different to the other. If the honest answer is that you don’t need us, that’s the deliverable.
Priced from the sprint’s findings, delivered in milestones you can test on real hardware, not slideware. You see working firmware on your bench at every checkpoint, and the estimate doesn’t quietly drift.
Firmware maintenance, releases, and cloud operations after launch, because devices in the field don’t stop needing engineering when the project ends. Slow at the start, sturdy at the finish.
C so far, on ESP-IDF: the logger and the Bench rig firmware are both C, and the host tooling is Python. We have no C++ or Rust firmware on record, so if your target or codebase calls for either, the scoping sprint says what that means for the estimate rather than learning on your budget.
Yes, though we have no takeover on record yet. The approach: get it building reproducibly and under version control, then bring it under test before changing behaviour. You get an honest written assessment of what you have before we touch it.
Nothing we have built has been through certification yet, and the logger firmware has no lab test modes or RF duty-cycle handling. We work alongside your certification house and add what the lab needs. We are engineers, not a test lab, and we will say so where the boundary sits.
Yes. Send yours, or we can supply a mutual NDA to start from.
That is the arrangement we like best. We slot in beside your EE team from schematic review onwards. Firmware decisions and hardware decisions are cheaper when made in the same room.
We read every enquiry ourselves and reply within two working days. Quick chats, long briefs, half-formed ideas: all welcome.
Send a short note about the device, the target hardware if it's chosen, and where the project stands: napkin, prototype, or field failures. If an NDA needs to come first, say so and we'll start there.