Instable communication via RS-485
Roman Dorogan'
I'm testing a simple network: Arduino Mega as a gateway, Arduino Uno and Arduino Pro Mini as nodes, connected via RS-485 using MAX485-TTL modules.
When a button is pressed on one of the nodes, this node publishes a topic named "button1". Gateway is subscribed to this topic. After recieving this topic "button1",
gateway forms a data package, which is transferred to all other nodes in the network via "publishdata" function, like publishdata(GlobalTopic, DataPackage, 20).
The size of this data package is more than standard 9 byte allowed, I increased it up to 20 bytes using the method you described here https://groups.google.com/forum/#!topic/souliss/jpmS5pNwYmI
All nodes are subscribed to this GlobalTopic, so all of them recieve and then parse this data package. Data package contains some actions, which nodes should run, and delays between them.
For example, node#1 should toggle the lamp status in node1 slot1 in 100 ms after recieving data package, and node#2 should toggle the lamp status in node2 slot2 in 400 ms after recieving data package.
The idea is that nodes do some actions and report their slot statuses to gateway in turn, avoiding any collisions. But it doesn't work perfectly :)). Sometimes node#1 doesn't toggle the lamp, sometimes node#2.
It occurs randomly, approximately in 10-15% of all cases, without any dependence on which node is the first to run a command. Besides, I compare the status of the lamp on the nodes and in Souliss App,
and sometimes the lamp toggles correctly, but in Souliss App the lamp status doesn't change. Is it possible to improve this situation, or it is normal for Souliss via RS-485?
Thank you in advance!
Di Maio, Dario
Hi Roman,
as rule of thumb you have never to exceed 1 frame/s, this give you good chance to avoid to loose data. Anyhow the RS485 isn't a peer-to-peer datalink and so there is a collision avoidance done in software.
If too many frames are on the network the CA may cut-out them and you will loose that data, at same time it may be that some nodes gets dirty data and so are not able to process the action. In Souliss there is no ACK and retransmit at protocol side.
To get it working you should use openHAB as the binding allow you to create sequences and cross check the state to retransmit in case of failure.
If you want to do it distributed over nodes you should publish topic without data, each topic shall give a single action (like close the window shutters) and you should send it multiple times to be sure.
You can also use LastIn to capture nodes state and verify that all has executed that action.
More, RS485 has a 24 byte maximum frame size, so for sure you are not transferring all of your data.
Dario.
From Mobile.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
To post to this group, send email to sou...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/souliss/ec465d43-c766-4954-91c8-8ee2f3c37c30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Damiano Verzulli
Anyhow the RS485 isn't a peer-to-peer datalink and so there is a collision avoidance done in software.If too many frames are on the network the CA may cut-out them and you will loose that data, at same time it may be that some nodes gets dirty data and so are not able to process the action. In Souliss there is no ACK and retransmit at protocol side.
Dario, if you have some time, can you briefly explain how the RS485 communication is implemented in Souliss?[...]
Di Maio, Dario
Hi Damiano,
isn't related and use an easier collision avoidance based on previous transmission.
I've never heard about but use a token pass in Souliss would increase the performances.
Dario.
From Mobile.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
To post to this group, send email to sou...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/souliss/CAPeQo8ATusPu-3nkNNL7g%2BR4MYRHYF5UB495KqgOCKqYH6tGtg%40mail.gmail.com.
Damiano Verzulli
[...]
use a token pass in Souliss would increase the performances.
am I right in assuming that the main changes to SOULISS code should be applied inside the "vNetDriver_usart.cpp" file, with specific reference to vNet_Send_M5() function (and related ones)?
Anyway, this will not happen soon.
-----
[...]
I've never heard about [...token pass...]
Di Maio, Dario
Hi Damiano,
I'm not young enough to don't know about token ring :)
I wasn't aware of that library.
Back to your question, is enough to change the driver to insert that library in Souliss, but anyhow there are several people using RS485 with Souliss and I've never heard of big problems.
Actually there are houses with tens of nodes in RS485, most has short and multiple buses connected via Ethernet/WiFi.
As rule of thumb keep the number of rs485 nodes on a bus lower than 10 and the distance within 10-15 meters and things should be fine.
Keep in mind that the RS485 is quite slow compared to other media and we run at 11k92 bps.
I will ask Gabriele to share its experience.
Dario.
From Mobile.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
To post to this group, send email to sou...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/souliss/CAPeQo8BK1D5bAVE9_Bj7%2BiOKXuJSQxGvovzMJxCfDrfaL8DCmA%40mail.gmail.com.
Gabriele Ribichini
my network is ethernet centric but to reduce cost the line starts with one ethernet connected board followed by all the others RS485 boards (up to 4).
SApp sometime is not refeshing or sending the message. This has nothing to do with RS485 and it happens with Eth nodes also.
I have no idea why but is much more frequent whith poor wifi signal.
On the other hand I have a highly distributed network but unfortunately I don't use publish/subscribe at the moment.
All my code is based on RemoteInput and SendData..
Tipically my leaf nodes have no logics.. Just standard T12 for example. And I keep these ON by periodically sending AutoCmd + N via RemoteInput or activating them via OpenHab rules.
Honestly this architecture works very reliable since almost two years.
I use it for several lights, HVAC system, irrigation system and night lights in the garden.
Let me know if you need additional help.
Roman Dorogan'
Main idea of my souliss-based home automation system is to provide a possibility to change logic without flashing Arduino-based ending nodes.
It is important due to the fact that some of the nodes will be located in not easily accessible places, such as ceiling lamps or their wall switches. Besides,
there is a possibility that sometimes it will be necessary to change some system parameters being far from home.
Nevertheless, a variant of using OpenHAB server as a central _logic_ of the system is not appliable. My strong opinion is that a home automation system
should keep work condition even if central server is down for some reasons. So, logic distributed over the network segments is the best solution here.
Even if OpenHAB server or one of network segment is down, others keep working with full or limited functionality.
My current vision of network structure is the following:
- Arduino 328P boards as an ending nodes, connected to network segment controller via RS-485
- ESP8266 as a network segment controllers, connected between themselves and to OpenHAB server via Ethernet or Wi-Fi
- OpenHAB running on Raspberry Pi for scenarios execution and smartphone application
Logic in the system is build in the following way:
- each ending node publishes some topics, when some events on this node happen (button pressed etc.)
- network segment controller is subscribed to that topics. When it recieves one of them, it applies some logic, which is described in network controller itself.
Aftewards, network segment controller forms a 20 byte data package and sends it via "publishdata" function. This data package contains actions, which should be done
on ending nodes. Nodes are subscribed to this data package and when they recieve it, they run logic described in the data package with some individual delays, which are also
described in the data package. For example, node#1 should toggle the lamp status in node1 slot1 in 100 ms after recieving data package, and node#2 should toggle the
lamp status in node2 slot2 in 400 ms after recieving data package. The sense of forming a data package instead of using a bunch of "send" commands is in the fact we can
make multiple nodes to recieve some correct data much faster, because the delay between two "send" commands in order to make them both work correctly should be really big.
In the case of, for example, 8 slots on 5 different nodes to be changed, the difference is significant. Though, I didn't test the use of "remote i/o" function, maybe it can give some
speed improvement.
- network segment controller's (ESP8266) sketch contains a simple web interface that allows to upload new *.bin file and flash it from the webpage. This gives a possibility to do it
remotely, not being at home.
- the system of remote hardware resetting network segment controllers and ending nodes when they are hang up is also provided.
So, at the end of this we should get a system, which whole logic can be changed without using a single USB cable, though it is still much more reliable then central server-based systems.
Now I'm developing the system of providing the execution of the all the commands in the data package. For example, node#1 and node#2 perfomed correctly and node#3, node#4,
and node #5 did not. Network controller repeats the data package for them. Node#3 and node#4 perfomed correctly, node#5 - didn't. Network controller repeats the data package
for node#5, and at last it perfoms correctly. Of course, there are a lot of issues, but I think most of them can be solved.
The most important question now is how to improve the stability of RS-485 transmissions in order to get 3-5% of incorrectly processing data packages instead of current 10-15%.
To reach this I'm studying the data which nodes recieve (souliss USART debug, souliss vNet debug and added by myself all recieving via USART buffer bytes debug). I'll be really
thankful for all ideas that can help :)).
Thank you in advance!
Di Maio, Dario
Let me suggest you to use a semi-centralized network, with esp8266 as Wifi to rs485 bridges and as logic solvers.
You set all esp8266 as gateway and using lastin/persistance you can manipulate all the other nodes and monitor the result.
Your idea is feasible but isn't easier to be applied.
Dario.
From Mobile.
--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
To post to this group, send email to sou...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/souliss/03954f88-123b-44c3-8f39-8603af6e346f%40googlegroups.com.