I have been working on a SIM800L GPRS module with ESP32. My purpose is to post data to a IoT platform using GPRS. I'm using sim800l library.
Here in the code i want to provide apn manually like this,
const char APN[] = "airtelgprs.com";
is there any possible method to assign apn automatically?
It's possible, but not simple. There are people who maintain a public database of network providers in the world and their access points: Service Provider Database. Upon logging into a GSM network you can choose the correct APN based on the MCC and MNC of what your GSM module is reporting. It's not entirely trivial, as the database file is over 341 KiB (but it's XML, so lots of redundancy).
The most annoying factor is that there are entries with different APNs, but same combination of MCC and MNC. This means there are networks with look exactly the same to the GSM module, but use different APNs. In such case you cannot automatically choose an APN and expect it to work. Either the user would have to choose between the alternative APNs or you'd have to try them out one by one until you succeed in connecting to the Internet.
Related
I want to post data to 2 different devices from same esp32. And I want to do it like posting all the data to one device and sharing its telemetries with the second device. Is that possible on thingsboard?
I achieved this via ESP32 but when I am posting data with two different token, I need to cut the wifi and reconnect the Thingsboard with the other devices token. This situation contributes to enormous battery consumption. When I examine the thingsboard library I could not see a function about cutting the network only with thingsboard. What can be done to overcome this situation?
Any idea will be appreciated.
Thanks
One way I could think of, would be using ThingsBoard Integrations. Where one input payload can have multiple outgoing payloads (works even for multiple target devices or assets):
https://thingsboard.io/docs/user-guide/integrations/#converter-output
But this requires ThingsBoard PE & an external MQTT Broker in between your ESP32 & TB.
Or you could try the MQTT Gateway API:
https://thingsboard.io/docs/reference/gateway-mqtt-api/
I'm trying to write a super-simple iOS app, just for personal use (i.e. it doesn't need to conform to any App Store stuff). I want it to do the following. Assume it's installed on two devices, both of which I own/control.
On device 1, it has a button that, when pressed, will immediately cause a notification to pop up on device 2.
I'm fine with hardcoding specific apple IDs, device IDs, whatever; it's also fine if this only works when the two devices are on the same LAN/Wifi. all I want is for the above to work, in the easiest way possible, and preferably without needing anything to run on a server anywhere.
How simply can this be implemented? I've set up a whole push-notification system once before, but that required some server-side stuff. Hoping to be able to do this without any of that.
====
Update: realized I wasn't clear in the original post that I need the notification on Device 2 to pop up whether or not the app is currently open/running on that device.
I think that what you are searching for is multipeer connectivity framework.
The Multipeer Connectivity framework supports the discovery of
services provided by nearby devices and supports communicating with
those services through message-based data, streaming data, and
resources (such as files). In iOS, the framework uses infrastructure
Wi-Fi networks, peer-to-peer Wi-Fi, and Bluetooth personal area
networks for the underlying transport. In macOS and tvOS, it uses
infrastructure Wi-Fi, peer-to-peer Wi-Fi, and Ethernet.
source: https://developer.apple.com/documentation/multipeerconnectivity.
You can also check those tutorials:
https://www.ralfebert.com/ios-app-development/multipeer-connectivity/
https://www.hackingwithswift.com/example-code/networking/how-to-create-a-peer-to-peer-network-using-the-multipeer-connectivity-framework
Send sms to port is a way (the protocol will become SMS): https://developer.apple.com/documentation/foundation/nsportmessage
and Maybe Firebase Remote Config can help you: you can get your data in FCM remote config (key-value) from the app :
https://www.raywenderlich.com/17323848-firebase-remote-config-tutorial-for-ios
https://firebase.google.com/docs/remote-config/get-started?platform=ios
, and you can modify your data whenever you want, and the app can fetch it.
I have similar requirements, and it seems like APNS (Apple Push Notification Service) is required for this because it's one of the only ways to 'activate' an application that is in the background.
As a result, then the question is how to make APNS as painless as possible? It seems like combining Firebase Cloud Messaging (or FCM) (to manage APNS / sending messages), and Firebase Functions (to help manage FCM server-side requirements) is one decent option.
Is there any way to create your own google IOT device based on webhooks and POST-request? Without using firebase, IFTT, node.js
Samples that Google are very poor, they don`t show all steps of creating your own app, they just showing how to deploy "their sample"
I tried to make action with dialogflow & webhook, it was pretty simple. Just processed JSON in POST request to Azure function.
But when I try to create IOT device, its ask me for fulfilment url and it does not even tries to reach that address. I read about action.device.sync, action.device.execute, it just does not communicate with the specified address, giving simulator some voice command doesn`t affect at all. Are there any ways to create IOT device to work with POST-requests & web-hooks?
The answer is it depends.
There are many different ways to do server-device communication: web sockets, local servers, hub/local control, polling, MQTT, and likely many others. All of these solutions have trade-offs, and work in particular circumstances. Depending on exactly what IoT device you want to build, its requirements and technical specs, and what cloud providers you are using, you may identify what works best.
If you run the sample, you'll see it is sending JSON requests to a server and expect JSON responses back. This is must like Dialogflow & a webhook. In this case, the smart home platform communicates solely with the server.
Your server can then communicate with the device in any way that you want. I'm not too familiar with Azure offerings. It might have an MQTT service as well, or some other sort of push notification service you might be able to use.
If you're seeing simulator issues, you may need to make sure your authentication is set up correctly, and you'll need to first complete account linking on your phone before you can use the simulator.
I'm doing some network research, I want to find all the IoT devices (or at least devices that could be IoT) from .pcap files. Do IoT devices have some unique traffic characteristics, traffic pattern or identification (eg. protocols, ports, etc)? I can't find the answer. IoT devices are relatively new so there is not that much documentation about it.
Thanks!
This is an active area of research and may require some sort of ML algorithm. We (3 students at UC Berkeley) are also looking into it. Do you have any pcaps you can share?
There are many characteristics, but because this is a new field with insufficient standardization - there is no solution to find all devices, and you will have to use several different methods.
Watch the protocol - some devices use niche protocols that single them out (like SIP for VOIP devices)
Watch the urls devices are looking for via DNS - since most iot devices are not directly human controlled like normal computers, their communication is rather unique per device. They will contact the site of their vendors for updates, send and receive data that directly relates to their function and won't have much variance in their behavior.
Watch for service discovery protocols. Many protocols include the service that the device gives as field. Read about ssdp and mdns.
There are many more complex ways of using the fact that most of the communication is pre-defined. Devices have unique patterns of communication - like specific times between requests for example.
There really isn't. It's an internet device after all, and the manufacturer and the user through configuration will define its traffic pattern.
That said, there will be a traffic pattern for a particular type of IoT devices. Sine IoT devices always phones home for legit reasons, you can probably find your device types by the servers they connect to, and use that to refine your statistics/ML algorithm.
Now on a tangent, a lot of IoT devices (medical devices, OnStar, Tesla and etc) use cellular networks, both for mobility and for reliability. There are a set of protocols that show a lot more information.
I have got a couple of phones and another couple of PC's connected to a Wifi access point and need to send and receive messages between either of these, I mean anyone can send a message to anyone and receive a message from anyone.
I am willing to write apps on the phones(Symbian OS, S60 platform) or PC(Windows), but what I can't understand is how do I set up a client or server, since any one of these devices could be a client or server.
If I use sockets do I have to script for ServerSockets and also Sockets on each of these devices? Can I use the HTTP protocol?
Alternatively any standard protocol that I could use to implement this?
You would broadcast UDP packets which would arrive at every device on the Wifi network. You would have to invent your own protocol to decide on the identity of each device, since you wouldn't be able to easily infer the IP addresses of your network devices. Without writing an election algorithm you would find it difficult to use a client/server architecture, so just use point-to-point (P2P).
Google for UDP broadcasts and read the relevant RFCs at ietf.org.
It seems like you're looking for pretty typical peer-to-peer communication over IP. I suppose other requirements will dictate which transport you use (HTTP, raw sockets, etc), but yes: Each node will be both a client and a server. You could possibly use MDNS (http://www.multicastdns.org/) to help the nodes find eachother in an ad-hoc manner.