ESP8266 Community Forum

- Thu Feb 23, 2017 8:35 pm #62947 Thanks for the responses. Allow me to inject a little clarity here.

The switch panels I described are going to be wall mounted. I see not I did not mention that in my original post. They are going to be about the same size as a standard single gang wall switch plate. I am going to fab these most likely out of wood. Switches are momentary "tact" switches. Not looking to have another "remote" laying around. There are many smartphone apps I could use and I may incorporate that into this also but that isn't the focus at this time.

Using an 8 way relay board won't work because not all lights are separate circuits. That would require a lot of rewiring and tearing up ceilings and walls. Most of the lights are only 2 circuits. I want separate control over about 8 of them.

As for using many ESP-01's, why not? I can put it, a power regulator, the mosfet relay and whatever else is necessary on a very small circuit board for less than the cost of the single wifi relay mentioned. It would also fit in the light fixture too. The songle relay mentioned will not fit into the fixture. Plus I already have all the components to do it.

The reasons I like the mosfet relay is it only takes a brief ground to toggle it. Its a logic level trigger so it can be connected direct to the GPIO. It would require the exact same software command to turn on or off. Plus I can also use a manual switch on the light to do the same thing. Plus the added benefit is I already have them. This is why I would like to use the second GPIO on the -01 module to signal the LEDs on the switch panels to toggle on and off with the relay.

So we have 2 NodeMcu's and a fist full of ESP-01's. Button press on NodeMcu sends the same signal command each time to the appropriate -01 module. Hopefully the relay triggers and then the -01 module senses the change on the other GPIO and sends command to NodeMcu (both) to update the indicator LED next to the button pressed. In this way the LEDs will get updated on the switch panels even if light is switched on manually at the light itself.

Now that I'm thinking about it, seems like it would also be nice to have an "all" button too. One press triggers all on or off.

On the hardware side of the GPIO it may require pull up and or down resistors. Probably "up" on the trigger because ground signal triggers. On the sense side I guess pull "down". I can run the 12v signal through a regulator to 3.3v to trigger the GPIO. It seems to me I read somewhere that the modules have internal pull up/down resistors?

Hope this helps. I still have that beer n pizza $$ for any help on the code. Thanks.

"The glass is twice as big as it needs to be".

- Thu Feb 23, 2017 11:51 pm #62951 With the 5 or 6 different RVs I've had I was able to fit extras into the ceiling void next to the lights rather than in the lights.

As far as the software is concerned...

In theory Esp_Basic should be capable of doing what you want to do, but in practice it starts having problems when things start getting complicated. It is better at concentrating on doing something well, rather than multi-tasking on complicated interactions.

You would probably be fine using udp for multiple remote lighting nodes with local activation plus abilty to be controlled from one or more master control panels and sending back their status using udpreply.

But udp uses 'connectionless' broadcasts that doesn't have any handshaking, therefore the 'sender' is unaware whether its broadcasted messages are ever received or not.

All nodes can be senders and/or receivers, so all need the same level of fault-tolerance and error-checking/correction.

The udpreply instruction could be used to return an acknowledgement receipt back to the sender if wished - which at first glance seems handy to use for error-checking and correction - but actually opens up a big can of worms which must be dealt with.

The sender needs to remember a copy of each sent message in a queue, for re-transmission if required.

When a receiver acknowledges receipt of a message, the sender must parse its queue of sent messages for the correct acknowledged message and delete it from the queue. There is no current efficient way of parsing such a queue and removing a matching entry, and I have been unable to add the required complexity without causing Esp_Basic to become unreliable.

In addition, each sender requires a timer so it can periodically parse its sent queue for un-acknowledged messages and periodically try to re-transmit them again up to a specified number of retries.

The problem I've had is that Esp_Basic suffers increasing problems with increasing complexity, to the point that the script becomes unstable and unusable long before all the required functionality is included. So I have been forced to abandon my udp fault-tolerance attempts until either mmiscool can fix the problems (which doesn't seem too hopeful at the moment), or a more efficient parser and string handling instructions become available (which also doesn't seem very likely). It's a great shame, because Esp_Basic is great in so many other ways... but it is not as great as it needs to be for practical node to node interactions, and possibly may never be.

If you were prepared to compromise on fault-tolerance to reduce the size of the script, you could avoid the need for error-checking and correction by just ensuring that all messages were re-transmitted more than once with a small variable delay in between - this would increase the chances of the message still getting through even though some transmits may have failed.

Where to get modules?

https://www.banggood.com/custlink/KvGGhGF4wG

- Fri Feb 24, 2017 8:03 pm #62992 Wow. Not trying to get overly complex here. It's not mission critical, do or die stuff here. We are just trying to turn on or off some light bulbs. Seems weird to me that this needs to be super complex code.

I was looking at the example page for MSG URL and was thinking that should suffice for what I want to do. Can a MSG URL message be generated from a button push? Also can the response back be another MSG URL message? Seems like that would do if it can be made to.

https://www.esp8266basic.com/msg-url-advanced.html

"The glass is twice as big as it needs to be".

- Wed Mar 01, 2017 6:17 pm #63207 The following is a simple program that can be run on 2 esps.

It shows how to send a msg from one esp to another and how to read that msg.

All esps on the network will receive the msg so you will just have to identify in the msg the intended target and use a bit of logic in the udp branch to make it do what you want.

As for making the physical buttons you can use interupts for those pins and have branches set up tosend different msgs.

Code: Select alludpbegin 62102
udpbranch [udp.received]
textbox mymsg
button "Send", [sendmymsg]
wait




[udp.received]
let rec = udpread()
let rem = udpremote()
print "Message received " & rec & " from" & rem
udpreply "OK"
return



[sendmymsg]
udpwrite "255.255.255.255", 62102, mymsg
wait

Serial terminal in the chrome browser see https://serialTerminal.com

http://esp8266basic.com
A BASIC interpreter for your ESP

Working now on Autodrop3d. A 3d printer with automatic part ejection system. https://autodrop3d.com