ESP8266 Community Forum

- Wed May 04, 2016 9:06 am #46870 Thanks forlotto, but you would need to run the script to be able to understand what I was talking about - and I knew you hadn't because you mentioned scrolling down it, and there isn't any scrolling if it is run because all that documentation is displayed in screenful pages, each starting with cls, and each sharing a common button footer for navigation.

How can I say this...

You are a mechanic that has built your own aeroplane, I'm a mechanic that has built my own mini-sub - you cannot know from your own experiences what my specific requirements and restrictions are without taking a deep breath and diving in to give mine a try yourself, cos it aint nothing like what you've been used to. Same goes for me and your stuff.
Don't be frightened that it's big, cos it won't bite, and it doesn't require any special hardware to run or to demo the networking features... and as explained in the the self-contained docs, most network features can be invoked locally by specifying name as LOCAL in the broadcast msg window. If you ever have any intention of seeing what the recent udp networking is capable of - and it's easy simplicity - then why not download cicciocb's ideal free little udp_debugger utility and interact with my script as a network node. It's easy-peasy, and you would probably never look back, cos with so many power features available now, networking ESP_Basic modules is going to be the future - trust me - even if just to take best advantage of the most recent IR functionality.

It's pointless me trying to explain everything if you haven't run it and therefore can't relate to what I am going on about ... but having committed to respond, I must continue and complete.

On the browser edit page there are the top [ VARS ] [ EDIT ] [ RUN ] [ SETTINGS ] [ FILE MANAGER ] option links.
On my home page the node description is able to list the nodes various built-in instructions, ie: MP3Player [Play] [Pause] [Next] [Previous] [Vup] [Vdown], so it would have been a nice touch to have those commands clickable similar to the browsers option links. It's only creating a text hyperlink branch instead of a button branch so I don't think it's likely to be difficult, and I suspect it may already be possible but undocumented... cos of the fact that it is already being used in the browser window and may have been one of the very first features created!

It's not currently possible to have a scroll_window to display incoming udp msg history in the same way that ciccciocb's udb_debug util can do.

Bearing in mind what the udp network demonstrator is trying to demonstrate (use multiple dhcp nodes on a wifi subnet) it would be very convenient for each newly added node to be able to locally flash out (blink) it's allocated dhcp node address at bootup. And the script is capable of doing that - but not if I wish the node to send a 'be patient' confidence msg back to the browser first, while still doing it's local flashing.
Same if doing a shutdown or reboot, I don't think it is possible to acknowledge the request AND then instigate the event.

It could ease the initial networking situation if it was possible to have two AP nodes at specified addresses for testing interconnectivity without needing to worry about routers and dhcp servers etc, but I fear your comments may have prevented chances of that ever happening. You raised a potential objection because of the possibility of cross-connection problems due to having multiple wifi interfaces on one computer. Really? I must be missing something... cos that just seems to be pouring on muddy water to obscure a relatively clear situation - surely it's a more realistic scenario to have one computer with one wifi interface able to connect to multiple AP's, than to have one computer with multiple wifi interfaces connecting to only one possible AP just to ensure no chance of a cock-up! I hope I've missed something relevent with that objection, else it may have pointlessly obscured a potentially useful idea from ever seeing the light of day.

Anyway, none of the above are show-stoppers, but all could offer some useful enhanced functionality if they were possible.

Some of the following are more subversive - first and foremost being the zombie parser getting it's nickers in a twist and then confusing it's vars and branches.
Maybe it's a script bug that brings on the madness, but in this case I don't think so - the web buttons work fine by themselves to toggle the relay (led) and flash the last digits of the ip address on the blue led etc, and all of the doc pages work fine and reliably, but if you flick back and forth between buttons and docs, then quickly the function buttons exhibit branch errors and incorrectly branch to doc pages.

Every html text word and button and other web component on every line has only 1 space character between each, because all other spaces and tab characters are ignored, eg: html "X " & chr(9) & " " & chr(9) & " X" results in "X X", preventing adding any white space or neat tabulations.
Everything still works ok, but it can look like a pigs ear, and doesn't offer professional presentation.

[branch] ' is one of the most useful places for having explanatory comments, but adding comments after a branch declaration causes a branch error.

Interrupt is an unhelpful jobs-worth... onboard gpio00 buttons and links that worked perfectly well for entering flashing mode and preventing autorun are later snubbed and ignored cos of not wearing the previously unnecessary pullup resistor 'tie' that custom now dictates, and which now causes a precarious mess out of any neat self-contained dev modules that must accept the unnecessary clutter forced on them.

The ip() function has a history of mental illness and still requires a bit more treatment before it's safe to let loose on an unsuspecting public. I can deal with it, and you can deal with it, but something that returns 192.168.0.39 when you are connected to 192.168.4.1 on a newly reformatted and reflashed ESP just aint right in the head, and it doesn't do other peoples heads much good either.

I'd hope the two wizards know by now that I'm not a negative complainer trying to find fixes for personal problems... it's simply the best and only way I know for an ordinary 'muggle' to try to help progress ESP_Basic - by spotlighting areas that perhaps the wizards may be able to improve upon but which they may otherwise not have looked at. That's the main reason for the 'bloatware' script being still like it is, and is likely to remain so until things like the zombie parser are under control and offer sufficient stability for things to be progressed.

So thanks for taking the time and effort to offer your help and suggestions for getting round the script problems, but hopefully you can now see that it's currently more of an imperfect testbed and yardstick for assessing improvements and benefits of new releases. A21 is still not quite there yet, but almost, and as soon as that stable threshold of functionality is reached then I intend to concentrate on doing some smaller practical individual network projects from it, which I hope will soon be added to by the more experienced people such as yourself.
At the moment my own interests lay more towards security and control, but I am really looking forward to seeing things like a mix 'n' match weather station evolve (I'm sure it's inevitable) with various add-on network nodes offering all sorts of increased functionality, and who knows what other things people will dream up and be able to achieve with the comprehensive ESP_Basic toolkit that is now becoming available to them.

Robin.

Where to get modules?

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

- Thu May 05, 2016 12:21 am #46908 Well thanks for sharing this Robin I am sure it will be helpful for the development a few things you have brought up already are and now that they are aware of these things this is good.

- Comments in message branch don't work
- Spacing or tabbing while printing does not work to keep things looking neat
- We need to hire the women from resident evil to get rid of zombies in the parser hrmmm may be expensive :P
- More than one connection should be possible via UDP there is an actual hardware limit on connections for the esp8266 if I recall correctly the issue is that there can be conflict if connected in AP mode and STATION mode at the same time but if using UDP I am assuming all units will be in station mode to do communications so it should not be a problem.

Finally I don't fear big it is just to has over a crap ton of code is not really likely for anyone to jump right in which is why clear concise and to the point helps there are many things in the works for a couple of guys working on this and it is open source I am unsure what your coding skills are but they seem to be fairly decent and this thing is open source feel free to jump in and contribute I'm sure they may like the extra help ... If not though I understand it is hashing over a crap ton of code many of us are not well versed enough to do such a thing in a quick fashion that jives with our life style and sometimes we are even lazy yes we are all lazy to some degree. I will say though I get about 5 hours of sleep a night tops and seem to always be working on something until then lol once in a while I peter out like any normal person would in fact do.

I thank you for pointing things out it does help things rather than hurt them I have pointed out things as well along the way some personal some not so personal and some grammar nazi stuff for documentation as well :P That is all we can do but this post at least helped point some possible issues out.

This is the constant evolution.

Short and to the point possibly highlighting the issues is always a good thing if they can fix it they will I'm sure if not well then we either have to wait or find workarounds depending if it is hardware limitations or software issues that can be resolved as we all know there are only 24 hours in a day and for the averge person 1/3rd of it is spent sleeping 1/3rd is spent earning money and 1/3rd of it is left to take care of everything personal hoping that you have time for hobbies and possibly trying to earn or save extra money by doing other work. Kind of puts things into perspective for me and I'm likely stating the obvious here for someone like yourself but I'm sure when and where possible now that the issues are known they will be ironed out.

These are all excellent points in your previous post there was a lot of information that should be helpful in the hunt I guess that is what I was reaching for.

Thanks.

Helpful? Donate To help support Mike http://www.esp8266basic.com click the donate button lets keep this project going and hope we can get the ESP32 in the mix. BEGINNERS GUIDE HERE http://www.esp8266.com/viewtopic.php?f=40&t=6732

Where I buy my ESP8266 boards from... (Banggood)

- Sat May 07, 2016 2:11 pm #47070 Short version) any control system that mentions numbers near 255 beware of exceeding 255. Any floating lines beware of inadvertent tripping.

The long version..about 20 years ago my career was seriously disrailed when my head of department decided we needed to replace our existing system with a new ibm based one.(for very good reasons). The business case went up to our parent company ho and got approved, and development started as an entirely separate section from the existing it dept. Some millions of pounds later, they were getting to the point where testing could start. At that point it became clear that the business case and budget had no provision for new networking; the new system was running ibm synch protocols and we were running asynch over a multiplexing network. In those days, this was a non-trivial thing. To install a parallel network to all our sites would have cost at least a million pounds and added between 500-750k to our annual budget...

To get round it without spending money we didn't have, ibm suggested looking at a solution that involved pcs used as protocol converters, runnning x25 from the ibm computer to a specialist card in the pc, software conversion, x25 again to our main network node, then from there out over the proprietory network protocol to the destination site. At that point, it came out on a port as ordinary async traffic to a pc that was running the matching ibm terminal emulation and also the terminal emulation for the old system. The main network had automatic and user driven switching capabilities, and we could easily support over 150 devices with subsecond response times on a single 64k link. Overall we had ample capacity to support our 2000ish devices and 200 locations...
We did some testing; all went well. Too well; the powers that be decided instead of moving just a small test area across, the whole system would go in a big bang approach. I worried...
I upped the count of links from the ibm to our protocol converters, and on to the network so users could get to old and new systems. We had a couple of glitches; nothing unexpected.
Three month later I was pulling my hair out; the ibm was showing very high cpu, links were restarting without reason it seemed; our network nodes were restarting; users were very unhappy. I learnt a lot about ibm comms very quickly.
I had everybody you could think of in.

In the end there were three things physically wrong;
The comms network node upgrade had upped the maximum number of logical channels possible from the historical max 0-127 to 0-255. Unfortunately all the good software engineers had moved on to the up and coming router side. So nobody tested what happened if a customers node looked for a free channel at the 255 limit. The answer was the controlling software wrapped round to 0 and started working up again in a continuous loop, till a watchdog timer said "this is stuffed" and restarted the whole bit of kit, throwing 300+ users off..and sometimes causing remote nodes to do the same.
Many basics use a pointer and virtual label to show where to go next. If line limit is about 253 as it was, and you exceed it, expect odd happenings.
The second thing was upgrading to 64k lines from 19.2k. The issue here was that the protocol conversion software knew the line was faster, but treated it as having the same number of control lines. The conversion board had the same connectors, but only some control lines were actively driven. The others floated, when they crossed a threshold software said oops and restarted the link - which caused mass disconnects so many people were reconnecting so very likely to trigger the first issue.
Monitoring pin states .. Well i think you can see where i was going. Fit the resistors unless internal pullx gives you certainty would be my thought. If there's a command to do this, great.
Processor - well on our system,it turned out there was nothing actually wrong with it; consultants had seriousluy underestimated how much was needed per transaction; our volumes were up, partly because of restarts but mainly because users were making many mistakes on the new system ( training happened too early and was forgotten by live time ) so they were processing large numbers of corrections. I went from the 3rd from base model the head of department had bought to the biggest machine ibm made in the range; it cost very slighty under a million pounds to do that.
Its not always easy to get a quart out of a pint pot...

Net result - one career mangled; one company out millions...

- Sat May 07, 2016 9:20 pm #47085 Great story reminds me of an old hardware bug that was exploited to have some fun back in early 2000's the old wrap around bug you could just keep filling up a buffer and then bang exploit active as it filled another buffer with code and nop's with padding then you would just trigger execution and bingo. The bug was fixed by some bug catching code but needless to say I would bet millions had fun with this or reaped the rewards from it. It was amazing to see a high profile security company have their bugs fixed via public exploitation. I think without the public exploiting of such bugs the bugs would still be out there. Really this was a great model as it helped them to constantly upgrade their security the only downfall was that users of the bug got something in return they were not "supposed" to have access to. I think overall though without this cat and mouse game progression would have been insanely slow moving. As of now there has been no known exploit to the security on their new system. Some folks were thrown in the slammer some were sued to oblivion etc... But the company itself really should have looked at what they gained out of their losses and really their losses were nothing as they lost nothing just digital stuff really yet they claimed all these damages when really the gains were a now fairly much so unbreakable system for quite a few years after.

I will say one thing reading about this incident was very neat but on the other end I believe the same thing happened to that company as your own company it was likely a huge loss and I assume heads also rolled funny thing is I read the attackers that discovered the bugs after serving their time also had taken a job offer from the security firm as pen testing experts more or less overall from what I read their were some fairly well educated out of the box thinkers involved in all of it a fun story. As to what it is I speak of I will keep that as a mystery to prevent other readers from reading about it or getting any ideas of doing so as the penalties are rather stiff and no one as a teenager or even young adult would grasp the importance or the concept of why not to partake in such a thing. But anyhow it was a good read I'm shocked a movie of it was never made.

Helpful? Donate To help support Mike http://www.esp8266basic.com click the donate button lets keep this project going and hope we can get the ESP32 in the mix. BEGINNERS GUIDE HERE http://www.esp8266.com/viewtopic.php?f=40&t=6732

Where I buy my ESP8266 boards from... (Banggood)