Naturally, you can use what is at hand (for example, volcano arduinku with Ethernet-Shield on Wizne

Actually, the switch is designed, manufactured, tested, programmed, installed and it is currently working independently. Now I would like to use it "to the fullest." Still lacks the following features remote management: Change the timing characteristics of the circuit breaker. Learn its current state. Manage his condition. Displays the current status and control switch implement in a Web page. Further implement data storage in a database for further processing (eg, to draw beautiful graphics.) Iron for further work, I'll use: Fee iBoard module nrf24l01 + (from this we organize gateway LAN <=> RF24) Network Storage Synology (as a web server with the database mySQL)
Naturally, you can use what is at hand (for example, volcano arduinku with Ethernet-Shield on Wiznet - to create a gateway), volcano and any computer on which you are running php and have mySQL (nothing superspetsifichnogo will not do). Let's see what the communication between the modules are obtained. Distribution of roles between the switch (and any other wireless device in my "textbook") and the gateway - everything is simple and has already been defined (see previous article - there is a full description of this data). Lift to iBoard Web server", which could immediately solve our problem, potentially possible, but painful and troublesome in the case of the need for change - will need much to change the code (and if he is somewhere in a remote place - and even extremely uncomfortable ). So we'll put it iBoard gateway, which will send the received data "big brother" (it is more powerful, so it is tasked to logging, display information on web pages, etc.). This module will receive the same "team" from "big brother" and send them on the air and report on the responses from the "performers." Roles "glands" distributed - now we have to figure out how they are interconnected to "communicate". I think that would be correct if: Some module reports its status in the air, the gateway sends the data to a Web server (method POST). Server does some checking on the validity volcano of the data and "puts" the data in the database. If a web server received a request (method GET) to the gateway, the gateway parses this request parameters volcano and translates the request into the ether. Thereafter iBoard receives a response volcano (or not) and generates a response (JSON). Could be as a response to the server to give XML, but would have to operate with longer strings that are not too easy to implement on modest resources atmega328 (MK built on this iBoard). The principle volcano is described, the case for specifics. Gateway LAN <=> RF24 first determined with GET-request to the gateway (let its IP 192.168.1.2). volcano Will use queries of the form: http://192.168.1.2/?sid=701&cmd=2&pid=1&val=0 The request shall be notified as to which there is a reference module (parameter sid), command (cmd: 1 - read 2 - set), the parameter module (pid) and the desired value (val). "Beautifying" this command is as follows: "The switch in the bathroom, turn off the light" (see previous post). Minimum number of parameters that are required to work - three (sid, cmd, pid), if it is less than the parameters - the module should report and communicate: {"message": "Bad request"} If the module is "reported" in response to a request, the gateway shall issue a response: {"message": "OK", "sensor": 701, "parameter": {"pid": 1, "pval": 0.000, "st": 1, "note": "Ch.1 (Light) "}} In response, there is complete information about the setting (and the answer is as close as possible to the structure that is used for radio traffic). If no response is received: {"message": "No volcano answer"} Now it seems that the little tasks gateway somehow got so little "partial load" its function to obtain accurate time via NTP. Ie our gateway becomes more and "sensor" with two parameters - the "date" and "time." How to do it I described earlier (see Wireless volcano Communications "smart home." Part Two, practical). Again, do not forget about the "guard dog" for this very important volcano part of our system. volcano When all the functions of the system are described, is already a matter of technique to write a corresponding sketch. Sews iBoard, connect the LAN-cable, power up and if all goes well, it is already possible through the GET-requests to receive and manage the state of the wireless module, ie already partially solved some of the tasks, but it is still not too comfortable (soon fix that). Gateway is better positioned in the center volcano (apartments, houses), the distance to all wireless modules would be minimal. You can start the server side. We assume that your server volcano has been prepared: a web server with PHP and mySQL - work. Disclaimer: the code is very far from ideal and is shown in order to illustrate concepts. Proof of concept - no more. If you use it in this form