- Wed Aug 10, 2016 4:45 pm
#52670
Hi Juan - yes, by default the udp messages are 'shouts', so if more than 1 node tries transmitting at any one time they will probably shout over the top of each other and drown themselves out.
As I said to joeman2116, I had plans for senders to request and wait for acknowledgements and responses (requested by including a "!" or "?" in the message) which would have enabled them to keep re-transmitting and looking for appropriate response up to a 'number of retries' before giving up and flagging a 'node not responding' error. I intended the senders to stagger their re-transmissions by delaying them based on their ip address (ie: .100 would re-transmit before .200 tried to). Things were brought to a halt when V3 came out. I tried working through the code to convert it to V3 a couple of times, but each time I got to a point where there were no more error messages but the browser stayed blank... and I had nowhere to go after that, so moved on.
So V3 brought things to a halt for me, but I still have the need to try to replace my aging and unsupported security automation system with a future-proof system at some point. Unfortunately I must develop the replacement system myself using readily available hardware and software, so it is very much a matter of getting the time and opportunity.
My current computer-plus-dedicated-hardware system reads a variety of wired PIRs and magnetic door sensors and beam-break detectors, and announces appropriate recorded voice messages via conveniently located amplified speakers so we can hear alerts at strategic locations (where we can usually glance up at a cctv monitor).
I have now got working proofs-of-concept of the 3 main types of nodes I will need, which are...
1. Relay responder,
2. A PIR sender (which could be activated by any of the other sensors instead).
3. As of today I finally have a Voice Announcer node speaking approriate messages.
So no doubt I will keep trying to press on towards a complete working substitute system, but I'm still not finished with the Voice Announcer yet (different message sets to do, etc). And then I need to develop a 'System Controller' node to co-ordinate all the incoming alerts and organise all outgoing responses. It will needs stuff like individual 'no-retrigger' delays for each of the sensors to prevent them continously reporting repeat triggers of PIRs etc (a visitor should be announced every few minutes until greeted, but things like a mailbox delivery only need to announce hourly).
If I get to that point, the next step would probably be a complete V3-compatable rewrite of everything (exhausting just thinking about it), and at that pount I would include the required EayNet acknowledgement and retry mechanisms etc.
I've set up a non-internet router specifically just for my Easynet system in order to maximise security and minimise non-EasyNet udp traffic, with thoughts of a future dedicated 'bridging' node to provide external access eventually (probably just a little html server node on the main network to relay authorised commands or requests via a serially attached EastNet node).
I believe dhcp requests use udp broadcasts, but once my nodes are up there is nothing else other than my dev computer causing any other unwanted network traffic. So it's worth pointing out that's likely to be a very different environment to the usual busy wifi network with other devices and traffic on it.
As I said to joeman2116, I had plans for senders to request and wait for acknowledgements and responses (requested by including a "!" or "?" in the message) which would have enabled them to keep re-transmitting and looking for appropriate response up to a 'number of retries' before giving up and flagging a 'node not responding' error. I intended the senders to stagger their re-transmissions by delaying them based on their ip address (ie: .100 would re-transmit before .200 tried to). Things were brought to a halt when V3 came out. I tried working through the code to convert it to V3 a couple of times, but each time I got to a point where there were no more error messages but the browser stayed blank... and I had nowhere to go after that, so moved on.
So V3 brought things to a halt for me, but I still have the need to try to replace my aging and unsupported security automation system with a future-proof system at some point. Unfortunately I must develop the replacement system myself using readily available hardware and software, so it is very much a matter of getting the time and opportunity.
My current computer-plus-dedicated-hardware system reads a variety of wired PIRs and magnetic door sensors and beam-break detectors, and announces appropriate recorded voice messages via conveniently located amplified speakers so we can hear alerts at strategic locations (where we can usually glance up at a cctv monitor).
I have now got working proofs-of-concept of the 3 main types of nodes I will need, which are...
1. Relay responder,
2. A PIR sender (which could be activated by any of the other sensors instead).
3. As of today I finally have a Voice Announcer node speaking approriate messages.
So no doubt I will keep trying to press on towards a complete working substitute system, but I'm still not finished with the Voice Announcer yet (different message sets to do, etc). And then I need to develop a 'System Controller' node to co-ordinate all the incoming alerts and organise all outgoing responses. It will needs stuff like individual 'no-retrigger' delays for each of the sensors to prevent them continously reporting repeat triggers of PIRs etc (a visitor should be announced every few minutes until greeted, but things like a mailbox delivery only need to announce hourly).
If I get to that point, the next step would probably be a complete V3-compatable rewrite of everything (exhausting just thinking about it), and at that pount I would include the required EayNet acknowledgement and retry mechanisms etc.
I've set up a non-internet router specifically just for my Easynet system in order to maximise security and minimise non-EasyNet udp traffic, with thoughts of a future dedicated 'bridging' node to provide external access eventually (probably just a little html server node on the main network to relay authorised commands or requests via a serially attached EastNet node).
I believe dhcp requests use udp broadcasts, but once my nodes are up there is nothing else other than my dev computer causing any other unwanted network traffic. So it's worth pointing out that's likely to be a very different environment to the usual busy wifi network with other devices and traffic on it.
