- Fri Jan 20, 2017 10:11 am
#61272
Well you might be in luck... it depends how confident you feel about hacking someone elses thought processes.
I had been working on something which is about 90% done until it kept maxxing out the memory. It's much larger than necessary because my original intention was to publish a comprehensive and versatile generic networking program that was simple enough for anyone to use for almost anything. But I feel I've been pointlessly struggling into a headwind far too long, therefore changed priorities will probably cause me to just modify things for my own specific purposes to greatly reduce size and complexity.
You're welcome to do similar if you wish, and I'm sure it could allow you to do everything you need, plus much more. Everything has been working at some point or other except for the unfinished message retries facility for fault-tolerance and reliability, but that probably won't matter for your needs anyway. Things will be a bit messed up at the moment due to hacking stuff out while trying to pinpoint the latest weird out-of-memory corruption problems, but I've kept all the previous stages to refer back to if required.
Much of it is overkill which can be removed anyway. For instance, I provided a hardware 'button mode' option whereby gpio00 can be selected to act as a PIR sensor trigger input, or a beam-break or magnetic contact trigger input, or a 'flip' switch for home-automation lighting etc, or a momentary button for user input to toggle its local relay etc. It even has a 'multi-mode' option whereby a short press can do one thing (perhaps toggle the local relay) but a longer press can do something else (such as blink out the IP address on local LED). So by removing all the unwanted options and just hard-coding for your requirements, you could recover ample memory.
Similarly I allowed for automatic selection and handling of messages on multiple input or output streams - eg: udp for broadcast network messaging, serial2 for connection to any other hardware platform messaging, and serial(1) reserved for serial monitor test and dev use... so anything not needed can be removed to simplify matters.
As far as addressing goes, my idea behind the EasyNet concept was that each node is given an appropriate unique node name and list of local instructions for it to recognise and action as appropriate. All messages are udp broadcast to all nodes on the subnet, and it is down to the receiving nodes to check if an incoming message mentions their local name or address, and if so, to take any appropriate action when necessary. For instance, one such command that all nodes recognise by default is RELAY TOGGLE, allowing nodes to control other nodes by broadcasting simple text messages such as "Node5 RELAY TOGGLE" or "BedroomLamp Toggle" or "192.168.4.17 Relay Toggle".
In the case of your driveway example, lets call the beam-break node GATE1, and each of the Solar PIRs DRIVE1 to DRIVE6, and we'll call the in-house monitor HOUSE1. What follows is just my interpretation of my needs in your situations, so of course may need adjusting to your own actual requirements. For instance, I would have a PIR sensor outside of the gate beam-break just to bring attention to possible snoopers looking for opportunity, Also, although EasyNet program has facility to turn local or remote remote relays ON or OFF, or TOGGLE them, I would prefer to use it's integral CYCLE function, whereby they can be turned ON for a preset duration then will automatically turn back OFF again.
So the first system requirement would be that all triggered external nodes turn on their local LEDS at night for a fixed duration, perhaps 1 or 2 minutes.
Additionally, each of the triggered external nodes would broadcast a udp message such as "HOUSE1 DRIVE(n) triggered". The HOUSE1 node would recognise the messages aimed for it and light the appropriate leds on your panel, plus perhaps speak a corresponding pre-recorded voice message via a serial to MP3 module (which I've already done), or at least give some audible bell or ding dong. In my case, I would also cause PIR triggers to switch the CCTV monitor to the most appropriate CCTV camera - and this would be applied to nodes covering all the property, not just the drive. I have a beam-break across the main entrance gateway, and another across the front of my metal workshop 'hanger', there are PIRs on the gateposts and in the hanger and other buildings, plus some external solar PIRs, and there are magnetic contacts on the hanger and shed doors. Anything that gets triggered causes a corresponding recorded mp3 voice announcement, ie: 'Gate 1 visitor', 'Shed Door', 'Hanger Beam', 'Workshop' etc, but like you I am still using an old hard-wired system at the moment. EasyNet is intended to replace everything, and has resulted in separate successful proofs of concept for all individual functionality, but so far not yet implemented because it doesn't have a usable multi-message queuing system for effective retries of un-acknowledged messages.
If you want security as well as night-time convenience you will need to hack the solar PIRs so that they trigger during the day (stick some insulating tape over the LDRs) and have an Esp-controlled relay able to supply them power to the LEDs even without the PIR being triggered.
Inside the house you could obviously control HOUSE1 node web buttons via mobile phone to turn on/off/timed external solar lights when needed, but I would also prefer the quick simplicity of reaching for an IR remote controller... it only needs 1 normally unused button to turn all the lights on for a preset duration - the HOUSE1 node would be programmed to send "DRIVE6 CycleON 2 MINS"... "DRIVE1 CycleON 2 MINS"," GATE1 CycleON 2 MINS", causing all lights to switch on for 2 minutes then switch off.
It could be even simpler by using EasyNet's GroupName facility and asigning the group name DRIVE to all external solar nodes... allowing all nodes belonging to the group DRIVE to be controlled with just one "DRIVE RELAY CYCLEON 2MINS" message. In practice the 2MINS would only be necessary if wishing to over-ride the pre-defined default duration.
Or if you wanted to get fancy you could cause the lights to sequence on and off to show the way. And don't forget that you could easily have more than one HOUSE1 monitor if required, allowing audible and/or visible alerts anywhere they may be useful.
This probably isn't the right place for this, so let me know if you wish to give it a go, then I'll try to tidy things up a bit and post it in it's own thread.