CAN bus transport implementation for MYS
-
@kimot
thank you for your answers in this case.You think, the SN65HVD230 is better than the max485? Can I use the SN65HVD230 with mysensors and Transport class rs485 without changes in the code? If yes, how do I do with the "DE-Pin" ?
I don't know, why you are using 3 Bus Systems at your home? Why not 1 Stable Bus?
I want a stable bus for several things in my new home. PIR, Standard button Switch, Contacts (Window, Smoke), Dimmers, RGB Dimmers, Temperaturesensors, Relays should be my nodes. The Problem in this case is, that I want to use my nodes even when the bus have Errors.
So if you seperate the communication from sensors to Gateway (with your self made library, as you wrote here) and the Gateway communication with the Controller with the mysensors libs, that would be excactly what I'm locking for.My idea besides of that is, that nodes can work without the bus. For examble the push button Switch can Switch the light, even when the bus is down. With mysensors this is not possible, because nodes have to register to the Gateway. Mysensors should be a "add on" for the nodes in my home, to control all on one place - openhab.
I also want to have a stable bus, because it would be very bad, when i press a push button and nothing happens (=is dark in the room), because the bus is busy. Sure it doesn't matter if a temp sensor can't transmit it's value to the Controller. But for Switch / PIR it is very important.
@hausinger said:
My idea besides of that is, that nodes can work without the bus. For examble the push button Switch can Switch the light, even when the bus is down. With mysensors this is not possible, because nodes have to register to the Gateway. Mysensors should be a "add on" for the nodes in my home, to control all on one place - openhab.
The only way to handle this kind of problem, is to make device with INPUT and OUTPUT at the same time !
You would then have to think of an intelligent way of handling what happens when the INPUT see events :
Do you have to transmit it to the gateway, wait for a reply, and then fall back to a "fail" mode if the gateway doesn't reply after a delay ?
Do you prefer handling the event simply by turning ON/OFF the output, and just inform the gateway of what happening ? this way, even if the bus is down, your device will continue to work... but you're loosing the benefits of having an intelligent controller/gateway that can make decisions... -
@hausinger said:
My idea besides of that is, that nodes can work without the bus. For examble the push button Switch can Switch the light, even when the bus is down. With mysensors this is not possible, because nodes have to register to the Gateway. Mysensors should be a "add on" for the nodes in my home, to control all on one place - openhab.
The only way to handle this kind of problem, is to make device with INPUT and OUTPUT at the same time !
You would then have to think of an intelligent way of handling what happens when the INPUT see events :
Do you have to transmit it to the gateway, wait for a reply, and then fall back to a "fail" mode if the gateway doesn't reply after a delay ?
Do you prefer handling the event simply by turning ON/OFF the output, and just inform the gateway of what happening ? this way, even if the bus is down, your device will continue to work... but you're loosing the benefits of having an intelligent controller/gateway that can make decisions...@napo7 said:
@hausinger said:
My idea besides of that is, that nodes can work without the bus. For examble the push button Switch can Switch the light, even when the bus is down. With mysensors this is not possible, because nodes have to register to the Gateway. Mysensors should be a "add on" for the nodes in my home, to control all on one place - openhab.
The only way to handle this kind of problem, is to make device with INPUT and OUTPUT at the same time !
You would then have to think of an intelligent way of handling what happens when the INPUT see events :
Do you have to transmit it to the gateway, wait for a reply, and then fall back to a "fail" mode if the gateway doesn't reply after a delay ?
Do you prefer handling the event simply by turning ON/OFF the output, and just inform the gateway of what happening ? this way, even if the bus is down, your device will continue to work... but you're loosing the benefits of having an intelligent controller/gateway that can make decisions...Hi @napo7
Yes, i would prefer handling it direct on the nodes. Not only ON/OFF, also dimmer (1 short press on the push button - Light on (last value) + turn on power supply of the lamps (Relais=1), 1 short press on the push button - light off + turn power supply off of the lamps (Relais=0), 1 Long press on the bush putton - dimming). The Gateway (and Controller) should be able to do the same Thing, if the bus is ok. But if it fials, i could use it localy and so i'm not in a dark room. -
@kimot Would it be hard to write CANbus version of the transport class based on rs485 implementation? Is there some extra things you need to handle on top of "basic serial communication"?
@pjr
Hi,If we want to use CAN drivers instead of RS485 drivers, we don't have to add anything to the code.
We will benefit of CAN drivers capabilities, but we still have to write some code to handle collisions.If we want to use a CAN CONTROLLER, yes, there is more to do :we must setup the CAN controller each time the board start-up : this is needed to tell the CAN controller on which kind of message we must listen to, what is our ID (CAN controller do all the filtering job...), etc...
-
@napo7 and if we use CAN CONTROLLER it does all the needed collision avoiding, detection and "resending" and it dont need to be written in the transport class? Only the initalization of the CAN CONTROLLER needs to be added?
Is there much difference in communication reliability if we use CAN DRIVER vs. RS485 DRIVER currently without modifying the rs485 transport class?
-
Yes, the CAN controller handles all this stuff (collision detection and resending...)
So, yes, only CAN initialization has to be added.In facts, NO, without adding code, there will be no difference between between the two drivers. I haven't looked at the class, but if we use a CAN driver, the goal is to use its advantages to "allow" collisions and handle them better.
-
Hi everyone. Have there been any developments regarding CAN Bus Controller integration to MySensors Library?
Thanks. -
Hi everyone. Have there been any developments regarding CAN Bus Controller integration to MySensors Library?
Thanks.@gonzalonal
Yes I am.
But I have got a lot of other works, so It's going slowly.
The problem is, that CAN can transfer only 29 bits ID ( 3 bytes + 5 bits ) and max. 8 bytes of data.
MySensors message has got max. 32 bytes ( 7 bytes header and 25 bytes of data ).
I must either send MySensors message like 3 packets of CAN messages or limit properties of MySensors protocol.
Now I am working on second variant.
I am able code to one CAN message:
6 bits - destination
6 bis - sender
(gateway, broadcast, 62 nodes - it is enough for me for one bus. I plane three buses and gateway can " translate " or "expand" nodes ID from and to controller )
1 bit - RACK
1 bit - IS ACK
3 bits - command
6 bits - type ( MY sensors has 56 types max. now )
6 bits - sensor id ( only 64 sensors per node ... )
3 bits - payload type ( int, uint, long .... )The sum of these is not 29, but 32 so I am using a little "hacking" data length field in CAN frame to obtain additional 3 bits.
For data I have got 8 bytes.
It is enough for conventional data types from char to floating point.
Only text messages are limited to 8 bytes. But for us, old boys, who remember old DOS file names, it is enough.In this time, I am able send and receive packets in that format between nodes and now I am working on transfer RS485 library to CAN library.
The problem is, that RS485 library sends destination address, node id, length of message and then MySensors message, witch "surprisingly" contain again destination and sender bytes. A little bit redundant for me.
So I must remove some fields from MySensors message, put it to CAN ID and send only payload in CAN data fields.
When I receive CAN message, I must again assemble correct MySensors message format and put it to MySensors system.
But unfortunately only documentation is library code itself :o(I try a "stress test" like here:
https://forum.mysensors.org/topic/5051/rs485-stress-testI send 10 000 messages from two nodes to "gateway" ( 22kbps ).
Result - zero messages lost.
But it is expectable with CAN. -
Hello,
I'm really interested in the solution you are working on (can bus with mysensors). I would like as much as possible to avoid a wireless network but I still would like to use the "mysensors" libraries and protocol. As this project as a lot of users it's a warranty of longevity.
@kimot : your trials seems great, did you have the change of getting further?
-
Hello,
I'm really interested in the solution you are working on (can bus with mysensors). I would like as much as possible to avoid a wireless network but I still would like to use the "mysensors" libraries and protocol. As this project as a lot of users it's a warranty of longevity.
@kimot : your trials seems great, did you have the change of getting further?
@gasuter
I think I am able sending data from node to gateway (GW) and through it to controller.
There is limited data space in CAN message, so I must avoid sending long strings and send all as possible like integers, longs, floats etc. It is not problem when sending from node to GW, because in the message header is field, which describes type of payload and according GW code, I assume, it can translate it to strings for controller correctly.
But problem is, when GW receives data from controller. Payload is always string and I must convert it to int, long, float and sometimes short string for sending it through CAN bus to the node. But from serial protocol GW can not recognize, what type of this payload is. I think I need to built some translation table for each serial protocol TYPE to variable type.
But maybe each controller sends different type of data for the same sensor value (0, 1 x "on", "off" ).
Or better something "smart" like "when there is a dot and not letter in string, it is float", "if there are only numbers, it is int or long" .... -
Sorry to hijack a bit, but j1708 looks like it can do bit level collision detection with a max485, it means controlling the DE line. More work than CANBus?
-
Sorry to hijack a bit, but j1708 looks like it can do bit level collision detection with a max485, it means controlling the DE line. More work than CANBus?
@wallyllama
I look at j1708 spec. and I think, that this protocol was born long before CAN.
It uses MAX485 bus drivers that way, that CAN bus drivers can works at higher speeds and better now.
And I must say, I can see better multimaster implementation for RS485 bus than j1708 ( clever addressing, bus arbitration, CRC instead of simple SUM etc. ) And there is AVR libraries so you do not start from scratch. For J1708 I can not find any. -
A friend of mine who works a lot with can bus told me that j1939 supports multi pack when bigger payloads are needed
@gohan
Thanks for your message.
All CAN controllers can send max 8 bytes of data, so longer messages must be divided to multiple packets. J1939 works this way too. That is what I do not want. With heavy traffic especially GW must again assemble packets to complete message, but packet of one message will not come one by one. Packets will be coming mixed from different nodes and GW must assemble them in memory to complete message from each node. So you for example has 30 messages in different state of completion. Some of them has received 1 packet and waiting for 2nd , some has 2nd and waiting for 3rd. ....
I am concerned that it does not work for ATmega328, and must be used processor with more RAM. -
@kimot Thank you very much for your reply. It's sounds great and more I read about bus for IOT more I think Can is the best solution. But still the problem with the data length bother me. The more hack and tricks we have to add to a system the more problem we can have.
I made a little research on internet about Can and found that there is a new version called CAN FD that is actually compatible with CAN 2 but it can be used at a higher speed between to CAN FD nodes (but that is not really interesting us for our use). The real plus is that you can send data up to 64 bytes. And I think that could be the solution of the problem, no?
-
@kimot Thank you very much for your reply. It's sounds great and more I read about bus for IOT more I think Can is the best solution. But still the problem with the data length bother me. The more hack and tricks we have to add to a system the more problem we can have.
I made a little research on internet about Can and found that there is a new version called CAN FD that is actually compatible with CAN 2 but it can be used at a higher speed between to CAN FD nodes (but that is not really interesting us for our use). The real plus is that you can send data up to 64 bytes. And I think that could be the solution of the problem, no?
@gasuter
CAN FD looks good, until you start to looking for IO chips.
MCP2561FD is only CAN bus transceiver ( like MAX485 ) with higher speed ability, then traditional CAN bus drivers.
It has no logic "on board".
You need something like MCP2517.
But try find datasheet, prices etc. for this chip.
I think, it will be very expensive way for us, like standard CAN several years ago was.
