![openhab modbus rtu openhab modbus rtu](https://community-openhab-org.s3.dualstack.eu-central-1.amazonaws.com/original/3X/7/e/7e2356a0bfcdfa839225b68ffa706fd1a6f03752.png)
Yes, and there was no smell of wireless here, although it met the conditions of the task.Īnd then I finally became firmly convinced that it was necessary to make a controller accessible by air. If you want to add another controller to the general system, you will need another such shield from the modem. The decisive factor to put an end to this solution was that it was not scalable. My attempts to modify Modbus Binding to be able to synchronize Item polls with the same host-port-slaveID did not improve the situation. my modem shield was not designed for multiple simultaneous connections and the data was mixed. The problem, as it seemed to me, was the asynchronous TCP connector on the Modbus Binding side. But it was worth adding a few more - errors in transmission immediately appeared. During testing, I configured only 1 Item and polled it successfully. It would seem, what else is needed? But the problem lay in the number of Items in the configuration. The differences turned out to be quite small, and now the controller is already working in the OpenHAB- (ethernet) -modem- (UART) -controller bundle.
![openhab modbus rtu openhab modbus rtu](https://community-openhab-org.s3.dualstack.eu-central-1.amazonaws.com/original/3X/c/8/c85dc46f652b134ae882892fae51e79570d1aeee.png)
At that time, this did not stop me - it was decided to finish the ModbusRtu library for arduino in order to change the packet format to TCP. But, unfortunately, Modbus Binding is not able to "RTU over TCP". You need to set up a connection in OpenHAB. Joy knew no bounds - polling the controller in such a bundle at the local modem address 192.168.1.110 on port 3000 worked successfully! Fortunately, the modpoll program mentioned in Arduino & Modbus supported this. This solution made it possible to achieve the intended task - the shield and the controller were located on the desktop, without using a work computer, at the same time the shield is always connected to the local network and is accessible from the home server.įor such a bundle, ModbusRtu over TCP support was required for the control program. This prompted me to start implementing old ideas.Īfter playing with the examples from the articles, I decided to try to spread the controller and the server using the above ethernet-shield from the modem. But most importantly, I discovered OpenHAB - what I have been looking for for a long time. Thanks to them, I got acquainted with the Modbus protocol.
#Openhab modbus rtu how to#
#Openhab modbus rtu series#
And he would have been lying further somewhere in the closet idle, if one day I had not come across a series of articles: On that list was the NRF24L01 + module, bought by a handful for experimentation. And everything is managed in OpenHAB.ĭuring these two years, I managed to order a lot of all sorts of nishtyaks from China and most of them were waiting in the wings. The final solution uses Modbus protocol and RF24Network wireless network. Thus, on the home server, I could send an on/off command to the port to the local address of the modem, which will be sent to the arduinka connected to it.īut this article is not about that. Looking ahead and skipping the interesting process of creating custom firmware, I still managed to get the modem to listen on the right port and "forward" the UART through it. The desire to give a second life to the piece of hardware prompted googling, which, in turn, miraculously led to the article Turning an ADSL Modem into an Ethernet Shield for Arduino/CraftDuino. But remembering that somewhere in the store lies the D-link DSL-2500U dsl-modem, which has not been used for a long time, with just one port on board. The maximum is a socket with a LAN all at the same working computer - since it stands almost opposite the air conditioner.
![openhab modbus rtu openhab modbus rtu](https://community-openhab-org.s3.dualstack.eu-central-1.amazonaws.com/optimized/3X/0/c/0c6a7473db755af45c64be0c444c1adf81527d0e_2_690x388.png)
There was no line of sight from the server to the culprit of all the puzzles. Because there was little practical sense from the arduinki connected to the work computer, the head was constantly looking for an opportunity to connect the latter to the home server. She received commands via UART and knew how to turn on and off the air conditioner. That is, the control of the controller must be wireless. The main condition was the absence of any wires to the air conditioner. During this time, the idea to control the air conditioner remotely did not leave me and had several rebirths. After my first article about controlling the air conditioner using a controller, a little over 2 years have passed.