Thanks alot!

Both links clear all my concerns.
Looks like I have all the features I had in mind for my future deployment.

Thanks,
Alex

For now I got all the answers and it was fast, so I'm more than happy.
Thank you and others for that.

Hope to contribute some code and experience when I'll get to the actual implementations.
For now I'll let my customers know about the site with the community and the work that was done so far.

Thanks,
Alex

For now I got all the answers and it was fast, so I'm more than happy.
Thank you and others for that.

Hope to contribute some code and experience when I'll get to the actual implementations.
For now I'll let my customers know about the site with the community and the work that was done so far.

Thanks,
Alex

Hi,

I've read it again... now I think I get it better.

Your explanation for point 2 logic makes sense.
Thanks for explaining that.

Regards,
Alex

Didn't expect to see another answer

Do you have any statistics for active users of the library?
Just curious how popular it is...
If you do a poll, it will be interesting to know how many are using the development branch (beta testers).

I was thinking about node-to-node communication a bit more and see few problems with it.
Will appreciate if someone could answer if those are real problems or maybe the implementation covers some of them:

Destination node-id is ok for routing the packets, but it's not enough.
Without child-sensor-id it will not be possible to address a specific port on an actuator.
Is there a way to send child-node-id in the packet?

As I understand, gateways/repeaters use the destination node-id along with their internal routing table to know where to forward the packet to.
If destination node-id is not a gateway id, the packet will be forwarded to the destination node, but will never reach the controller for logging the event. Am I right?
Assuming there is only gateway in the deployment, is there an easy way to push the packet to the controller for node-to-node packets as well?

Even if there is a solution for point 2 issue, the serial protocol don't pass the destination node-id (and destination-child-node-id) to the controller, so the controller won't know if it should answer or only log the event.
Maybe that could be solved by some rules in the controller, just to log the event as with temperature sensor for example...
The rules might be a solution, but without destination-child-id the controller won't be able to log properly events for smart nodes with multiple children since it still don't have that information. The example I can think of is a multi button switch that controls 2 different window shutters that are controlled by single actuator with multiple child-sensor-ids and the switch node decides what shutter should move based on its own logic (light direction for example).

Thanks,
Alex

Can live without it for now.
I've found the RS485 HAL only in the development branch.
Does that mean I'll always have to use non-stable versions?

What is your release and testing methodology by the way?

Thanks,
Alex

@gohan said in Communication technology you'd use for new deployment:

For image capture, I think IP cameras are a proven reliable technology so far.

Agree. That's a plan B for me.
I have a building intercome with LCD screen next to the entry door and hope to find a way to hack it, so I could display there the pictures that will be captured from the door camera.
If it won't go, will try to use my own monitor and display there the building entry camera when someone calls my appartment from the lobby.

Hope my building manager is not in that forum

Thanks alot!

Both links clear all my concerns.
Looks like I have all the features I had in mind for my future deployment.

Thanks,
Alex

@wallyllama said in Communication technology you'd use for new deployment:

My plan is to use rs-485, but my experience is all still theoretical so confirm anything I say here.

Higher speed and longer distance require better wiring, but a house should be well inside the limit even, if you snake a single wire all the way around the house. According to this link you may even be able to get away with some star topology
https://arduino-info.wikispaces.com/RS485Info

It seems the biggest issues on this forum with rs485 are collisions, and correct use of terminating and pull up/down resistors on the line. There is a lot of information and solutions to these out on the net. A separate ground wire is often one of the recomendations, but the inexpensive modules i have only have A and B, so im not sure exactly how the ground is wired in.

My thinking is I will divide my house into zones, with a separate rs-485 net for each, reducing length, number of devices(collisions), and possibly less grounding issues.

Ive heard the max485 chip isnt the best, so possibly buying better modules would be helpful. Maybe rs-422 or CAN might be other options.

This website talk about tens of meters wires to allow star configuration, I don't think it will be enough for any home
installation.
I found a discussion with a TI engineer about star topology and he strongly rejected the idea and explained it from the aspect of too many terminator resistors will lower too much the resistance between the lines (resistors in parallel), so there will be much higher current draw from the drivers, which will eventually fail from too much load.

I plan to run a 2-core wire for power and 2 twisted pais for data (telephone cable, only one pair will be used for RS485). Thinking to use the additional wires as interrupts indicators, so all the devices and the gateway on the same trunk will know if there is something to say on the other end.
Since RS485 are half-duplex, the gateway will have to ask every node what does it have to say, that way there should not be any collisions. The interrupt lines could save the questioning round if all the nodes are sleeping and there is nothing to transmit.

For now, if I go with RS485, I'd like to try multiplexing the trunks using 2 analog MUXes (one for every data line), so the gateway could address every trunk separately. The interrupt lines could help to decide what trunks to check every time.
If MUX won't work, adding few more RS485 chips are also possible, those are pretty cheap.

@gohan said in Communication technology you'd use for new deployment:

Rs485 is good if you do cabling correctly. I prefer cables too if it's possible (like security sensors) but I don't dislike wireless for other uses. I don't know how much data you will be transferring from your devices that you need those high speed, but for normal home automation slow speeds should be enough.

I agree, slow speeds are enough for the automation. KNX is only 9600bps.
I guess it's like the hard disk size, the more you have, the more you'll use.
My plans include image/video capturing from entry door camera to show it on the intercom LCD and record it in the controller so I could check later who came to visit when I wasn't at home.

I belive I'll have to use wireless in places where I didn't think I'll need the cabling, so I don't rule it out completely.

Thanks,
Alex

So MySensors only implements wireless sensors network?
I saw some RS485 mentioning in the configuration file.
Does that mean RS485 is supported as well? Or maybe any other Serial based connection?

Thanks.