I am a web developer and I am starting to learn about the world of IoT.
Because of the vaccines arrival to my country (Argentina) I got asked to build 80 temperature sensors to monitor them and I have some questions about it.
What would be the best way to connect all of them to the cloud?
If I use for example aws iot platform, do you know how much it would cost monthly for just sending
and storing temperature logs for each sensor (remember, there are 80 of them)?
Is there any language/environment/protocol that works better for IoT? Because it's a constant flow
of lightweight data...
Is there a better way to connect them to the internet besides using esp32 modules for
each?(I saw a tutorial that said it's possible to connect some more to a single esp32 module)
If you have any advice I'd love to hear it. I know how to code but when it comes to backend and specially server stuff I have a lot to learn.
Costs are directly related to the amount of data you send, process and store. You'd have to check the price lists for each cloud service you plan to use. If we assume that you'll be sending 1 temperature reading (with associated data such as timestamp, device id, ...) every 10 minutes using reasonable protocols (MQTT, JSON) then the total costs for all 80 devices would be perhaps a few dollars per month. The total database storage will accumulate over time and you'll be charged more, but honestly the amount of data under these conditions is ridiculously low.
An ESP32 is cheap, has WiFi and enough performance to send data to cloud. You can connect this micro to AWS IoT or Google Cloud IoT using the relevant libraries from either: AWS library or Google IoT library. These libraries decide the questions of language and protocol on the microcontroller side - it's C and MQTT/HTTPS (but avoid the HTTPS, MQTT is much more practial). You can use JSON for the actual temperature data message. The microcontroller development takes place with either ESP IDF (a bit lower-level C environment) or Arduino (a bit higher-level C/C++ environment). Those use FreeRTOS as the OS on micro (note that the IoT libraries work on almost anything).
A practical alternative to ESP IDF and Arduino (especially for a web dev) is Mongoose OS where you can do much of the development work in JavaScript (not all, though). It has high-level libraries for both AWS and Google IoT (which still use the same underlying MQTT/HTTPS client, I assume).
By far the easiest way to connect the ESP32 modules to Internet is to have each connect to a WiFi AP. If the single WiFi AP doesn't cover all devices, add more until they do. ESP32 does have a mesh networking library, but I would hesitate to recommend it to newbies.
Related
I'm researching and trying to building a RC car that can be controlled by the internet. I've started looking into how communication over the web works, but I seem to be going nowhere. My goal for the project is straight forward:
The RC car has an on-board camera and 4g wifi router that enables communication (driving commands, video streaming) over the internet. A Raspberry Pi will serve as the on-board computer.
I will be able to control the car with my PC even across the globe, as long as I'm connected.
I want to preferably do as much by myself as possible without relying too much on other people's code.
So here are my questions:
How does an application communicate over the internet? What is the interface between the application's logic (e.g pressing "w" to go forward), and transmitting/receiving that command over the internet?
How is video data stream handled?
I've looked into WebRTC and WebSockets for communication, but they are aimed at providing real time communication to web browsers and mobile, not something like a raspberry pi, and I'm still in the blind as for exactly what technology should I use, and in general the overview and architecture of real time communication.
All I've achieved so far was an app that sends text messages between devices through a server on my network, with very primitive reading/writing using java Socket.
In short, what does messenger/skype/zoom do in the background when you send a message or video call?
Any guidance would be greatly appreciated.
First things first. You cannot do real-time control over Internet, period. There is absolutely no way to guarantee the delivery latency. Your control commands can arrive with a delay from milliseconds to seconds, or never. No way around it.
Now, you can still do a number of reasonable steps to absorb that unpredictable latency as much as possible and safe-guard your remote robot from the consequences of the unreliable communication.
For example, instead of sending the drive commands directly - as in, acceleration, deceleration, turn angle, etc., you can send a projected trajectory that is calculated from your drive commands locally on a model. Your RC car must be sufficiently smart to do some form of localisation - at the very least, wheel odometry, and with a good enough time sync between the sender and the RC car you'll be able to control the behaviour remotely without nasty consequences of drive commands executed at an unpredictable delay.
You can add a heart-beat to your protocol, to monitor the quality of the communication line, and if hear-beat is delayed or missing, initiate emergency stop.
Also, don't bother with TCP, use UDP only and maintain your own sequence counter to monitor missing packets. Same applies to the telemetry stream, not just command channel.
I am working on edge computing for IoT applications and expected to create a system that acts as a near edge computer with the use of a raspberry pi hooked up to a dht11 sensor. How do I send this data over to a computer that is at the edge? Ideally I want to use my PC as this device but I have no clue how to send this data over in real time.
So far I have created the circuit and can view the temperature and humidity readings on the raspberry pi in python. Unsure of what the next steps are - I don't want to send this data over to the cloud just yet.
Side note: I believe i may be missing knowledge regarding this but is the raspberry pi an edge device because it is hooked up to the sensor directly?
Any help is greatly appreciated.
You need to think this through a bit more. What will you do with the temperature and humidity data that you receive?
For example, if you're just experimenting and want to just see the readings in a console on your PC, you can use netcat to send the console output of your Python program from the RPi to PC. No SW development needed, they just have to be in the same network. Not particularly useful for anything else, either.
Otherwise you need to set up some client-server solution between the RPi and your PC. There's a ton of possible solutions, all depending on what you plan to do with the data. You can use MQTT, HTTP, a straight database connection (MySQL, PostgreSQL), etc. You have to supply both sides of the connection. The Python code on client side which connects and sends data; and the server side thing that accepts the samples and stores them somewhere. Plus all the networking, authentication etc.
Or you can just download the Python client libraries for your favourite cloud solution and set that up according to a tutorial. TBH, this sounds a lot less work to me.
I am struggling to find how to let google home do a local network rest call.
I have some ESP8266 laying around with mDNS and rest api in them.
Now with the google home I want it to send a rest call to the device.
I don't want any web hooks / services like IFTTT. I don't want the communication going through these 3rd party services.
It should work like this google home gets input (google service to understand is oke). It retrieves the action (local network, url rest call with body). Google home sends the rest api call to the local device.
No need to have port forwarding / firewall changes.
The Google Home does very very little on-device processing. Sending out local network calls is not one of the things it does. Almost all processing, including IoT controls through the Smart Home API, are done through cloud-based services.
Update
I can't answer "why" it doesn't do this, since I'm not one of the engineers that built it, but I can make a lot of guesses about why.
For starters - it increases the complexity of the software and hardware on the device dramatically. Right now, the device is really little more than a microphone and a speaker, with a little logic to detect the hotword and then stream everything else to the server, and then get a result back and play it. Most of the rest of the code is likely to handle setup and configuration.
If the device has to also be a general purpose IoT hub, then it needs software and hardware for Bluetooth and possibly other signaling systems. It needs to be able to keep track of the state of other devices on the network and manage that in between power cycles of the device (or even handle interruptions in power for the device itself). Some of the implications of that may need to open up the networking on the device to receive messages, not just send them. It has to have more extensive network configuration - to understand what local networking is and not just what the local router is and how to deal with that configuration (and that configuration when it changes). These are all possible, to be sure, but increase the complexity and, in some cases, lower the security of a device.
And that might be reasonable... if there was significant value in doing so. But you've already stipulated in the question that the voice processing could be done in the cloud, so once commands are sent to the cloud and parsed there - why not also do all of the above (device and state tracking, changing, etc) in the cloud? Particularly since most IoT devices maintain cloud servers anyway because people also want to be able to control or monitor their home devices when they aren't on their home LAN. Having a dual set of commands (some for when you're local, and some when you're not) does make sense in some cases - but also dramatically increases the complexity of both the controller and devices, so most just rely on the cloud, again.
So while I understand why some people would like to have a nice little system that can just sent your play local REST server a command now and then, the reality is that to do this for a consumer system isn't that reasonable.
If you really wanted a system that can do this - you can continue in the hobbyist spirit and build something with the Assistant SDK and your favorite IoT platform.
The “local” API for Google Home is a bit limited. Here’s a doc from someone who reverse-engineered the API.
Looks like they expose Bluetooth and Alarms/Timers, and some limited configuration stuff.
https://rithvikvibhu.github.io/GHLocalApi/
I'm developing a Web application with HMI capabilities that needs to interface with multiple Modbus RTU and Modbus TCP PLCs:
frequently update the web UI based on the state of the Modbus devices
send commands to Modbus devices based on the user's input
What is the best way to integrate a Web application and a bunch of Modbus devices, given the requirements?
have you looked at modbus bridges (or Modbus-RTU to Modbus-TCP converters)? and the 'middle-man' software we use at our place is Kepware which then talks to our SCADA package (Cimplicity for us). Not sure if you're still in need of any more info on this, just shout back and i'll fill you in a lot more :)
Also, does this need to be a low cost solution (you could pretty much do this with off the shelf hobby hardware) or a full-blown industrial solution? Doing a dead simple SCADA bit and then talking to the plc's shouldn't pose too much of a headache if you have the time for it.
I'm planning to setup some sensors for a project I am working on. I plan to use a simple xmpp client on each device hosting sensors and posting the readings via PEP/PubSub.
I would like to run a program which dynamically displays this sensor data upon receiving the push notifications from the sensor clients.
I intend to communicate on a LAN with 100Mbs connections and several WIFI APs as needed for the sensor locations.
Is XMPP a good choice for a backend?
Would this scale well at say 100 devices running 6-24 sensors each updating every 15-30 seconds?
XMPP would certainly be able to handle this use case, and seems a good fit based on the small set of requirements you have shown. I am assuming that the sensor data is small amounts of textual information.
From what I can see, I would not use PEP though, just straight up pubsub with a single node for all the sensors to publish to. Pretty much as simple as it gets.
I would think that any XMPP server should be able to easily handle that load. I know I was able to publish 800,000-1,000,000 items to a persistent node in Openfire in about 5 minutes (3.7.2 alpha version). A non persistent node would probably do a little better.