1

I'm building a floor heating control with raspberry pis. Until now I have two Pis working, one which controls the valves via relays and another which works as "central" with a webinterface to adjust the roomtemperature and as the sensor for the livingroom. Now I want to split everything, that I have:

1 Pi to control the valves (existing) 1 Pi as a central to control all the rooms, with a temperature-curve for the last 1-3 days or something + the data of the (still to build) wheaterstation 3-4 Pis (each for one room) for the on-site measurement and manual adjustment (small LCDs)

So far there's no problem. At the moment, in this try-out state, I'm using UDP to transmit the actual value and setpoint from one Pi to the other (which switches accordingly the valve and creates a CSV log) via WiFi. But now I want to have a "sensor" for each room and e central with more and visual information. So I'm asking you, what is the easiest way to realize that. Via a central file on a NAS or a central file on the central Pi. Further I'd appriciate some solution ideas for this. Maybe someone has already done something similar? Thanks in advance!

Greetings Alex

Improve this question
1
  • I would think a central text/csv file is easy to start with. You might later setup a FTP server or NAS. There are many I2C temperature and humidity sensors to choose. Commented Sep 20, 2019 at 12:33

1 Answer 1

Reset to default
1

I did something similar and used this basic set-up:

  • Remotes controlling sensors send data to central. In my case I send JSON with the data over http.
  • Central stores data in a MySQL database when the message is received.
  • Central runs a webserver with a visual interface to retrieve the data for users.

I was only measuring whereas you want to provide control, but you could work that into the system either by having the remotes query central for instructions periodically or setting up some sort of service on the remotes that listens for instructions from central. (I suspect it easier to have the remotes query, but I feel sure you can make it work either way to match your design interests.)

I think that I would not use UDP, by the way. It's not "wrong" but it doesn't strike me as the right tool for the job. You probably want to ensure that packets aren't lost here and I don't think you're time-sensitive (at the level that UDP would matter) in this application.

As for data storage, you may want to put write to something other than the card on central due to wear and backup, but that shouldn't be critical to the initial design and test.

In my case some remotes were Raspberry Pi but some were other types of controllers. Segmenting it this way allows you to decouple details of the controller of the remote from the rest of the system. (Raspberry Pi sounds like overkill for your remotes.)

The hardest part of this, in my opinion, is the last bullet since you may have to write both front-end and back-end code for that. Open source will take you part of the way, but there are several technologies that need to mesh, so there may be a steep learning curve, especially if they are all new for you.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.