@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.
@andriej
Just put CAT5e to every place (or even two CAT5e to each TV, room - as I done myself). Later you will decide what kind of signals will travel over CAT5e wire. It can be Ethernet or RS485, CANbus, or something else. Regular twisted pair Ethernet is also has a star topology with central hub/switch. (You may also remember an old Ethernet system with one base cable and terminating resistors on the both ends). For a really long distance - RS485 is the winner anyway - up to 1200m on slow speed.
@kimot
Just a quick look
http://www.aliexpress.com/item/MCP2551-High-Speed-CAN-Communicate-Protocol-Controller-Bus-Interface-Module/32472004400.html?spm=2114.031010208.3.27.bEv7Im&ws_ab_test=searchweb201556_1,searchweb201644_3_79_78_77_82_80_62_81,searchweb201560_1,searchweb1451318400_6148
They are five times more expensive.
But it might be another option for wired network too.
@andrej it is still a line not a star topology.
@cranky
Yep - you are right
Does anybody had a problem with retained messages from mqtt broker?
Seems to me I am receiving only some retained messages from mosquitto - not all of them 
Looks like it's a bug in nodered mqtt or mosquitto.
@cranky
One small bugfix to your ToString function.
//msg.payload = msg.payload.toString().replace(/[\n\r]/g, '');
// sometimes we are receiving a several messages in one packet
// we should spit them and emit one by one
var outputMsg = [];
msg.payload = msg.payload || '';
msg.payload = msg.payload.toString();
var parts = msg.payload.split("\n");
for (var id in parts) {
var payload = parts[id].replace(/[\n\r]/g, '');
if (payload.length > 0) {
outputMsg.push({
payload: payload,
controller: msg.controller
});
}
}
return [outputMsg];
@FotoFieber
Great work, keep going! I have a modified version of your flow with message resend if not received - but it's a bit ugly to publish here.
@andriej
The star topology could be a problem. However for low speed nodes this may work anyway.
You may need something like RS485 hub or a GW with many RS485 bus ports.
Or just a separate MAX485 board for each node. You need to test it.
I have implemented a resend if not received algorithm based on node-red.
It is working only one way from controller/mqtt/gw -> node.
The message will be resend after timeout in case if it is not acknowledged by a node. I can gather stats based on number of packets/lost per node. Even my RS485 nodes have a small packet loss. An average packet/command roundtrip (gw->node->gw) on radio is about 40-50ms, and 10-30ms on wired RS485 bus. Usually acknowledgement arrives after 50ms for sure - but some packets are received after 150ms and even after 250ms (who knows - maybe node is busy or gw). I am still testing this approach based on node-red. Seems to me the packets from gw to nodes are lost more frequently. One of my distant radio nodes loosing about 70% of messages
@andriej
According to: https://en.wikipedia.org/wiki/RS-485
"It offers data transmission speeds of 35 Mbit/s up to 10 m and 100 kbit/s at 1200 m. "
also check this: https://www.maximintegrated.com/en/app-notes/index.mvp/id/367
You may design a bus with up to 256 nodes.
CAT5 is the best choice anyway for any type of communication (I mean you can run regular Ethernet on them too).
Check the video at the beginning of the post. It's a working example of two remote nodes connected only with one CAT5 cable over 50m. They are working at 115200 - however speed might be up to 1 Mbit/s.
@MarkV
Regarding the USB to RS485 adapters:
I think they are using a some kind of serial to USB chip like CH340/341. So your RPi will be able to see RS485 bus as the regular serial port. It may work. It worth trying, you can always build an Ethernet GW later in other case.
@shabba
I am using exactly the same MAX485 modules. It is much more reliable media comparing to radio communication.
@hek
Thanks for adding DE pin management code.
@kr0815
Take a look here:
http://forum.mysensors.org/topic/2184/enhanced-dallas-temperature-example-with-permanent-sensor-index
I think this will solve your issue.
@hek
I am wondering why did you remove the code responsible for dePin management ?
It's not possible to use MAX485 boards without tx/rx management.
@brianc1969
It is absolute possible.
I am pooling this way a relay statuses when node starts.
Hi everyone,
I have made some improvements to the Dallas Temperature Sensors example.
You are welcome to use it:
https://github.com/leodesigner/mysensors-arduino/tree/master/DallasTemperatureSensor_Recall
@tbowmo
Node will listen RS485 bus before it will try to transmit anything (just like Ethernet).
So other nodes will behave yourself
But we have another difficulty: standard bootloader know nothing about TX/RX (dePin) management. So, we need to modify it to be able correctly emulate Arduino upload process. Maybe a simple schematics with diode will work in that case.
I am still busy with other improvements.
@hek
Sure - but it can be possible done with standard bootloader - we just have to emulate standard Arduino sketch upload process on the gateway side. But I am not sure if it's possible to do with half duplex protocol. Just an idea.
@hek
Speed is one of the reasons why I have decided to use hardware serial.
But we should be flexible and universal as much as we can. I had been thinking also to add support for over the wire firmware update. As you have done with wireless.
@hek
My example boxes are installed right now on the site and doing a daily job
It will take time to build a new one. I may try a breadboard, but I am still busy to finish additional improvements to mysensors.org project. (I will share them later - it's will be interesting too - I hope )
Actually, it's easy to test RS485 transport without a RS485 converters - just use a simple schematics I have been talking before.
Also, you may want to look to this: https://github.com/MajenkoLibraries/ICSC/pulls
It's untested support for SoftwareSerial option for library.
With AltSerial we will be forced to use only a documented pins.
Anyway - I am glad to contribute a bit to great mysensors community.
@hek
My modules are from http://www.aliexpress.com/item/FREE-SHIPPING-5PCS-LOT-MAX485-module-RS485-module-TTL-turn-RS-485-module-MCU-development-accessories/1718665649.html
They are the same as yours - based on MAX485.
However, it is possible to run a simple TTL signal level bus on a short distances.
(https://github.com/leodesigner/mysensors-serial-transport/blob/master/sch.png)
Finally I am received my RS485 modules.
Here is the working example of gateway with two nodes:
RS485 Arduino transport for Mysensors.org – 00:14
— Axel Vivaldi
@shabba Take a look to https://github.com/MajenkoLibraries/ICSC/tree/master/debian
It may be a starting point for you. You can adopt this part of the ICSC library to your RPi2 setup.
@shabba I am not quite understood what exactly you want to do with USB. You can use arduino nano without any problems at all.
All you have to do just to make sure to disconnect your RS485 bus from RX pin during the time when you will upload your sketch/firmware.
Also it is possible to use this class without any converters at all. See attached simple schematics on github page.
Regarding USB - you can attach an RS485-USB adapter to this bus as well too.
So it is an universal solution for a serial communication between many arduinos via serial port. Please note about possibility to connect this bus to RPi directly. ICSC lib include the library for RPi too.
Also, it's better to disable DEBUG option in mysensors config file to avoid additional traffic on the serial bus.
Hi everyone !
I needed a wired solution for my several nodes.
Here is the serial rs485/rs232 wired network transport for mysensors.
https://github.com/leodesigner/mysensors-serial-transport
It is based on the Majenko ICSC serial library.
Can you please test it? It is a beta version - but it is working for me.
(However, I am still waiting for my rs485 boards to arrive)
You can find more technical information at
http://sourceforge.net/p/arduino-icsc/wiki/RS-485/
To use it, you have to:
Please let me know about bugs and how it is working for you.
