The Industrial Raspberry Pi Forum

Hi,
I have been using 1-wire and dht sensors to control my home heating system, currently I am using a DHT22 and a Maxim DS18B20 temperature sensor as prototypes.
They both hold the features I need:
- digital devices with no need for cable-length tuning (1-wire or dht protocols)
- long distance measurements and reliability (up to 50m with ethernet cable cat5)
- support for multiple devices along the same cable
- inexpensive
- compact
- easy to try out by using Arduino libraries and 5V

Maxim DS18B20 adoption seems widespread along with the related 1-wire protocol.
I have bought a RevPi and I congratulate on the project and its open source attitude, really appreciated, I would like to plug in the temperature measurement somehow, here are the ideas that have popped up to my mind, could you please give some advice, taking into account that these sensors should work stable for years and I am willing to wait for the new Jessie feature or future modules if they provide ease of use and stability, here my ideas:

1) Buy and off-the-shelf 1-wire controller and use ethernet to read the sensor data via software, like:
https://www.eservice-online.de/shop/1-w ... nittstelle

2) Use an approach similar to the Hannover example, so the Jessie image using modbus-rtu with a USB-rs485 adapter -please correct me if I am wrong-, as described here:
https://revolution.kunbus.de/blog/revol ... es-modbus/
https://revolution.kunbus.de/tutorials/ ... verwenden/

Would you be so kind to provide the details of the modbus sensor you used and possibly the RAP file configuration?

3) Understand how the RevPi protocol works and create a new custom module (Arduino for instance rs485 slave device) to be queried by the process image, the RAP file could be created as described here:
https://revolution.kunbus.de/tutorial-r ... erstellen/
The new module could be used as a bypass to the 1-wire etc. world.
My understanding is that all the DI, DIO, future AI modules are programmed internally to exchange data via RS485 and your custom protocol, since no updates are provided for the modules I gather this protocol is stable, correct me if I am wrong.

4) Wait for the new Kombi-module to come and use the free side of the PiBridge to plug in and ethernet/rs485 slave device bypassing the piControl module.

5) Any other approach I have not mentioned and might be more sensible

Could you please recommend any of the following solutions with particular focus on flexibility and future stability?

Thanks indeed

Enrico

Hi Enrico,
as your use case is not the first in our forum wishing to have 1-wire for smart home applications including sensors I appreciate very much your systematic style of analyzing this problem. Because this is an important topic give me some more time of carefully studying the possibilities before answering to your points in detail. There are some misunderstandings in your points but also some very interesting suggestions. I'll be back and comment all points later today or tomorrow...

okay, here we are again... sorry for he delay...
I'll comment your suggestions:
1) Probably the most professional and easy way to connect 1-wire sensors. if you would like to reduce the costs you could also use the "1-Wire Buskoppler USB Pro" which is just 60 Euros.
2) i would not go for RTU but TCP instead as you could use PoL in order to save the power line to the sensors and also because you said you would use CAT5 cabling for reliable 1-Wireconnections. Here is a link which might be interesting for you: http://inveo.com.pl/nano-temp-en/. But the costs per sensor might bring you back to suggestion 1)
3) Yes you could create you own 1-wire custom module for the PiBridge. But with all the parts needed it would never be cheaper than a TCP to 1-wire bus coupler. btw: with Jessie we have finally introduced an extension module updater software. Using this software you can e.g. update the DIO firmware. We are continuously developing new ideas and extensions to the actual protocol in order to get more functions and other enhancements.
4) The Revpi communication will not help much because it does not offer 1-wire connectivity. maybe it would make things easier for you to connect modbus RTU temperature /
humidity sensors which are available for under 15 Euros.
5) Do not underestimate a wireless approach. Nowadays you get BTLE or WIFI IoT nodes for small money. E.g. have a look on TI's Dev Kits or this page: http://projects.privateeyepi.com/WIFI-Sensor

Hope this helps for your plans,
Volker.

Hi Volker,

thank you for your reply, it was helpful.
For 1-wire a controller is the easiest option probably, the esera USB version is more geared towards Windows than Linux/Arm, the ethernet version needs some understanding of their protocol.

Technically speaking I do not necessarily need 1-wire sensors, any good modbus sensor might be an option too.
The nicest thing I think would be to stick with the PiBridge and PiControl with no ethernet data to plug in via software, switches, routers etc.
I have a couple more questions if you don't mind:

3) custom module over the PiBridge, would it be technically possible to enclose a home-made prototype (say an Arduino e.g.) in a RevPi Maker-Set and make it communicate with PiCore?
This module could in turn work as a "gateway" between the RevPI protocol and another protocol, 1-wire being an option.
Some points related to this:
- do you have any specs of the protocol you are using over RS485 or any plan to open-source and document it? Could it be inferred by the uploaded code?
- out of curiosity if this can be disclosed, how is a DI/DIO module logically set up for instance (chip, internal bootloader to update the firmware via the PiBridge etc.)? Could a similar custom module mimic its functionality?

4) The RevPi communication, would do the trick but at software level, so by means of standard interfaces, plain rs485 (not RevPi), tcp with possibly modbus on top.
- So the "standard" side of the RevPi does not belong to the PiControl kernel protocol, is this correct?
- Would you recommend any temperature/humidity sensors in particular in case a RevPi communication is used? For now a USB to RS485 converter would save some software rewrite.

Cheers

Enrico

Hi Enrico,
I love people who know what they are talking about - and you are one of them
It's not that I like to thwart your enthusiasm to build a custom module. But if your reason to do so is only to get a reliable cyclical RS485 connection between an arduino and the process image this would be a little exaggerated.
You can find the PiControl code (which is the RevPi side of th ePiBridge) on Github and reading it you may be convinced that it is pretty sophisticated. In June/July we will also publish the DIO source code (this delay is due to the fact that we are right in the middle of updating/upgrading the firmware) so you can see that communication over the PiBridge is not just a cyclical telegram on RS485 but a complex state machine which needs to have knowledge about the modules attached to both sides of the module the state machine runs on. This is because there is a complex initiation of the PiBridge whenever it is reset. During this Initiation which involves multiple timeouts and switching of the "sniff-pins" the physical setup of the modular system is detected.
Here is a picture out of the old documentation which is pretty close to the new firmware we will publish in June/July: And yes, you could take the DIo code (written for STM processor) and try to integrate it into an arduino. But Why should you? It is so much easier to connect an arduino to the revPi and set up a cyclical communication for data exchange with the central process image:
Just use our new virtual device Modbus RTU master. Use an arduino and connect its USB port to the Revpi USB port. You get a ttyusb? device on the RevPi which can be used for the Modbus RTU communication channel. On the arduino side take a public domain Modbus slave software and you are ready! All you need is some DIN rail case and you are dons because the arduino is powered by the USB...
we have implemented such a connection for our "Snack machine" on the KUNBUS booth which was hardware controlled by several arduinos all connected to a raspi which worked as master control device and provided the GUI as well as the internet connectivity.
With your application you could easily use a little arduino sketch to cyclically read the 1-wire sensors and write the values into Modbus registers (=array in RAM of arduino). The modbus slave functionality of the arduino will serve and deliver these values whenever the Revpi requests them. Using our Modbus RTU master you simply set up the cyclical requests as tasks in the extended data configuration of a virtual modbus module under PiCtory. The result will be sensor values cyclically written to the central process imagy from where any software can access them using their symbolic names or cryptic offsets.

Hope this makes sense to you

Hi Volker,

thanks for the quick answer, your suggestion I use the new Jessie virtual modbus device for Arduino/the like does make sense, btw I quickly went through the new Jessie features and the blog posts about Modbus bindings:
https://revolution.kunbus.de/blog/revol ... #more-2574
and found a hint at a modbus driven temperature sensor too, I think I should follow the doc here for that:
https://revolution.kunbus.de/tutorial-modbusrtu-master/

Since I haven't tried it out, I need to familiarize myself with these settings first.
As for Arduino if I have not misunderstood the explanation you wanted to point me at a Modbus "ASCII" solution without the need for a usb to RS485 converter.

Nice the idea to expose the polled data of the modules through the process image -if I am not wrong-.
The diagrams give a feeling of the subtleties, I imagine this is not simple and do not delve into deeper topics, they would probably take up all of your time...
If you manage to expand on the big picture and architecture of the system when you publish the DIO code it would be great; if in the future there could be kind of a C/C++ library hiding the handshaking complexity of a slave module even better.

The inner workings of your protocol are interesting indeed, looking forward to the DIO code then.

Thanks again, good job!

Enrico

Hi Volker,

since your last reply I have been considering various options with regard to sensor inputs (1-wire and in general, mainly temperature).
I would like to try and build a prototype using an Arduino and some 1-Wire sensors over a direct USB (modbus slave) connection with the RevPi.

- Any chance you can share the code you used for your "Snack machine" built with Arduino modbus slaves?

After this prototype I would like to put in place a more professional solution using 1-wire by Esera eg., they have 2 types of gateways or internet controllers:
- modbus-tcp
https://www.eservice-online.de/shop/1-w ... modbus-tcp

- modbus-rtu
https://www.eservice-online.de/shop/1-w ... modbus-rtu

- ethernet controller, which should be queried directly by program and not via the RevPi
https://www.eservice-online.de/shop/1-w ... nittstelle

Could you please confirm the first 2 modbus gateways are supported by the new Jessie image? The first requires a permanent network connection, the second requires a usb-to-rs485 converter. The third requires ethernet connection and software logic.
Since this is going to be used in a house and must be reliable, from experience with modbus/ethernet relibability with the RevPi would you go for one in particular?

Last but not least: would you consider a modbus-rtu-only solution with a line of sensor slaves connected to the RevPi over RS485 (I need 10 slaves then), would you recommend any modbus-ready temperature sensor in particular in this case?

Thank you

Enrico

Hi Enrico,
there is code snippet online at support-> download which is Juan pablo Zometa's Arduino sketch for modbus slave functionality https://revolution.kunbus.de/download/1266/ ...
As for the Modbus Gateways to 1-wire, yes they will work and someone from our community has already used these gateways. You should consider using direct modbus sensors instead because they will be much more reliable than 1-wire. 1-wirehad not been developed for such long sensor busses and even if a company like esera has put lots of knowledge in to make it reliable you will be nailed to a single manufacturer to get the reliable stuff and there are not many sensors out there on the market compared to Modbus. You can only safe money going the 1-wire way if the number of sensors is so high that savings for sensors will win over costs for the gateway.
here is a nice product for Modbus TCP:
https://www.amazon.de/NANO-TEMP-PLUS-ex ... B01C8O6YX2
it even seems to use a 1-wire sensor but the cable is limited to a reliable length of about 1m.

Hi Volker,

thanks for your reply, I had a look at the Inveo nano temp but I need 10 temperature sensors and it would turn out pricey, I have been using Arduino and 1-wire sensors for years (20m cable length CAT5) and they don't have an issue in a standard house.
Also Inveo is using a Wire sensor too with a "gateway" providing the modbus translation, which is the same approach as Esera, just less scalable since they support a single sensor, but I would be bound to Inveo proprietary modbus specs anyway. Having a unique gateway per sensor is overkill for 1-wire too. It would be the same and cheaper to use Esera with shorter cable lengths then; sensors and approach are the same.

I was thinking about something like this: http://www.audon.co.uk/rs485sensors/tqs3i.html
as an alternative to 1-wire, by setting up several modbus slaves in the RevPi, without a gateway of its own. But rs485 uses a linear topology for the bus which is not very practical for house wiring, an "rs485 hub" (an Arduino for instance) would be needed.

I have not found a reliable rs485-based sensor which has a decent cost and a gateway/hub supporting a star topology providing a modbus interface. Nor have I found a modbus-tcp/POE product at a decent price, in any case I would need a 10-port POE additional switch to support this infrastructure.

All in all it seems to me that the 1-wire star-topology from the gateway onwards is the most practical and cheapest reliable option up till now.

Cheers

Enrico

I think your're right when it comes to prices. If you have made positive experiences with the 1-wire star and 20 m cable length this will possibly be the best solution for you.
so have a try with the modbus gateway as this will be the most reliable way to get 1-wire connected. you could also take the TCP/IP gateway and use your own python sw to send commands. I need to emphasize that this way is most preferable if you are going to have bi-directional event based data transfer as our modbus master is strictly developed for cyclical communication of repeating the same modbus commands all the time (i.e. it is difficult to realize modbus master bus command reaction to a slave event like a reset of a flag's slave etc.). But using just the temp sensors will normally not need any event handling but just cyclical requesting the temp with the same modus to 1-wire command every period. it could be that the gateway will offer some event based modbus possibbilities (e.g. alarming when a certain threshold has passed) which would need event based reaction of the master 8e.g. resetting the alarm flag). Such things are hard to realize with our modbus master sw.
Hope this makes sense,
Volker.