Questions with regards to ESP8266 Basic and hardware interfacing and control via Basic commands

Moderator: Mmiscool

User avatar
By Electroguard
#61182
I'm thinking it might be something with the Wget function (possibly) ..and wondered if maybe there was another way of receiving the returned message.

You could try returning your messages using udp, even if just to prove the point.

The transmitter would need to include something like...
Code: Select alludpport = 5001   '(or whatever your preferred port number)
targetIP = "192.168.1.17"   '(or whatever your required destination IP)
myrtnmsg = "whatever message you wish to send"
udpwrite targetIP, udpport, myrtnmsg


The receiver would need to set up a udp listening port and branch, something like...

Code: Select alludpport = 5001
udpbegin udpport   'sets up a udp port to listen for incomming messages
udpbranch [UDPMSG]  'branch to handle incoming messages
wait

[UDPMSG]
mypayload = udpread()   'reads incoming msg into your designated variable
if mypayload = "this" then gosub [DoThis] else gosub [DoThat]
return

If both nodes contain both the appropriate transmit and receive codes they can send and receive messages with each other just using udp.


I should point out that you have a very long line which may give problems...
if status = "ON" or status = "OFF" then myrtnmsg="MSG OK" else myrtnmsg="MSG ERROR" 'SET RETURN MSG TO "MSG OK" IF "ON" OR "OFF" RECEIVED, "ERROR" IF ANYTHING ELSE

Lines that don't contain a carraige return before the end of the edit line will wrap over to the next line (usually just comments), which Esp_Basic used to assume was the beginning of a new line to be interpreted. It used to cause many weird errors until I twigged it and took pains to ensured my lines have never wrapped around since.
User avatar
By Boxey
#61247 Thank you for the reply Electroguard :)

I hadn't thought about using UDP, for some unknown reason I had it in my head that it was going to be complicated, but looking at the snippits of code it doesn't seem too different from using "wget" and retrieving messages.

I'm a bit stuck with trying to make it do what I want though. I've searched the forum and found "cicciocb's" post in the New UDP Commands Example, which has code for three ESP's which each reply to the Windows "controller" program with their ID and then each pick up their individual messages: viewtopic.php?f=40&t=9330

I've tested this on 3 ESP's and it seems to work fine. However, I'm a bit at a loss on how I would use an ESP to be the "controller" (instead of the Windows program) and get it to "find" the slave ESP's? ...and how (if it's possible) I could make the slaves be able to talk to the controller too (at any time they want.. not just when their doing a udp reply)?


It's probably easier for me to explain what I'm trying to do, and see if it's possible.....

Imagine I have a long tree lined driveway, and spaced out along the driveway are 6 individual lights. The lights all have PIR's in them and come on when walking past, and at the end of the drive is a gate with a infrared break beam switch.

At the moment they are all hard wired to a panel of LED's in the house, which shows if the gate has been opened and if any of the PIR's have been triggered. It's a messy system, with lots of cable, and not very useful as you would have to stand in front of it all the time to see if anybody was there.

I'm about to get some new solar powered lights with PIR's built in, and would like to separate the light and PIR signals, and put an ESP in each unit, which would tell me if the PIR had been triggered, and also let me turn each light on individually if I wanted to.

Ideally I would have one ESP in the house, which would show which PIR had been triggered, and if I wanted to I could then turn on that light, or a couple of lights around it, to see what was there.


In simple terms ... I guess I need a Slave ESP which can send and receive messages, and Master ESP that can send and receive messages ..but so far I can only send to the slave and get a msg reply (so I can turn a light on) .. but I can't figure out how to get the slave to send a msg to the master when the PIR is triggered. :?

Any help would be appreciated ..or a link to any code that does something similar that I can tear apart and possibly make work. :)
User avatar
By forlotto
#61250 That helps quite a bit!

Have you thought of looking at ready made solutions like KUNA for example?

As far as making some you you could without a problem you pretty much understand a good portion of this .

Use an interrupt to trigger when on.

if interrupt happens then wget to pull your led on which I believe is D4 or D5 errr don't recall off the top of my head now but when the light goes high you can also trigger a routine that will play a sound.

To be truthful electrogaurd worked hard on a framework that does almost exactly what you talk about not that you have to use UDP wget works just as well really if you use it correctly.

You could also integrate with thingspeak and I believe with thingspeak you may be able to get a notification on your phone or twitter or something along that order.

What are your plans a message? What good is a message you might as well stand by your drive way if you have to sit in front of a screen and watch for a message right? So the kicker is what do you plan to do beyond the message?

If you want Dirt Dirt Cheap Harbor Frieght sells a PIR with a Buzzer to alert you when someone is near. It actually works pretty good you could likely hack it to suit your needs and hook up a solar charger to it to keep rechargeable batteries in it topped off. I thought of doing this in my own driveway I have seen these things the only thing I do not like is batteries who likes to pop batteries out of these things. Heck I even have This solar Keyboard because it is wireless and keeps the battery charged from your house lighting awesome idea awesome use of solar I have two of them have had them for years already so yeah I understand your want for going solar but you could use you existing PIR and a battery with DC to DC Converters to run everything really.

Side thought for a product for TV Makers would not cost much at all:
Maybe some day they will have a built in warning message thing in your TV that we can link to and overlay whatever is on the television as a warning message or even get the TV to come out of sleep and display the warning message. When you think about it this would be huge allow it to play a sound or be silent with a custom warning message.

But what you are going to do with your warning how are you going to be alerted this is the important thing!
User avatar
By Electroguard
#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.