search

RaspdasTeam / raspdas

Raspberry Pi Data Acquisition System
MIT License
0 stars 0 forks source link

General System Conception #1

Open myma84 opened 8 years ago

myma84 commented 8 years ago

The purpose of the project is collecting various data such as temperature, humidity, gas concentration etc. from sensors. The data should be shared to user via web console.

The main part of the system would be Raspberry Pi with linux on board. The sensors should be designed using simple and cheap hardware parts.

My proposal of general system conception is as follows:

raspdas_concept

The central point is a database used as a sensor data storage. The data are provided by sensor data providers (SDP). According to type of sensor interface there are several SDPs. The data are read by web console (WC) and are presented to the user.

JakubRakus commented 8 years ago

Nice work. Overall conception is very good, but we have to think how much every type of SDP would be generic. API for DataBase should be identical for every SDP - this is obvious, but what about protocols used to communicate with sensors? For Net class Sensors there won't be a problem to create one common protocol encapsulated i.e. in TCP frames (with Sensor as active side, starting the transaction every constant period). Such protocol may be used for Serial class Sensors also. Unfortunately for 1wire (SPI, I2C or any other untypical interface) Sensors connected directly to Pi there's no way to use our protocol, SDP's for such nodes have to implement proprietary Sensor protocol and they (probably always?) be a master who starts the data exchange transaction.

myma84 commented 8 years ago

Protocols between sensors and SPD don't have to be the same. Important thing is a common sensor data model (CSDM). This is subject for another issue. Let's treat a sensor like a piece of hardware with some configuration not just like measuring element. We have to determine what kind of data will be assign with the sensor (identification data, description data, measurements etc). It would be nice the sensor would be self-describing. In some cases such information will be added directly in sensor hardware, in other cases (e.g 1w) extra information will be added in SPD.

JakubRakus commented 8 years ago

OK, I understand that protocols to communicate with sensors and way of data processing would be different for every class of SDP. But IMHO the rest (or maybe majority) of the SDP main features should follow some general rules - I can't give example rules at this early stage, but CSDM have to be one of these. Do You agree with that? And one more thing - what about adding some kind of manager? It would be responsible of start/stop SDPs, WC etc. and eventually restart them in case of some critical failure.

bez nazwy

myma84 commented 8 years ago

Good observation. The output of SDPs has to be unified. SDPs will be using common database with fixed structure. There are also other possibilities for example direct connection (websockets ?) between SPDs and WC. It will allow for passing current readings from sensors without overloading database.

I think, DasManager is worth considering. Such app would be responsible for checking whether other components work properly. In case of failure of any app, hardware watchdog wouldn't be refreshed by DasManager what would cause system restart. In case of DasManager failure there would be the same situation.