Posts made by napo7

You're not !
I'm also exclusively on linux, and I use MySensors !
I was using Arduino IDE, and now I'm using atom.io, but both are working on linux !

I see in the domoticz code that there are some fields to record Signal Level for other sensors types.
Making domoticz handle the signal level would then be possible.
There is 2 enhancements to do so :

• Handle a standard variable or subtype in MySensors to carry the signal or RSSI level (github issue 581 : https://github.com/mysensors/MySensors/issues/581)
• Modify the domoticz code to show somewhere the Signal Level for MySensors devices. (no github issue yet)

That would be interresting, since it would also allow to trigger some custom scripts if a device falls in a poor level...

That's not a software interrupt. In facts, the atmega supports interrupt on all pins, and also waking-up the device from any pin change, but the sleep function only support "external interrupts" which can only be triggered on pin 2 and 3.

Yes, I know that fsck repair the partition, but it's not really convenient to run a fsck at 4' AM because the server has crashed and doesn't want to startup because of corrupted FS

Thanks !

Hi,

I have the same question, but a little bit different

I use a RFM69 with the Mysensors 2.2.0 beta.
I don't sleep my node with the provided function, since I don't want to sleep for some time, but until a Pin Change Interrupt is triggered (via pin A0 or A1). So, I can't use the sleep() function.
I do put my node to sleep with avr core functions (setting registers, calling power_all_disable() and sleep_cpu()...) but I suppose the radio is never put on sleep !

Is there a function I can call to sleep the radio, and if yes, is there another function I should call before sending, to awake the radio ?

Thanks !

@gohan No they should'nt, as soon as they need to be modified.

There is probably better filesystems which are powerfail-resistant, but I'm not an expert and can't name any of them !
The main subject is still applicable : beware of wear ! Userdata which moves frequently such as databases should not be on a sd-card. Why not on an external HDD (or SSD...)

@gohan If you are using dietPi, you just have to run the command "dietpi-drive-manager" (sorry not sure of exact spelling, I'm not near a dietpi !)
Then, you'll have a menu that will allow you to choose per-partition read only or read-write.

@dbemowsk That's a good point to avoir SD wear-out, but it didn't avoided me the corrupted ext4 partition on a power-fail.
That's why I did choose to set the root partition as RO, so I'm sure the system will not hang at startup because of "partition not clean, cannot mount it"

I've found a neat project for such uses :
It's called "DietPi" : it's a debian based distribution available for Raspberry pi, Orange PI and many others.
Many advantages :

• It's really lightweight.
• By default, logs are not written on SD card but in a RAM FS.
• Dropbear as SSH server instead of (more) heavy openSSH.
• and at last, but not least : ability to set root filesystem as READ ONLY. This is a BIG pros because the extFS is really more robust when not mounted RW.
  This way, you can still put your databases on another partition which would be more tolerant to power failures....

That's great for "IOT" which need to be powered-off without needing to shutdown linux. I use it for some "connected speakers" : I plug them, they start, I listen to music, and when I'm done, I unplug them ! Never fail !!

BUT, IMO for a home automation server, the best and only option is an UPS (uninterruptible power supply) : either an AC one, or a powerbank-like battery : some of them are able to charge and deliver their juice without failing.

Hi @tekka
Would you share your poc so I could try to enhance it ?

Regards

Hi @tekka,

Any news about RFM69 for MYSBootloader ?

I've had another look in the code, too much complicated for my skills !

Hi !

Not so much news,
The PCB are at home
Missing time to test them, but I should start in a few days !

I've added some pictures, and an ebay link for the board only (not 10 boards, only one !)

Yes of course !!

I have some of them available to purchase (pcb only).

I'll do an ebay link this morning.

What I'm doing is something similar to you :

I've made "dimmer boards" for lights, which doesn't have input buttons.
I've made "switch boards" which runs on batteries. Each board sleeps until a button is pressed. When the button is pressed, I send a message to the light that needs to be switched on/off...

I can explain more if you're interrested.

You're not totally right :
RFM69 can be used with a raspberry pi, you must use a usb (serial) gateway.
That's what I'm doing, and I've got very good results : My house is made of outside concrete walls; with my gateway in the middle of my house, I can walk outside 60-70 meters before starting to loose some packets.
And that's only with a dirty cheap 8cm wire antenna. I'm sure that a better antenna (see GPA-Ground Plane Antenna on internet) will allow some meters better...

Some people are talking about +1Km ranges with propers antenna.

I didn't go the NRF24 way because I wanted to use sensors outside the house, and without repeaters that wasn't possible.
PS : I use 868Mhz RFM modules : using 433 could also rise the range.

Hi there !
I know this thread is almost one year old, but I haven't found any recent thread about broadcast messages.

Is there a way to broadcast messages ?
My switchs are meant to drive groups of light.
Instead of sending multiple messages, each switch could broadcast a message which each light could intercept, check if the "group id" is the correct one, and turn on

Great !
Now I have to implement a circular buffer and the solution will be perfect !

Edit : This reading is interresting : http://hackaday.com/2011/05/16/destroying-an-arduinos-eeprom/
The user did a test to wear out EEPROM, and did managed to get more than 1M writes before it started to fail !

Quick thought :

At least, if the old value is the same as the new value, don't write it !
I'm sure we can avoid a big amount of updates in case of the controller resend the same value...

I did thought of a kind of circular buffer , but it's too late for my brain to find a working solution
Reading the atmel doc will surely be easier !

Hi there !

I was about to use saveState function, but I first aked myself about the wearing of the EEPROM.
It seems that the EEPROM has a life of about 100.000 writes.
So, if I do 100 writes per day (4 state change every hour), it takes 1000 days to write 100k times : about 3 years and the EEPROM may start failing.

Do anyone use a wear-leveling trick ?
I've quickly searched for code over google, but hasn't tried anything yet.

Catch it !

Thanks !

So, when I send a message with anything but 0 as destination, it goes thru the gateway, and the gateway rewrites a new message with the same destination ?

I'll make a POC this evening, two nodes without gateway, to see if node-to-node communication works without gateway.
I think it should work.

A questions remains to me : How to easily set EEPROM parameters from the controller.
I plan to use V_VAR(1-5) messages, but I think I'll have to write some kind of tool to easily set it, since the controllers I know doesn't seems to allow sending custom messages.

BTW, That's where I need a "V_ACTION" message type : setting a light from the controller needs V_STATUS, V_DIMMER, but from the switch side, I only need a "V_ACTION" message, to inform the light to take action regarding its current state...

@hek said in (Almost) Controller-Less MySensors switch/light network:

You could send the light-switch-message both to the controller and the other light node. I.e.

msg.set(1);
msg.setDestination(0);
send(msg);
msg.setDestination( <my other light node id> );
send(msg);

In facts, I think I don't need to inform the controller of the switch press if the switch has a destination ID set.

@Boots33 said in (Almost) Controller-Less MySensors switch/light network:

When you are controlling internal lighting for a house I think it is important that the light can be operated even without the controller or gateway being available.

The only way i know of doing that with Mysensors is to have a switch connected to the node controlling the light. Don't know whether your wiring topography will allow for that but it should be considered for at least some lights.

Yes, that's a very important point : avoid black-outs when the controllers goes down for any reason.
That's why I was planning a solution where buttons directly drive lights, without having the need of a controller.
But, my boards are made, and I didn't put any inputs on the lights board, to replace my "old boards" with new ones and make the transition from old to new boards easier. Moreover, I often have 2 switchs that can command the same light, and I sometime change switch/light assignment.

I think I will tend to a solution where each switch will have a reserved EEPROM space :
01 : Destination node ID
02 : Destination child ID
03 : Message type to send
or something similar.

Eventually, a switch could turn on/off many lights at the same time (2 or 3 in my case). So I'll have to set i.e. up to 3 destinations for each switch.

@hek is it possible to do something like

msg.setDestination([Destination ID]).setSensor(Destination Child ID]);

to specify to which child this message is for ? (I have up to 8 lights on the same board)

I address this issue with keeping AUTO ID.

When I need to change a node ID, I use an USBASP programmer which can directly dump and write the EEPROM memory.
When I dump the EEPROM I get a binary file which is a 1:1 copy of the EEPROM memory.

I then use a hex editor to change the node ID and then write back the EEPROM file to the node.

This way, I can keep AUTO ID feature, the controller always give me new ID when needed, and I can easily replace a failing node with the same board, just changing his ID after uploading his firmware !

Hi,

I'm working on the code of my new nodes.
My house is fitted with a great number of door-bell-like switches, and I'm using a home-automation solution which doesn't fit my needs.

My current topology is like this :
There is SWITCH boards, and LIGHT boards.
The LIGHT boards doesn't have buttons inputs, they are only controller from messages.

When a switch is pressed, it can either send a message to the controller, or to another light. The message type when sent to a light is a "toggle" one.

Then, when the light changes, its new status is updated with a message back on network.

This kind of topology is reasonable , since a light can be either controlled from the controller(aka server), or from a switch. The switch doesn't have to know the state of the light, it just have to send a "toggle" or "action" command to the light without parameter.

Now, I'd like to replace those old boards with mysensors one.
To do so, I can either let the switch report every push to the server, and let the server handle the changes, or program each switch(aka push buttons) to send a message to the light it has been associated.

I see some pros and cons for each solution :
Pros of "Server solution":

• associating a switch to a light is simple (if Controller software supports it)
• Switch/push button code for nodes is simpler. Just report "push" message, no need to keep a track of target light in EEPROM...

Cons of "Server solution":

• If server fails/doesn't answer the lights doesn't work anymore !
• If the server gets busy doing some stuff, the lights can become laggy...

Of course, the Controller is still needed to have a web view of the network, give some tablets entry-points over the house, do some advanced stuffs (heating scheduling VS hollidays, etc...), so I WILL keep it in my setup, but I'd like to avoid the need of it to drive the lights, etc...

Which solution would you use ?
How would you program the nodes so a switch node can send a message to a light node ?

@AWI Ahh Sorry ! Didn't seen the comment !
I thought it was never mentioned since the how-to still refers to resistor divider method (which is, IMO a bad method since it will draw current...)
I'll have a look at Yveaux's lib.

There is a much more efficient way (and cost-less) to measure VBATT :
https://provideyourown.com/2012/secret-arduino-voltmeter-measure-battery-voltage/
It doesn't need any external resistor, so there will be no current flowing even when the Atmega is asleep.

V_STATUS=ON is even more confusing : I still want to be able to toggle the light from a controller, so I'll have to sens status on and off from controller.

Yes , or perhaps V_DEFAULT_ACTION ?

Hi,

I made a simple scenario for each of my shades/covers /roller blind (name them as you whish ! :))
They are controller from just ONE button :
If I push the button :
When the blind is idle, If the previous move was a UP, I make them go down, else I make them go UP
If the blind is already moving (I move them for a certain amount of time), stop them.

So, my feature request is : add a V_ACTION new type.
Of course, the behavior of the blind has to be handled by the arduino program.

The S_COVER would so have : V_UP, V_DOWN, V_STOP, V_PERCENTAGE, V_ACTION.

The same type could also be used for lights : When I press a switch button (doorbell kind), I could send a V_ACTION to a light node (S_DIMMER or S_BINARY) : It would toggle itself depending of his state.

Edit : I found a Github issue that seems very similar to my request :
https://github.com/mysensors/MySensors/issues/724

Well done ! I must admit I wasn't ready to read such a word play
Hum... In fact, I did a small try, cloned the RF24 bootloader, tried to search which pieces of the code I have to modify, but didn't go further....
If you was about to release it in the future days (I'm willing to help/debug/test), I'd have waited, but my projects are going to be on a rush....

I'll try to go a bit further in making my own version

Well, I'll wait a bit, so !

BTW :how much is a bit for you ?

Ah ah ! I was sure that I was dumb !!

I'll have to give a try to port MYSBootLoader to rfm69 so ....

Hi,

I might be a bit dumb , but I can't find RFM69 OTA bootloader ?

Has anyone done it ?

Not this one, but I've ordered some MAX1724 which are also in a "friendly DIY package".
The only external component needed is a inductor.

The idea was to get 3.3V out of a single AA battery.

The max1724 can operate down to 0.8V.

Handling the short press/long press/release by the arduino is quite easy.
I can already send a different event regarding what happens on each button, but the event has to be handled by domoticz

Previously, I was using a custom-made software for all my home automation.
I handled the thing like this :
When event is "pulse" :
if timer is OFF and light is OFF :
- Turn a timer ON for 5 seconds.
- Turn light to 1st dim level (levels are 2, 5, 10, 30, 50 and 100%)
if light is ON and timer is ON :

• Reset timer to 5s.
• Turn light to next dim level
  If light is ON but timer is OFF :
• Turn light OFF

when event is "hold" :
-do another action (ie. turn on/off another light)...

That was working corretly, I did put this script in a function that I could reuse for each light easily, but it was my own home automation system software, and now I want to turn to another system, no more time to fix/enhance my own software !

Hi !

I'm planning to drive lights with my MySensors devices :

I have some Mysensors devices with 8 light outputs (dimmers boards and relay boards),
and I have some Mysensors devices with 8 push button inputs.

I'm used to have 3 functions on the same button with my previous home automation system :
I have the "short press" event, "long press begining" event, and the "long press release" event.
Using these events, I usually set different actions on short press events and on long press begin events.
This allows me , i.e., to drive 2 differents lights with the same button, or to set a dim level with a long press, and an ON/OFF command on a short press.

How should I define my Mysensors devices to return the short press/long press/release events , that can be handled by domoticz ?
What would be the best way to handle those kind of events in Domoticz ?

Perhaps using the "V_TEXT" subdevice type could allow me to report differents events "PULSE/HOLD/RELEASE", but I suppose then I'll have to use nothing else but scripts to handle these on domoticz ?

PCBs are out of factory.
I should receive them in 2-3 weeks.

Stay in touch

Yes, you're probably right ! The ABS used in printing starts to melt at about 185°. I don't know for Legrand boxes !

I don't know how we could manage to exchange our mail addresses ? No PM system on mysensors forum !?

Yes I have

I can also designa box, I should do one ! It's not serious to put a circuit with live voltage without protection !

I'll try to design a box as soon I'll can.

Salut,

Non, je n'ai pas d'idée de boitier .
Mon projet initial était de cacher ce montage dans la cloison, donc inaccessible à l'utilisateur normal.

Ca ne serait pas très compliqué ni couteux d'imprimer un petit boitier via une imprimante 3D!

Launch the 3D Viewer from PCBNew, then do screen-shots

Yes I noticed it !
Since it didn't mention IRQ pin, I didn't seen it at first !

What misleaded me, is that on LowPowerLab forums, some users says that you can absolutely discard this interrupt and poll the radio frequently to ask if a packet is available.

Well, I had a look in RFM69 driver, and it seems that the interrupts handlers are never sets ?
Am I wrong ?

Edit : In facts, DIO0 is not used as an Interrupt source in RFM69 driver : it's a pin that informs the library that, either, a packet has been received, or , the frame we try to send has been sent.

So, the code doesn't use interrupts, but this pin is more a "Data available" pin.

Hi !

It seems that the FRM69 library set the IRQ pin as optionnal. Can someone confirm that the IRQ pin is mandatory ?

I was about to make tests with the 2 same modules, powered by a single CR2032 coin , a boost converter (MAX1724) for one node, and nothing for the other.
Since those readings, I'm not sure that the boost converter is needed anymore.

Just to prove myself and my friends that it is useless, I'll do the test, with each node waking up the same amount of times and two fresh cells (I'll have to reduce the sleeping time for the test to be quick enough...).

I'll post the results on the forum, as soon as the batteries will die, in a few month

Yes, the step converter has an efficiency, ranging from 50 to 90 % regarding the output current and input voltage.
There is also a quiescent voltage inside the converter, so the converter will ALWAYS eat some current, either when the devices are sleeping !

The pros and couns should be measured : I hope we can consome "more" of the battery with the converter (till a lower battery voltage), but perhaps due to efficiency of the converter, we'll have wasted more power !

Not yet !

In fact, the interrupt must be short enough and fast enough to be sure to not miss the RFM69 interrupts.

The code for 8 dimmers will not be really more complicated : in fact, each time we got a zero cross, we must set a timer to zero, and then wait the good amount of milliseconds to turn on the needed outputs.
So, yes, we'll have an interrupts each 10ms (each time the wave crosses the zero, to be precise !), but I think all we have to do in the interrupt handler is set the timer to zero (or to micros() ...) and then on the main loop, wait the good amount of time for each output before setting them ON.

Seems simple on paper, perhaps it will not work on the chip....

In facts, my main concern is : will the RFM interrupt be short enough to not disturb the zero crossing interrupt ?
Although, not yet tested the RFM : do we NEED the interrupt pin ? Can't we poll frequently the RFM?

Yes, you're right for the NRF which can run from 1.9V, but I don't know for RFM, which can also have higher power consumption ?

I did the same on my nodes : The main idea is to get a consistent 3.3V to supply the atmega and radio module, whatever battery voltage you have. So, If you decide to power it with a 3V lithium battery, it will still be giving the radio and CPU 3.3V , and even when the lithium battery will start failing, it will continue to work down to 1V !
I can even use a single AA battery to power my nodes. I use a MAX1724 step-up converter, which start working from 0.8V ! At this voltage, any AA battery is almost 100% empty

@bbarriere, this solution is the one I was using with my previous home automation software.
It is Ok, but not really transparent for most softwares...
I prefer the ZWAVE Qubino solution which I find more beautiful : The heater is seen as a variable light, when you choose a variation value (between 0 and 100%) , it is associated with an order... Neat and clever

@hek, I understand that the forum is English, but since this solution is purely for french appliances, I though we could discuss in french

@Fabien said in Carte Fil Pilote MySensors NRF24L01:

Cette solution pourrait être discutable mais par soucis de compatibilité avec les widgets des controlleurs, je vais utiliser la mê

Cependant, peut etre que certains controleurs supportent des appareils "radiateurs" de type variable ?

However, perhaps some controlers do support heater devices of "variable" kind ?

@Fabien, j'ai fait quelques recherches, et je suis tombé sur çe messages sur un blog :
http://www.looic.com/2016/02/pilotage-de-radiateurs-electriques-par-domoticz-le-materiel/

En resumé, un module ZWave existe pour gérer le fil pilote. Comme le ZWave n'est par contre pas prévu, lui, pour ce protocole, ils ont faire reconnaitre le module comme un variateur de lumière.
Ainsi, les ordres varient de 0 à 100% par tranche de 10%, la dernière tranche allant de 50 à 100%, par ordre de "puissance" du chauffage : arret, hors gel, eco (qui est souvent égal à confort -3°), confort -2°, confort -3°, confort
Ingénieux

Ensuite, il "suffit" dans domoticz de gérer des programmations journalière/hebdo afin d'envoyer aux heures voulues, et aux chauffages voulus, les ordres de variation qui vont bien (0%, 10%, 20%, etc....)

Voila une solution qui me plait !

I saw that the HW version is more powerfull so I went to it. I use 868mhz, i think it's a bit less polluted than 433.

I bought a batch of 50 pcs directly to HopeRf, they proposed me a 2.30$, plus 30$ of shipping.
This makes a good price if you buy a big quantity

I think that HiLink also sells directly power modules ?

@tonnerre33 I had some troubles to convice myself !
At first, I decided to go the NRF way, but seeing that there is many clones on ebay and aliexpress, and that the clones are either poor quality, doesn't goes to sleep correctly, has range issues.... This conviced me to run the RFM69 which has biiig range.
I also have a project to put a sensor in my mailbox, which is 60m away from my house. I hope that the RFM69 will be able to transmit data to my gateway...

@jeremushka Les 4 ordres du fil pilote se génèrent avec 2 optocoupleurs. Pour les 2 ordres supplémentaires des radiateurs "6 ordres", il suffit de mixer du CONFORT / ECO avec des temps différents (regarde sur google, c'est assez bien documenté)

@Fabien, Je n'ai pas encore scripté le noeud. Mes nouveaux noeud sont en cours de fabrication, j'ai donc encore quelques semaines pour y réflechir ! Actuellement j'utilise un autre système domitique (DOMOCAN) avec tout une partie logicielle que j'ai écrit moi même, je gère donc chaque chauffage comme un couple de 2 sorties, et donc j'ai adapté le logiciel en conséquence. Il faut que je regarde comment faire avec MySensors ?
Peut etre utiliser la température de consigne comme étant l'ordre, de 0 à 5 °, par exemple :
0 = "chauffage éteint"
1 = "chauffage hors gel"
2 = "chauffage Eco",
3 = "confort -2° "
4 = "confort -1°"
5 = "confort"

Je suis pret à discuter avec vous des solutions possibles, sachant que je vais être confronté au problème !
De même d'ailleurs, je compte basculer de mon système DOMOCAN et mon soft propriétaire à Domoticz ou Jeedom (avec une préférence pour Domoticz pour l'instant), il va falloir aussi que cette programmation d'ordre soit integrée au logiciel de domotique ? J'ignore si ces deux protagonistes gèrent la programmation des chauffages, et qui plus est, le fil pilote ??

Hi,

I've made a small module which generates a 220V signal for french heaters called "Fil Pilote".
It allows you to remote controls your "fil pilote" enabled heaters

Here is the link to the project !

https://www.openhardware.io/view/317

I planned to use them in my house, but I then changed my mind and swapped to RFM69 instead of NRF24L01, so I sell the PCB I never used !

French description :
J'ai créé un module fil pilote pour MySensors, mais j'ai décidé de basculer du NRF24L01 au RFM69. Ainsi, j'ai les PCB que je n'utilise pas (je les propose donc en vente , juste pour rembourser les frais de fabrication).

Great !
I've done a small quick desktop test this morning.
I've managed to burn optiboot with 8mhz internal RC, it works ok with just the Atmega328 and no external parts
But, I've searched for fuses settings for 1mhz. Found none !
I suppose I have to choose "8Mhz int rc" and apply "clock divisor =8 " ?
So, the int. RC will run 8mhz, but the cpu will be clocked 8 times slower, so 1mhz ?

Am I right ?

Do that means that the atmega328 can run on 1mhz without crystal ?
This would solve some space constraints problems !

Is the internal RC oscillator stable enough to communicate with NRF24 correctly ?

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.

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

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

Yes, this device is interresting.

None the less, we're thinking of using only a CAN driver without controller, in a kind of RS485 bus...
This way, we make an hybride bus : simplicity of RS485, with multi-master possibilities of CAN thanks to the way his driver works !
So, having a CAN controller on ESP32 is ( from my point of view) not-so-much usefull.

Hi,

@LeoDesigner , that's the begining of a way avoiding collisions, but it's not sufficient :
The problem is that if two devices performs that check at exactly the same time (even if it's not so-probable, it can happen), they will start speaking at the same time !

A second step would require HANDLING (and not avoiding) collision : what can (what MUST) we do when two devices speak at the same time ?

That's where CAN drivers become interresting : we can use them on a "simili-RS485" bus : if two devices speak at the same time, the device speaking louder (understand, placing higher bits first...) will be overwriting what second device is saying. So, the first device (the one that is speaking "louder") will not see any problem, it will continue speaking, and the second one (which will see that his bits are not heard) will stop speaking, and try again a few milliseconds later !

I agree with @kimot : the RS485 bus is not designed to have many masters on the same bus.
So, when you want to use RS485, you have 2 choices :

• The master polls the slaves to ask them if they have something to say (you give them the "right" to talk)
• Each device tries to talk when needed, with the risk of collision, and the message could not be correctly transmitted.

Using a MCP2551 driver (without a MCP2515 controller) allows to use the benefits of CAN bus : If 2 masters talk at the same time, one of them will "see" that one of the bit he tried to push on the bus has been overwritten by another one, and will have to try again a few times later. This is not collision avoidance, but collision detection.
Of course, since we use only a CAN driver and not a controller, we must do the checks via software (listen to what is being heard as we're talking).

I have some arduinos laying around, and some MCP2551. I must do some tests.

I'm also looking for a wired network...
I think, as @kimot said, that we cannot rely on "listen what I just said", since this just ensure that the message we did wanted to say was correctly put on the line, but it doesn't ensure us that it was correctly received !
Perhaps we should use collision AVOIDANCE (be sure that the line is free before speaking), but ALSO use ACKing system.

I think the \n or the ; should be encoded differently.
In facts, the protocol says that the message is finished by a \n . So, the first one which will be encountered will mark the end of the message.

So to be concise :
0;3;0;9;1;foo\nbar\n will be understood as 0;3;0;9;1;foo\n

For the ; I think it's not a problem ? Haven't tried yet.

I also see that message when I startup my gateway.
It seems to be a log message : the gateway just ask the controller to log "hey, I'm ready !"

Nice card !

It seems that you power your arduino mini with 2x1.5V ?
Is that working well ?
Do you sleep your adruino ?
How many life does last the batteries ?