On the CMI you configure the related inputs connecting to your Raspberry Pi Modbus server: Configuration of Modbus inputs at the CMI. Using log.debug lets you follow the details of the communication on the server – and helps with sorting out any byte ordering issues -) The ‘context’ is a global object, and one thread constantly updates the values in an infinite loop, and the other thread is for running the actual TCP server. In order to change the values while the Modbus server runs without interruption, Python threading comes in handy. Another option would be to create a client connecting to your own local server and writing to the registers.
RASPBERRY PI MODBUS SERVER UPDATE
I update the values ‘internally’ using the setvalues method of the context, like this. That infamous usage of weather forecast data from some public API for optimizing battery storage could theoretically be one application for that. These values are then ‘sent out’ via your Modbus server interface. The payload builder can be fed values retrieved from another logger, or created by whatever complex calculation. Here is an example using the payload builder to create a ‘stack’ of registers containing payloads of different types. You write values to your own registers by building a payload from values in different formats. There is a great python library called pymodbus which makes this task easy: Top right: Raspberry Pi 3 B – with a USB stick for logging (This extends the life time of the SD card a lot -)), second ‘row’ UVR16x2, third row: UVR1611 – most of its former functions have been migrated to UVR16x2. The main units of our control infrastructure – after the Chief Engineer’s heroic rebuild of the technical room last year. Starting my own Modbus server at the Raspberry Pi we already use for logging from the heat pump’s CAN bus. and provides these data to UVR16x2 in a proper format as an input relevant for control.Īs I had already tested logging from Modbus sources, the logical solution was:.processes these data and calculates derived values, without having to ‘waste’ UVR16x2’s building blocks for functions on that.collects data from other sources which UVR cannot directly process.I was looking for … a babel fish! A universal protocol translator that … So far I could not, say, calculate the photovoltaic power used directly at each instant.
RASPBERRY PI MODBUS SERVER SERIES
As I am mainly interested in daily consumption or performance data, the Data Kraken creates a series of nested views, finally spitting out one row per day, and those views for different loggers can be joined again. Of course you can simply overlay the data without the time stamps being exactly equal.
Separate log files provide for built-in backup – but what if I could send these data to the UVR16x2 in real time in addition?Ĭurrently different loggers log data at different points of time, so you cannot simply join all these tables together. My Data Kraken is a SQL Server that is fed log files from different data loggers – the largest one from the CMI, and others are from our smart power meter’s logger, from our photovoltaic inverter, and from the heat pump’s internal CAN bus. But while the CMI is a web server with visualization a JSON API, it cannot log ‘from’ JSON. However, our smart meter has ‘only’ a JSON interface – and you can always scrape data from the website as last resort. As the CMI supports Modbus inputs and our Fronius Symo inverter has a Modbus interface, PV ‘generation’ data can be logged via Modbus. If you want to optimize the usage of photovoltaic energy, the controller should know about the PV ‘production’ and current consumption. An operating system for control should do just that – I don’t want a web server and TCP/IP on the controller itself.īut sometimes it might be useful to send the controller a non-critical ‘nice-to-have’ signal. This ‘architecture’ might be due to historical reasons, but I like the separation of critical control functions and nice-to-have logging. There are two pieces of hardware you need for logging – the actual control unit and the logger connected to the controller via the CAN bus. Our main data logger is the Control and Monitoring Interface of the freely programmable controller UVR16x2.
0 kommentar(er)
