I’m a technical kinda guy, doing technical kinda stuff.
Would be fine. Maybe a few decoupling/buffering capacitors at the sink end just to help things along, depends if your device has its own supply regulator and etc onboard. A high and low value pair in parallel would be good (eg 100uF electrolytic and 100nF ceramic).
The cable between the two boards would be a maximum of 50cm. 3 of the signals are addresses for a multiplexer that would change at a maximum speed of 2ms per change. One of the other signals is a 20khz pwm signal. The final signal is a zc detector for mains so max Freq of 100/120hz.
None of this will be a problem over 50cm of cat5. If you were talking about millivolt or MHz signalling then you’d have to be a bit more careful.
Regarding wifi and power draw, you could always do batch uploading of data to another server at something like a 1:10 ratio, or upload only when there’s a change of more than 1 degree or similar.
There are some low power deep sleep esp32 boards out there that can do like 3-6 months on a couple of AA batteries. A lot of power draw comes from hanging around on wifi doing dhcp, so having fixed addresses can cut down power usage considerably.
Even without using the wifi side of things the esp32 boards come with lots of IO , plenty of drivers for various devices, and a reasonable in-house (i.e. not Arduino) development environment so I’d be leaning in that direction.
You could also look at Sharp’s memory LCD as opposed to normal LCD, as that’s extremely low power without the fiddlyness of e-ink screens.
If you’re just simulating the temperature there’s pretty much just three options:
Personally, I’d go with, “error faulty sensor” as the most likely outcome.
(Edit: you can stimulate the temperature by setting your house on fire. Better to just simulate it)
There is an empirical way of doing it - best one I’ve seen online so far is this:
Horn switches switch to ground. Power for your original horn relay is supplied from a fused battery source, passes through the horn relay, and when you press the horn button the button completes the circuit to earth, triggering the relay.
So, you need to wire your relay coil like this -
12 volts from a fused battery source to:
Your relay coil, to:
The horn switch, which then switches to:
Ground.
Just like how your current horn relay works.
This also works for older cars that do not have the really. They supply power to the horn, and then a single wire runs from the horn back to the horn button, which then completes the circuit to ground when pressed.
Could be. The way the voltage sags at the end of the cable with the blueretro connected suggests that someone skimped on copper in the wires.
If you can figure out a way to measure the voltage at the port with the cable attached and powering the blueretro, do that. If it is mostly the same whether the blueretro is connected or not, yep, it’s the cable.
It was probably a marginal product deliberately overdriven beyond “good design norms” to make it look good for the currently-missing data sheet.
Put it on a variable voltage power supply, run it at 6v to 12v in one volt steps, and measure its output volume for ten seconds at each step.
You might find that you still have adequate flow for your situation at a lower, cooler, voltage.
Hmm I’m not sure of the pin drive currents on the Pico, but can you power the sensors off a pin? At least then you can programmatically power cycle them if you need to.
The Pico also has a watchdog, you could set it up to give it a reboot if things don’t respond in time. It doesn’t solve the issues of course but at least it gets it back to a workable state. And if the watchdog fails, or it works but there’s still no USB serial, then that would point towards power instabilities or somesuch.
Perhaps slightly adjust your logic a little and see what it does.
Read from the sensors first, then enable and connect to wifi, send the data, then disconnect. That would reduce the maximum power draw as only one function is active at once.
Small edit: I have a MagTag ESP32 board with circuitpython that can’t read onewire devices while the wifi is active. Whether that’s because of supply instabilities when wifi is transmitting, or interrupt conflicts, or just plain poor programming in the onewire drivers or the wifi drivers, I don’t know. But reading the devices first and then connecting to wifi and sending the data afterwards works.
My only guidance is: Do not assume the wire colours have any significance. Work your way through all the combinations, regardless if they are “logical” or not.