Hi, I'm looking for someone to build out a prototype controller for an end device (mechanical device). Basically, I would like a controller that can be housed in a project box that does the following:
Has a "Run" button that enables a 120 Volt relay (end device only uses 50 watts at most)
Will keep the relay closed for 60 minutes
Will then open the relay, shutting off power to the device
Will have a display that shows the total number of times the relay has been enabled
The plug for the end device will connect to the relay power socket inside of the container so that the end user cannot bypass the counter by plugging in the device directly into an outlet.
If possible, an ideal add-on will be for the controller to connect to the client's wifi so that I can communicate with it, mainly to read the counter. If this can be done, then the display can be an LCD to display any other information that is needed. There would also need to be a way to connect the device to the client's wifi network, so there may need to be an Android app so that I can connect it while onsite.
Also, is it possible for the controller to store the the date and the number of activations per day? This file can be sent to me in whatever way possible. If we are not going to use a wifi connection, can we use another way to store the data so that I can pick it up with a USB flash drive?
I'm interested in your quote to create this box. If you have specific questions, let me know.
How about we use a controller that has WiFi built in and comes with existing android app? That would ESP8266 which can be controlled via Blynk app. If WiFi connection is reliable then data can be logged directly to google sheets or on a local file that you can access remotely.
the problem with connecting to a client's WiFi is they have to give you the SSID and password and hence access to their network which they probably will not be willing to do.
Conisder LoraWAN or a modem with a TCP/IP stack
Are you sure that this needs to connect to the client's Wi-Fi? If you are going to be onsite, then you only need the device to have its own Wi-Fi that you can connect to. The only reason for it to have to go on the client's network is if you are physically out of range of the device. Connecting to a third-party network has a whole bunch of issues that I've had to deal with over the years.
That said, yes, it's pretty straightforward and I can build this for you, assembled and tested. Send me a PM if you'd like to proceed.
This is a unique device that I am looking to have someone build. Based on the adoption of the purchase of the end product/service for which the end device being controlled takes place, I would potentially need a few more built at a later time. It will not be a mass-produced device.
Regarding connecting to the client's wifi, yes, they would either connect it their self, or provide me with the network name and password.
Regarding the need to connect to the client's wifi, I would like to in theory be able to connect to each device from my location on a monthly basis to download a usage report that shows either the number of times the device was used, or a more detailed report that gives me the date and times, as this data can help be better understand potential demand rates. If I am just going to "read the meter" (the counter, in this case), I would not need to connect to any self-generated wifi network when onsite, as I could just write down the current count when I am there.
connecting to a device on a local network from the internet would require the site owner to set up the network router to forward TCP or UDP packets arriving at a specified port on their IP address to a particular device on the network
assuming you can access the WiFi network it would be simpler for your device to connect to your remote server at regular intervals to upload runtime information
