@kimot
I am absolutely agree about the number of SOH bytes.
Currently in my github code I am using:
//The number of SOH to start a message
//some device like Raspberry was missing the first SOH
//Increase or decrease the number to your needs
#define ICSC_SOH_START_COUNT 3
We need to ask someone to make minor changes to the MyTransportRS485.cpp or submit PR to the MyTransportRS485.cpp.
@pjr
Yes the AVOIDANCE part is implemented, however it's not perfect yet.
We still have collisions during the first start packet byte.
I really hope to find some time to make necessary patches.
@pjr said:
So we need collision AVOIDANCE and DETECTION for (almost?)perfect solution?
AVOIDANCE:
- line checking ( digitalRead(rxPin) ) what @LeoDesigner suggested
DETECTION:
- "listening what I just said"?
- checksum at receiving end?
- perhaps similar "hw ACK reply" as the radio is using?
With most important nodes I could additionally use controllers ACK functionality.
I hope we will finally will come to the right most perfect solution.
Let me say first: I am not saying that we should use only raw RS485. CAN bus is very good idea too. It's good to have alternatives. We can get some ideas from CAN protocol also. I like challenges, and right now it's like a getting something good out from dirt cheap staff.
So, how about this procedure:
Before packet will be sent:
Collision DETECTION could be reliable done only via CHECKSUM ACK (small confirmation packet once we are received the input packet).
I think it's should be really rare case when two nodes will start transmission at the same time in case if we will make this random wait interval. Actually IMHO, Ethernet protocol using something like this (randomness before start).
One more idea regarding cheap collision detection on the bus.
We can almost eliminate collisions on the bus (should be almost no lost packets at all).
Before packet transmission we need to check the bus state during one first byte time using digitalRead(rxPin). In this case collision may occur very rarely, because time between bus checking and actual first byte sending is very short.
Also the code modification will be very small in current library.
I know about mysensors ACK protocol feature, I was talking about small ACK packet with checksum as a confirmation of the received packet.
So basically the easiest way to improve current situation is to add ACK/CONFIRMATION packets to the existing library. Unfortunately I am really busy right now with main projects.
@kimot
I have the same concerns regarding long RS485 lines. Also SoftwareSerial cannot send and receive at the same time (not sure about AltSoftSerial).
We would like to make the solution as cheap as we can.
How about sending the message and get ACK back from node/gateway ? (Resend if ACK not received) It is like immediate confirmation of received packet from the other side ? I think it's could be reliable solution. CAN bus is a good solution, but one of the reasons why many people choosing mysensors library is a simplicity and cheapness.
Another way is too look to the modbus - but it's not multimaster bus solution.
@AWI
The pseudocode looks correct, with one minor addition.
We may have corrupted incoming bytes received (or in our case just dropped) by the USART. So some kind of incoming byte waiting timeout should be implemented.
Please take a look here, to the bus arbitration process (J1708 NETWORK ACCESS part)
I hope we are not reinventing the wheel :)
One more interesting project to check:
https://github.com/MichaelJonker/HardwareSerialRS485/wiki/software-capabilities
@AWI
Thanks for your efforts and persistence :)
Yes, before the packet will be sent, the MyTransport485 will check if there any bytes arrived recently from the serial port. The collision itself can occur during period of the first byte of the packet. (I wish to have time to draw a time diagram for this.)
I think I forgot to mention one more change to the original library:
//The number of SOH to start a message
//some device like Raspberry was missing the first SOH
//Increase or decrease the number to your needs
#define ICSC_SOH_START_COUNT 3
Could you please try to modify this constant ?
It may affect amount of lost packets.
You may also try to increase speed up to 250000 baud.
I have one more idea about collision avoidance:
(In this case we need to make a small modification to the original RS485 module connection, /RE input should be connected to the ground to make receiver always active - then we would be able to receive own messages sent)
We can try to implement the following algorithm:
(Send a packet procedure):
-- check if there any bytes received recently - continue if we have a silence on the bus (done at this moment)
-- send a first SOH (start of header byte)
-- check if it is received by our serial and it's equal SOH.
(so we know at this moment we have no collision on the bus for sure)
-- send next SOH bytes and all packet bytes.
It's like we are sending bytes to the line and reading them at the same time to make sure we had no collision at the same time.
This way we can even resend our packet if collision was detected during packet transmission.
Also we can implement one master and slaves nodes poling mode. But this will not be easy to make in the mySensors protocol architecture.
Let me know what you think about, you probably should have some other ideas too.
@karlheinz2000
I had no chance to look to the AltSoftSerial code, but if we are talking about hardware serial - arduino as a standard has 64 bytes buffer. I think it's possible that your gateway is not fast enough to process packets at high rate from FHEM. Also even if they are processed on time - at 19200 you may loose packets due low serial speed. It's simple no room for next packet.
@AWI
Yes - I am using wired gateway with two nodes (mySensors libs 1.5.2) with my rs485 transport class. I am decided to use only hardware serial for reliability reasons.
I am handling lost messages via NodeRed. Actually I am doing a lot with NodeRed and mqtt. (mySensors<->mqtt gateway, mqtt->influxdb->grafana dashboard, time scheduled and rule based automation, mqtt<-> homeassistant, mqtt <-> custom web dashboard via websockets )
Thanks for testing. I think your errors with one node could be related to AltSerial. RS485 by itself is very reliable.
@AWI
Probably, in my case (I am using hardware serial at 115200) transmission is more reliable because it's not an emulation via AltSerial. Did you try to connect only one node ? I am just curious... In that case should be no lost messages at all.
@hek said:
You are right, those lines should go away. Will you fix?
It's fixed in my repository, please make changes in mysensors library (in https://github.com/mysensors/MySensors/blob/development/core/MyTransportRS485.cpp)
Hi,
Please try to increase serial speed, I am running my network at 115200.
(As I remember you may increase speed for AltSerial up to 57600).
Collision may occur with higher probablilyty at lower speed.
Also you may remove debug lines 161-164:
_dev.print(" wrongid: ");
_dev.print(_recStation);
_dev.print(" - ");
_dev.println(_nodeId);
in https://github.com/mysensors/MySensors/blob/development/core/MyTransportRS485.cpp
@elmarculino
My library is using a standard hardware serial port of arduino - you have to disable debug option in MySensors config and use the serial port only for RS485. The 'garbage' you are receiving are actual binary communication packets intended only for RS485 bus. You have to disconnect your serial to usb adapter in case if you are using Arduino Pro. Please take a closer look to the video and schematic coming with the library. You can use and 'sniff' your serial console - but you must to disable any additional serial debug prints to the console in production mode. Remember - your serial console is a RS485 bus with this library.
@elmarculino
I am using a custom controller based on the node-red, mqtt broker and homeassitant with mqtt bindings. But this is not essential - you can use 'nc GW_IP GW_PORT' from unix command line to issue commands to gateway directly. Try to separate your basic building blocks to smallest parts and then debug it.
@elmarculino
In Gateway:
#include <MyTransportRFM69.h>
//#include <MyTransportNRF24.h>
//#include <MyHwATMega328.h>
...
MyTransportSerial transport(Serial,AUTO,2);
Should be:
//#include <MyTransportRFM69.h>
//#include <MyTransportNRF24.h>
#include <MyHwATMega328.h>
....
MyTransportSerial transport(Serial,0,2);
In 4relay / 4 switches:
Personally I am assigning a static ID to nodes, so I did not tested an AUTO option in gw.init. However I think this it should work. Also make sure you are downloaded a latest Serial transport class from github with some minor corrections.
@radekzm said:
HELP: Please instructions on how I can run this RS485 transport class for beginners.
You have to use a stable 1.5.2 version for my RS485 transport class. Not a development branch. You also may want to try development version too. The instruction was written for 1.5 (1.5.2) version of mysensors libs.
Some basic questions:
- First point instructions: File "SerialTransport.h" and "SerialTransport.cpp" download to C:\Program Files (x86)\Arduino\libraries\MySensors[here]. is this correct ?
...\Arduino\libraries\SerialTransport\ [HERE]
- On the second point instructions: "Add #include <SerialTransport.h> to your .ino sketch" but examples do not have this:
https://github.com/mysensors/Arduino/tree/development/libraries/MySensors/examples/MotionSensorRS485
https://github.com/mysensors/Arduino/tree/development/libraries/MySensors/examples/GatewaySerialRS485
way ?
They are for development version - not for stable 1.5.2
In what file i must put this line "#include <SerialTransport.h>" ? main sketch ?
Yes.
- The third point instructions: Replace transport class with: "Replace transport class with: " where exactly ? Maybe I have a different version MySensors because I can not find the declaration "#define MY_RADIO_RF24" and replace it with a "#define MY_RS485". I do not know how to change the NRF to RS485 in lib MySensors. Please precise instructions with examples for the current version lib MySensors.
Please check examples for version 1.5 (1.5.2)
- Can I get examples of sketch (confirmed that work with the physical bus RS485) Gateway and sensor.
/*
* MockMySensors 485
*
* This skecth is intended to crate fake sensors which register and respond to the controller
*
* Barduino 2015
*/
#include <MySigningNone.h>
//#include <MyTransportRFM69.h>
//#include <MyTransportNRF24.h>
#include <MyHwATMega328.h>
#include <MySigningAtsha204Soft.h>
#include <MySigningAtsha204.h>
#include <SPI.h>
#include <MySensor.h>
#include <MyMessage.h>
#include <SerialTransport.h>
#define RADIO_ERROR_LED_PIN 9 // Error led pin
#define RADIO_RX_LED_PIN 8 // Receive led pin
#define RADIO_TX_LED_PIN 7 // the PCB, on board LED
// Wait times
#define LONG_WAIT 500
#define SHORT_WAIT 50
#define SKETCH_NAME "FakeMySensors 485 241"
#define SKETCH_VERSION "v0.2"
// Global Vars
// unsigned long SLEEP_TIME = 60000; // Sleep time between reads (in milliseconds)
unsigned long SLEEP_TIME = 3000; // Sleep time between reads (in milliseconds)
boolean metric = true;
long randNumber;
// Instanciate MySersors Gateway
//MyTransportNRF24 transport(RF24_CE_PIN, RF24_CS_PIN, RF24_PA_LEVEL_GW);
//MyTransportRFM69 transport;
MyTransportSerial transport(Serial,241,6); // serial port, node, dePin (-1 disabled)
// Message signing driver (signer needed if MY_SIGNING_FEATURE is turned on in MyConfig.h)
//MySigningNone signer;
//MySigningAtsha204Soft signer;
//MySigningAtsha204 signer;
// Hardware profile
MyHwATMega328 hw;
// Construct MySensors library (signer needed if MY_SIGNING_FEATURE is turned on in MyConfig.h)
// To use LEDs blinking, uncomment WITH_LEDS_BLINKING in MyConfig.h
#ifdef WITH_LEDS_BLINKING
MySensor gw(transport, hw /*, signer*/, RADIO_RX_LED_PIN, RADIO_TX_LED_PIN, RADIO_ERROR_LED_PIN);
#else
MySensor gw(transport, hw /*, signer*/);
#endif
//Instanciate Messages objects
#ifdef ID_S_DOOR
MyMessage msg_S_DOOR(ID_S_DOOR,V_TRIPPED);
#endif
......
......
I use Windows, path of arduino lib is: C:\Program Files (x86)\Arduino\libraries.
You have to decide which version of the library to use.
My SerialTransport is written only for version 1.5.2
It's tested and working. BTW, I will upload updated version in a few minutes to github.
@kimot
Thanks for pointing to mrbus.org.
I have seen this before - it's really nice implementation of RS485 bus management.
It's worth trying to implement it. However, I can see only one weak point of ICSC lib. It's a moment when both nodes listening a bus and starting to transmit at the same time. In this case the both packets will be lost. (This situation can occur only during the transmission of the first starting byte, so higher bus speed can make this situation rare.)
I have both the radio and wired mysensors network. And wired network in order of magnitude is more reliable. I have a really small amount of lost packets. The packets are retransmitted only due delay in the code of the nodes.
@redvoodoochild
You welcome, I hope it will be useful for you too.