(Appropriate snipping makes Usenet much nicer!)
It's 10 Mbps Ethernet. You need something that has an Ethernet MAC.
You'll need a few dollars for the MCU, and I think the PHY's are about three dollars last I looked. Expect prices to come down as popularity and competition increases. Ethernet on an MCU is not expensive these days, but it's still a good deal more than RS-485.
Yes.
Yes.
You can be a little loser if you can impose some rules on the messages you send (like avoiding collisions).
I wouldn't want to rely on CAN for anything like that distance/speed combination - my experience is not as good. However, there are all kinds of details involved such as the type of cable, grounding, driver power, EMC protection, etc.
Agreed.
There are lots of ways to evaluate complexity.
Your hardware costs (for the "slaves") will likely increase. You will also likely incur the cost of a switch -- which may also impact deployment logistics and costs (e.g., if you were hoping to daisy chain from one node to the next NEARBY node, a switch forces duplication of cable).
You'll need an MCU with a MAC and, hopefully, external PHY interface. Then, the actual PHY, itself.
Your software complexity will likely increase at the driver level. Instead of a Linux "master" and /ad hoc/ slaves, you will likely run something *like* Linux on the slaves, as well (to benefit from the network stack).
OTOH, the whole polling issue becomes moot. It's just as easy (and reliable/scalable) to have each "slave" act as initiator when *it* wants to talk to the "master" (let's call it a "controller" and them, "motes")
Depending on the power requirements of your motes, you may be able to source power centrally (from the switch) and thus eliminate the need for locally sourced power at each mote.
[It is incredibly liberating to be able to place a mote anywhere that is convenient -- instead of having to make considerations for how you'll access power. E.g., I have devices up at ceiling level, inside walls, *above* the ceiling, etc. I have neither the unsightliness of "power supplies" scattered all around -- nor the regulatory issues (e.g., hidden boxes). Likewise, one less aspect of an attack surface]You may end up rethinking the application's feature set. E.g., perhaps you incorporate provisions for two-way audio (intercom) between each mote and ????. Or, a fingerprint sensor -- with the authentication performed by transferring the image to the controller at the enhanced throughput available.
With (likely) more smarts at a mote, there are other options available to enhance reliability. I.e., what happens when your controller is not accessible (perhaps the network has been subverted or the controller has crashed or the system is in overload)?
If your focus is exclusively on the (recurring) cost of comms, you will end up chasing an /ad hoc/ bastardization of *some* protocol to "make it work". You should, instead (IMO) think about what you can do with a different capability suite.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.