Navigation

    • Register
    • Login
    • OpenHardware.io
    • Categories
    • Recent
    • Tags
    • Popular
    1. Home
    2. LeoDesigner
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    LeoDesigner

    @LeoDesigner

    19
    Reputation
    42
    Posts
    875
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    LeoDesigner Follow

    Best posts made by LeoDesigner

    • RS485/RS232/Serial transport class for mysensors.org

      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:

      1. Put SerialTransport.cpp and SerialTransport.h to folder/directory/path SerialTransport in your library.
      2. Add #include <SerialTransport.h> to your .ino sketch
      3. Replace transport class with:
        MyTransportSerial transport(Serial,0,-1); // serial port, node, dePin (-1 disabled)

      Please let me know about bugs and how it is working for you.

      posted in Development
      LeoDesigner
      LeoDesigner
    • Enhanced Dallas Temperature example with permanent sensor index

      Hi everyone,
      I have made some improvements to the Dallas Temperature Sensors example.

      • made for non blocking main loop (useful for repeater and busy nodes)
        block time max 15ms for sensor read procedure
      • it will remember a sensor index in EEPROM (2 bytes per sensor)
        in case if you need to replace or add a new sensor to the 1Wire bus - all other sensors will keep own sensor index

      You are welcome to use it:
      https://github.com/leodesigner/mysensors-arduino/tree/master/DallasTemperatureSensor_Recall

      posted in Development
      LeoDesigner
      LeoDesigner
    • RE: Unique ID-value DS18B20 Temperature sensors

      Check this solution too:
      https://forum.mysensors.org/topic/2184/enhanced-dallas-temperature-example-with-permanent-sensor-index

      posted in My Project
      LeoDesigner
      LeoDesigner
    • RE: RS485/RS232/Serial transport class for mysensors.org

      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

      posted in Development
      LeoDesigner
      LeoDesigner
    • RE: RS485 Stress test

      @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)

      0_1478452964585_AN01230A.pdf

      I hope we are not reinventing the wheel 🙂

      One more interesting project to check:
      https://github.com/MichaelJonker/HardwareSerialRS485/wiki/software-capabilities

      posted in My Project
      LeoDesigner
      LeoDesigner
    • RE: RS485/RS232/Serial transport class for mysensors.org

      @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.

      posted in Development
      LeoDesigner
      LeoDesigner
    • RE: RS485 Stress test

      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.

      posted in My Project
      LeoDesigner
      LeoDesigner
    • RE: Enhanced Dallas Temperature example with permanent sensor index

      @redvoodoochild
      You welcome, I hope it will be useful for you too.

      posted in Development
      LeoDesigner
      LeoDesigner
    • RE: RS485 Stress test

      @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 AVOIDANCE: listen rxPin for time of one byte + few bits symbol interval
        • if bus is free: wait random time ( few bit's interval, 5-7) and check the bus again
        • if bus is free: start transmission of the first byte (start of the packet marker).

      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).

      posted in My Project
      LeoDesigner
      LeoDesigner

    Latest posts made by LeoDesigner

    • RE: RS485 Stress test

      @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.

      posted in My Project
      LeoDesigner
      LeoDesigner
    • RE: RS485 Stress test

      @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.

      posted in My Project
      LeoDesigner
      LeoDesigner
    • RE: RS485 Stress test

      @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 AVOIDANCE: listen rxPin for time of one byte + few bits symbol interval
        • if bus is free: wait random time ( few bit's interval, 5-7) and check the bus again
        • if bus is free: start transmission of the first byte (start of the packet marker).

      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).

      posted in My Project
      LeoDesigner
      LeoDesigner
    • RE: RS485 Stress test

      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.

      posted in My Project
      LeoDesigner
      LeoDesigner
    • RE: RS485 Stress test

      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.

      posted in My Project
      LeoDesigner
      LeoDesigner
    • RE: RS485 Stress test

      @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.

      posted in My Project
      LeoDesigner
      LeoDesigner
    • RE: RS485 Stress test

      @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)

      0_1478452964585_AN01230A.pdf

      I hope we are not reinventing the wheel 🙂

      One more interesting project to check:
      https://github.com/MichaelJonker/HardwareSerialRS485/wiki/software-capabilities

      posted in My Project
      LeoDesigner
      LeoDesigner
    • RE: RS485 Stress test

      @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.

      posted in My Project
      LeoDesigner
      LeoDesigner
    • RE: RS485/RS232/Serial transport class for mysensors.org

      @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.

      posted in Development
      LeoDesigner
      LeoDesigner
    • RE: RS485 Stress test

      @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.

      posted in My Project
      LeoDesigner
      LeoDesigner