raliand / ESP_AsyncSmartPlug

WiFi Based Distributed IOT Home Automation
GNU Lesser General Public License v2.1
2 stars 0 forks source link

index.htm does not load #1

Open RudyFiero opened 8 years ago

RudyFiero commented 8 years ago

index.htm does not come up in a browser. edit.htm does.

Seems to be an interesting project from the description. Doesn't seem to work though. It would be nice to have known that rather than spending the time trying to get it to work.

raliand commented 8 years ago

Hi Rudy, don't worry I am here to help. The asyc version doesn't work (yet). Last night I uploaded the version with the normal HTTP server and that works much better(look at my second project). The idea with this one was to have all the javascript libraries on the ESP so you can use the interface without the need of a internet connection... and I will get there one day when the libraries that I depend on mature a bit more. For now I am falling back to loading the javascrips from CDN as I need a internet connection for the NTP anyway. Thank you for the interest - this gives me motivation to press ahead :)

RudyFiero commented 8 years ago

"The idea with this one was to have all the javascript libraries on the ESP so you can use the interface without the need of a internet connection"

As it should be.

I was interested in your project because of the use of the async libraries. I wanted to see an example that I may make use of. I have seen a couple but I can't get my head wrapped around it yet. I liked your project because it is base around UDP and that is the way I want to go. I'm not too keen about every node broadcasting on a regular basis. I'm concerned about too many collisions. Maybe it isn't too big a concern. I don't know as I have little experience with this.

The system I had thought of was to have a few regularly broadcasting input nodes and a larger number of listeners. I work for a company that manufactures control electronics for animal barns. Hogs, chickens, cows. Typically we have a few inputs, temperature probes, and many outputs, exhaust fans and air inlet actuators. I wanted to play around with a purely distributed control system. Each fan having the the control relay at the fan.

And because barns are in less populated areas there isn't always reliable internet, or any internet at all. Checking the web for the time might be included but a RTC will be available because it just needs to work.

I just started using the ACS series current sensors on a project at work. I like it. I have a project where there is a 3/4 hp motor that I need to do speed control on. But it's a 12V dc motor with full load current of 55 Amps.

I'm a hardware guy. I'm just getting into the programming as a hobby. At work I design the electronics and pass it on to our programmers.

raliand commented 8 years ago

Hi Rudy, What you have is quite a specific application. What I am aiming for is a more polished user interface as it is targeted at the 'general population' :) I am a software engineer, so a 'specialised application' is a much easier problem for me. Let's see if I got this right. Your nodes are all on the same network, but need to work autonomously. Their configurations won't change often (provided that the 'recipes' are complex enough). You would need a central point of monitoring, reporting and configuring. If I am correct, I would suggest each node having a static IP and a single javascript application(local static web page) running on a management computer. You would manually add each node with its IP and the application will connect to each one via WebSocket (the async library works well for that). This way you will not need a Web Server on each node and in the same time you would be able to monitor and configure all of them. You can change the broadcast intervals separately for the UDP and WebSocket broadcasts. Let me know if I am on the right track.. Are you based in the US? I am in Johannesburg, South Africa and seems that our times are quite different... ;-) Regards.

RudyFiero commented 8 years ago

Hi, been busy but finally here again. I'm in Winnipeg Canada. I had been writing to a woman from Pretoria, Elaine. I wonder if you know her? (just kidding)

The company I work for makes temperature control, sprinkler systems, lighting control products for the agricultural market. From single stage temperature controls to larger 16 output controls, and then our big box control with plug-in modules. We are just starting to make that controller web accessible. That system has a PC for management and logging.

Yes my application is pretty specific. Primarily this is a learning exercise. I prefer a better defined target otherwise you don't know where you are going or when it ends.

I want a polished user interface that is simple and intuitive. With spiffs the ESP9266 is capable of delivering sophisticated web pages so it is a matter of implementation. I first want to start with a relatively simple case. No computer involved. That would come later with larger scaled system, and then that would likely be a Raspberry Pi level device. But for a smaller system I was thinking a smartphone would be used for access and programming of the system.

A mesh setup was something I was thinking about but I tried the mesh example and it was horrible. Very unreliable. Now (with more experience) I wonder if I didn't have enough physical separation between my test units. I had four on my on my desk and I think they were getting too much interference. Because of the poor mesh results I had thought of communications between devices via UDP. Broadcast or multicast messaging for system traffic, then unicast for communications between specific devices when needed. And I was thinking of a very simple mesh technique for redundancy. That part needs more thought.

Most of the devices would be relays that would turn on fans, or air inlet modules with an open and close relay and a position feedback input. Also timed events, like turning on an auger motor for supplying feed at the correct time, or lighting. So these would be primarily be listening to system system information. There would be fewer input devices primarily measuring temperature but optionally humidity and static pressure. (in room to outside differential) I was thinking of redundant control of the system by the temperature input modules. Them being the master control of all the system events. Or go the other way and have each element make it's own decisions based on the transmissions it gets. And this is where I would want a mesh approach so that all information is received no mater the path. But that's more complicated and might be better to leave for later.

There usually is little change in the control strategy. There modification based on the aging of the animals. Temperature setpoints are gradually lowered as the animals grow larger. Of course is manual override ability for the system or individual elements. Manual control between batches allowing washdown or just turning off the system between batches.

Temperature is the primary input of concern. I was thinking that that would be the master if I went for a master control approach. And if there were multiple units they would interact, come up with a single or average control value. I see them as the configuration point of the system. The head although that is not a good analogy if there are multiple units, unless it makes up a virtual head. (I think it is getting late . lol)

I might be mistaken (we will see) but I feel that the control and management can be handled by an ESP8266. (some healthy doubt though) I think manually adding the nodes would be safest. I was thinking of showing a list of devices to the user and he would pick from those available. Adjacent rooms would have their own controllers and would need to be on their own zone/group. I can see the person going to each element and configuring it while they are in front of it. Able to see it, turn it on and off. Sometimes on installations when all the wiring comes to one central control box the wiring is incorrectly identified and can be hard to track down.

I have not used websockets yet. I didn't know that websockets have a broadcast mode. That is definitely desirable. I think that is something I need to look at first.

raliand commented 8 years ago

Hi there, it was my turn to get busy at work and have short weekend away afterwords... :) I completely understand your requirements now. It makes it very clear to me why you chose my project. I think the main goal for me now is to finish the interface, so the 'recipes' can be added and edited. The loading of the javascript files and the async web server, are of a much lesser importance. These problems can easily be solved later by loading of the js libraries as binary variables in the PROGMEM as per the example in the ESPAsyncWebServerhttps://github.com/me-no-dev/ESPAsyncWebServer. For now I will assume that the WiFi network is connected to the internet. I will let you know when I have a new version of the interface to try. I am very keen to test this type of distributed system in real life, which gives me a great motivation to get back to working on the project. I have also tried mesh networks with very little success and this is actually what pushed me to go the UDP way. I also find webSockets to be very stable and efficient in such a star-shaped configuration of nodes (one central web browser creates a single connection to each node).