choice of the most fit Raspberry version

The Pi Pico is the only one with a built-in ADC. But even it only has three inputs, so you'll either need to use analogue switch circuitry or an external ADC.

If you use an external ADC you could connect that to any Pi model. You might also consider mounting individual ADCs remotely at each sensor and communicating with them digitally, to avoid electrical noise picked up by the long wires messing up the readings.

The 300mA output current of the Pi Pico could drive many models of relay directly (with protection diodes). Equally other models could switch them via a transistor without much more complexity.

They've all got USB so that's easy.

You probably want one with HDMI output then, which rules out the Pico. Though perhaps you mean small displays which could be run from the GPIO.

Also rules out the Pico.

Overall I'd say that a Pi Zero W would do all you need, so long as you're willing to use an external ADC chip and buffer transistors for the relays. You'll need some external circuitry whatever you choose. Equally most other "big" Pi models suit, and more USB ports may avoid needing to use a hub if you choose to connect a keyboard.

Sounds very fancy. Note that I wouldn't trust the Pis to be super reliable, eg. compared to boards designed for industrial environments.

--
__          __ 
#_ < |\| |< _#

Den 2021-09-03 kl. 08:59, skrev Soviet_Mario:

I'd use a 3b+ because

• rpi display fit it well

• has wifi and ubs-ports (no need for a usb-hub that the zero would need)

• easily boots from SSD via usb. No worry about wearing down the SD card

i use a 120 Gb version of this since 3 years

The pi holds a postgres DB with quite some read/writes and also - lots of file logging

A Zero may have enough umpf for your needs, but connectivity is harder

"unlimited" number of sensors - how do you plan that? OnWire?

Some relays do not work with PI directly - some do. I've got some chinese realys both in singel and double configuration on a board. The singel ones do not work with a Pi - the double one do. Both work with an Arduino Nano - so - external circuit may be needed

You don't need more than a Pi zero W to make this useless idea even worse ;-)

--
?It is hard to imagine a more stupid decision or more dangerous way of  
making decisions than by putting those decisions in the hands of people  
who pay no price for being wrong.? 

Thomas Sowell

Although writing a usb mass storage + ext4 driver for the Pico might be a challenge.

I might possibly ask further clarifications for the parts above, but preliminarly ... could you explain why it is fancy ?

feel completely free to suggest any other platform which, with REASONABLE amount of expansion/integrations, would be able to comply with the points I have specified.

As for the fancy choice, I am a complete novice in IoT, and as a Debian user, I felt confident with raspbian and development SW tools

but I'm open to *ANY* other suggestions as well, of which I thank you in advance

>

--
1) Resistere, resistere, resistere. 
2) Se tutti pagano le tasse, le tasse le pagano tutti 
Soviet_Mario - (aka Gatto_Vizzato)

no, well, I wrote "unlimited" number of wires/cables, as I have drawn two independent 8x0,22 mm2 poles cables plus a

3x2,5 mm2 poles cable for power. So I was thinking wiring would never become a bottleneck whatever solution will be chosen.

The thermal sensors will roughly a dozen or slightly less (the critical issue will be the long distance of 3 of them from the "brain", 25 to 40 meters away).

I still have to study much of the terms, sorry :(

I'll have to choose suitable ones then, and at that time I'll be here again to ask :D

I'll have to strieve for long, but that was being expected :\

TY

--
1) Resistere, resistere, resistere. 
2) Se tutti pagano le tasse, le tasse le pagano tutti 
Soviet_Mario - (aka Gatto_Vizzato)

Il 03/09/21 11:46, Soviet_Mario ha scritto:

sorry, I made a mistake. This abundance of wiring was installed for just the 3 more distant PT100 detectors as I had to dig a trench and lay cables. The nearer ones would be managed as needed, so regardless of whatever else, the available wiring will not become a bottleneck

--
1) Resistere, resistere, resistere. 
2) Se tutti pagano le tasse, le tasse le pagano tutti 
Soviet_Mario - (aka Gatto_Vizzato)

I'm not familiar with this NG so I can't assume to be able to recognize trolling, but ... this seems that.

I am not asking if the general idea is good or not, just what would be a good central system choice to control all the devices.

Sb maybe deprecated the choice of the raspberry per se, and I hope to discover more about the point

--
1) Resistere, resistere, resistere. 
2) Se tutti pagano le tasse, le tasse le pagano tutti 
Soviet_Mario - (aka Gatto_Vizzato)

Programming? Suggest Raspberry Pi 3B+

--
Cheers, 
David 
Web: http://www.satsignal.eu

"Fancy" is just my response to "multi heat-source solar-biomass water warming system" when I actually haven't got the first clue what that means. In terms of electronics, the demands that you've specified seem modest enough.

The Pis are one range amongst many Single Board Computer (SBC) ranges. I'm not an expert on them, and I mainly look at lists on this site as a starting point:

Try looking for the word "industrial" on that page for the sort of board that might be a bit above the Pis in terms of reliability.

It'll generally be easier to develop software for the Pis than for some obscure industrial-spec SBC though.

--
__          __ 
#_ < |\| |< _#

Pi zero has a decent operating system and the WiFi has adequate hifi and usb support for disk, I/O is the weakness compared to Arduino.

But it does support I2C bus and many temp sensors do the same.

My point stands. Pi Zero W will do what you want, sadly the multi heat-source solar-biomass water warming system, with forced circulation probably will not.

Experience suggest it will save no money and will certainly not save the planet.

OTOH if you are selling such systems to gullible greentards, it will probably make a profit

--
There is nothing a fleet of dispatchable nuclear power plants cannot do  
that cannot be done worse and more expensively and with higher carbon  
emissions and more adverse environmental impact by adding intermittent  
renewable energy.

I'd think about splitting this up into two parts:

Part 1 does the temperature monitoring and any control loops. For example 'if too hot then open relay #4'

Part 2 does the display, logging, networking, etc. It just reads the status and sets parameters of Part 1.

The reason for splitting this up is it's safer if Part 2 crashes, your house doesn't melt by jamming the furnace on. Maybe you can't adjust your temperature up or down but at least it stays running.

Any Pi with wifi would be fine for Part 2. Part 1 would be a microcontroller of some kind - for example a Pi Pico, an Arduino, an ESP32 or whatever board you feel like. Pick something with a nice software dev enviornment and suitable I/Os.

A more involved design might have Part 1 cache recent recordings, so if Part

2 crashes it can re-fetch the last hour/day/week of recordings without a gap.

I would have a look at Home Assistant on the Pi and ESPHome on an ESP32 or ESP8266 microcontroller, as that probably does most of what you want already. You mostly just need to build the controls using JSON or a clicky GUI, it does most of the rest for you. HA and ESPHome are part of the same organisation so they are well integrated together. They may well have integrations with your existing kit (eg if it speaks Modbus or has a cloud interface).

HA is not the most lightweight thing ever so benefits from having a Pi 4, although the cheapest Pi 4 is fine.

Theo

oh ... I see. As it seemd unessential, I overlooked this. It is simple in brief. I have an insulated 5000 L "water buffer" There are coils in corrugated steel pipes (heat exchangers) that can input heat from two distinct source, in parallel to one another : a biomass kiln and solar panels.

The "brain" must check the various temperatures (the storage, and the sources), do some evaluations, and decide whether or not to activate the PUMP, and which, if any, valve to open, to put the selected source/s online, and recharge the buffer.

Then do some log (how many times the pump was activeted and for how long, the detected temperatures, the flowmeter data).

yes nothing amazing, nonetheless overwelming for a complete ignorant (like me) in electronics.

I'll have a look. I must ad I have long be considering ESP32, but the SW environment is unfamiliar to me, and I dunno if it can pilot any kind of display to make mainteinance

you got perfectly the point ! In Debian i feel at home, but I am completely unfamiliar with ESP32 or Arduino :\

>

--
1) Resistere, resistere, resistere. 
2) Se tutti pagano le tasse, le tasse le pagano tutti 
Soviet_Mario - (aka Gatto_Vizzato)

have you seen my calculations and solution ? the system will work as expected, more or less reliably.

this is uncertain, as I have just spent a lot for materials. But I have spared on manwork as I built it all alone. I have trees and collect wood for free, and the sun is also for free, so at a certain point I will cease to buy very costly LPG (upwards of 1'200 ?/y) and will only spend sth in mainteinance. All is very modular and most materials will last beyond my life expectancy.

The inox coils are protected by passive magnesium cathode and also by forced current titanium anode.

The most vulnerable part is the black rubber mat (a couple of pool heaters) which won't be exposed directly to UV though, as in the front stands a triple layer transparent alveolar polycarbonate. It might last 5 to 10 years, this is uncertain. The mats cost 350 ? both.

the buffer is thick polyethylene, the insulation rock wool.

the kiln is plain iron, but the exchangers are 6 mm thick and should almost survive myself.

I see

absolutely no, all hand made, for myself alone. I am seeking energetic autharchy

--
1) Resistere, resistere, resistere. 
2) Se tutti pagano le tasse, le tasse le pagano tutti 
Soviet_Mario - (aka Gatto_Vizzato)

I feel comfortable with C, C++ or Gambas, but I'll need to find libraries to manage I/O on the ports, that's sure.

--
1) Resistere, resistere, resistere. 
2) Se tutti pagano le tasse, le tasse le pagano tutti 
Soviet_Mario - (aka Gatto_Vizzato)

sensible considerations. The wood-system is passively safe, as it is not in pressure (an open air reservoire is present), there is a floating valve self-replenish of the tech. water in the source coils circuit, and a max.level discharge system. At worst the water will BOIL for a given time and vent vapour from above, and the floating valve would detect water loss and replenish from top with cold water. It will not be good anyway, sure : the calcite (CaCO3) would foul the coils, if the T soars often.

I had thought of ESP32. The thing is : I am ignorant how to communicate with Pi.

I'll do the search, but I haven't got very well the meaning. The two projects are independent ?

uh ! Fine !!!!

tnx a lot. Sure basing over an existing working project and making minor adjustment would be faster and safer for a niubbo like me !

--
1) Resistere, resistere, resistere. 
2) Se tutti pagano le tasse, le tasse le pagano tutti 
Soviet_Mario - (aka Gatto_Vizzato)

On Fri, 3 Sep 2021 08:59:03 +0200, Soviet_Mario declaimed the following:

None of the R-Pi models I'm familiar with have usable Analog inputs, so any temperature sensor that reports via voltage change will require an external ADC board cf:

For sensors that use I2C or SPI -- you will have to determine how many sensors you need to address. SPI will require a chip-select signal for each device (but sharing the data in/out, and clock lines -- 3 lines plus 1 line per device; you may have to bit-bang the chip select; most SPI ports only natively control 1 or 2 chip selects). I2C will depend upon how many unique addresses can be configured on the devices, as the one I2C port will be limited to sending that many addresses; if devices have to share addresses, you will need another I2C bus for the duplicate addresses.

You'll likely need a relay driver board. The R-Pi digital signals are

3.3V and low-current; hitting them with a 5V signal, or attempting to transfer too much current, will kill the R-Pi. You'll definitely want some isolation from the 220V side (I believe many of the relay boards are aimed at robotics, being driven from one to four 12V batteries -- 12-48V DC, so the relays may not be rated for 220V AC -- that may mean one set of "low voltage" relays are needed to drive the high voltage set.

Software and configuration... may want more than one USB port given the next...

Most R-Pi's have HDMI ports for standard (modern) monitors and HD TVs. Keyboard/mouse is probably best served using wireless models where one USB receiver works with both the keyboard and the mouse (Logitech "Unifying" receivers and peripherals are what I have experience with).

If you mean something like a 3-7 inch LCD display... Those may use a lot of the digital GPIO pins, reducing those available for the above control system. Not to mention getting access to the pins when a display board is fitted over top...

Every R-Pi that I know of has either or both Ethernet or WiFi (all current models have WiFi, the smaller ones may not have Ethernet ports).

Software...

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

On Fri, 3 Sep 2021 15:02:22 +0200, Soviet_Mario declaimed the following:

Take into account that the R-Pi does not have a battery-backed clock. Without a network connection allowing for time-synchronization, your logged time-stamps could be off; especially following a reboot (when the OS relies upon some value periodically written to a file).

You'll need to consider the difference between a "microcomputer" (aka: embedded Linux system) running a full OS, and a "microcontroller" which, at best, may be running FreeRTOS built into your application.

Most all microcontrollers probably have a support library that can drive an Hitachi compatible 2x16 character LCD. Few will support a full keyboard. Parallax used to have an add-on board for their Propeller Quick-Start board with PS-2 ports for keyboard and mouse. Most do not have USB HOST ports (though you can find SD card add-ons for logging storage -- but they will only be using FAT filesystem). They have USB client ports used to flash updates to the application.

"Maintenance" on a microcontroller typically consists of modifying/rebuilding the application on a desktop computer, then sending the (re-)built application to the flash memory of the controller via USB. Think of a "smart" home thermostat. At most you have a few buttons which permit making changes to parameters stored in EEPROM [some boards have EEPROM for parameter data as they don't allow write access to the flash].

Many also have on-board ADC (Arduino UNO and compatible has 6 ADC inputs, and up to 6 PWM outputs; TIVA C tm4c123g has two 12-bit ADC -- which appear to be MUXable among some 14 odd pins -- and way too many on-board timers [12, each which can be "split" into two half size timers]; Propeller... No ADC).

Note that there are two "classes" of microcontroller commonly available: the Uno and kin are Atmel AVR 8-bit processors; the (discontinued) Arduino Due, Adafruit Metro Express, TIVA, STM are variations of 32-bit ARM Cortex M-series processors [M0, M3, M4 and M4f {f = floating point hardware} most common]. The Propeller is a custom design

-- 8 lock-step cores sharing all GPIO, no interrupts (one is supposed to assign a core to running polling loops to detect pin changes for interrupts).

With microcontrollers you'll have to be concerned with on-board flash

-- though most applications should fit, as the application runs from the flash memory -- it isn't like an embedded Linux board where the flash memory is "disk", and the application(s) are loaded from "disk" to run in the RAM. Microcontroller RAM is only for run-time variable data (heap/stack).

TIVAs were cheap if one was in a country TI would ship to (the 123g model was around US$12 -- 80MHz Cortex M4f, 256kB flash, 32kB RAM; TM4C1294 was around $20 -- 120MHz M4f, 1MB flash, 256kB RAM, Ethernet [you need to include drivers in your application, so likely also need TI-RTOS]).

Arduino uses a form of C++ for the native language, though most users never see that level -- include a library, create an instance, and just use the object.

The Metro M4 Express native is CircuitPython, though one can load an Arduino compatible boot-loader and build Arduino style code. 120MHz M4f,

512kB flash, 192kB RAM, one ADC shared among 8 pins, one DAC shared among two pins, 16 PWM

TIVA has a port of the Arduino IDE called Energia for simpler coding, but for complex stuff (TI-RTOS) uses Code Composer Studio.

Propeller... again, all custom -- SPIN, Propeller assembly, even a C compiler environment is available (SPIN is a byte-code interpreted language; the applicable Propeller core [8 cores available] is loaded with the SPIN interpreter, and application code runs from the flash memory).

Everything else you've stated is what the microcontroller boards were optimized for. Low-power usage, no fragile file-system [power loss to a Linux board can result in a trashed boot file-system -- Amateur Radio Pi-Star systems actually run with the file system set to read-only, with all dynamic data being stored in a RAM-disk -- which is lost on power-fail], often have ADC and PWM on-board. Fast start-up since there is no OS to load -- processor basically boots with the application in flash. Your application probably doesn't need the fastest response times so slower processor clocks [which contribute to low power usage] is fine. You should even be able to fit a PID logic system into a microcontroller [maybe look for one running on M4f for the floating point math].

You'll still want a battery-backed RTC regardless of Linux or microcontroller board to time-stamp log entries, and probably an SD card slot on which to do the logging.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

I suggest the Pi because it is very well supported, with lots of libraries and help out there. Possibly some of the libraries are more focussed on Python, and I've used Perl and scripting too.

--
Cheers, 
David 
Web: http://www.satsignal.eu