I'm interested in the answer to this question above because I'm trying to setup my Lab so I can send data from an ESP32 device over wifi to Influx DB hosted on my local network with a raspberry pi.
I've tried doing this with udp but the arduino libraries are very poorly documented (and didn't work)
and I couldn't find anything from Influx about what and how the data sending format should be...
Also is there a way to quickly find the network method used to transmit communicate with Python and influxDB?
According to the documentation here they support several methods.
Looking in particular to the upd listener seems that you need to enable the listener on the influx db server first.
Related
We are pairing WT901BLE device with the ESP32.When WT901BLE is paired with smart phone application NRFConnect then service UUID is shown. I have read on some forums that some devices don't advertise service UUID and ESP32 only analyzes advertised data so that's why ESP32 can't see the service UUID of WT901BLE.Someone proposed on git to a similar issue that library code need to be updated for ESP32 to read scan response for data other than advertised data also then it will work. Can someone tell whether this is the only solution or there is some better way to do it. Secondly, which library need to be updated to get the desired result?
I have a BLE temperature sensor, which should send measurements to an ESP32 via a BLE connection and my plan was that the ESP32 could send the measurements via WiFi to my database (Firebase Realtime Database). However, I have seen from a few tutorials that a mqtt server would be neccesary (see the screenshot below - link to the video: https://www.youtube.com/watch?v=PBYCG-ypvRY). Could someone please explain to me why the mqtt component is neccesary? Currently I am measuring temperatures using my ESP32 (without the BLE temperautre sensors) and sending them directly to the database, so I am confused as to why with BLE I would need a mqtt server.
Thanks for your help in advance!
You don't need MQTT. It's just one of the IoT-friendly protocol alternatives (like HTTPS, AMQP, CoAP, homebrew, etc) available to you for device-to-server communication. There are pros and cons to each one. It's up to you to choose whatever solution is relevant to your system.
If you've already implemented the Firebase HTTPS interface and it does the job, you're done.
If you are having problems, note that the Google IoT Core also prescribes MQTT (or, alternatively HTTPS) as an underlying messaging protocol - used together with the Device SDK for Embedded C. But this is for people who want to have a large-scale authentication and management solution for their devices. By all means, stick to your existing solution if it works.
I am using an embedded microprocessor to communicate with a SIM900 GPRS modem. The sim900 has an embedded tcp/ip stack but no embedded PPP stack, and my embedded environment has neither of these stacks.
With other devices I have followed these steps:
at+cgdcont="IP","internet",,
atd*99***1#
called a PPP function that took take care of the login to the APN (and presumably the authentication & LCP etc).
called a TCP function that connected to the remote server.
But now I have to do the PPP part myself. so I am at a loss locating all the necessary information.... can anyone point me in the right direction?
when I use hyperterm so as to see what happens with ATD*99***1# it connects and returns a lot of PPP frames which i suppose i have to write a module to deal with. But I did notice, on a number of sites, that the login to the APN is not mentioned at all, so is there a way of bypassing the login?
When I follow the example in the SIM900 docs, I get an error indicating (quite rightly) that the PDP is deactivated...
I think my original question was really 2 questions...
1) does one need to write an APN logon module when using the onboard TCP functions of the GPRS module?
- the answer here is NO. The module takes care of that....see cmd AT+cstt="apn","user","pwd".
2) where can one find opensource code for a PPP stack?...that remains unanswered.
The 1.4.1 release and some older versions of LWIP have an implementation of PPP in it. Not certain if it can easily be used standalone though. You might still be able to decouple it from LWIP and use it.
There is a GPS device which can send data to IP:Port. I have a website hosted on IP 1.2.3.4
Can I send GPS data from the device to that website? 1.2.3.4:8080? How I will retrieve the data?
This is the device
http://cgi.ebay.com/GSM-GPRS-GPS-Vehicle-Car-Tracking-System-Tracker-Device-/270683202099?pt=AU_Car_Parts_Accessories&hash=item3f05f9e233
Maybe this should be a comment...
To be honest we can't answer that question the device will most likely use its own data format(s) so the service that receives from it will have to implement those. Additionally the device might not support web protocols, it could use raw TCP sockets for example, so you may have to implement a listener service that adheres to those protocols. In fact it looks like the device uses GSM (a mobile telephony standard), so using a web site to receive the data is definately off the cards unless you have a GSM proxy service sitting between the device and the web server.
Assuming that you are allowed to implement your own service it follows that the documentation will include the necessary details and if you are lucky a full SDK that you can use.
I'm doing a project where I must write a network library for a device connected to a Windows machine. The complication comes in that I may only communicate with the device using ethernet frames. So there is no TCP/UDP/IP at all. I don't think the bind/listen/accept approach can be applied here, but maybe I am wrong. Also, there is no routing or switching involved.
I have a few questions. How do I use a socket to communicate with this device? Does winsock have any support for just frames? I haven't been able to find many resources on this. Does anyone have any ideas about how I should proceed?
Is using sockets even a good idea or can I just send out the information with the appropriate headers?
Use WinPCap, it has an an API to send and listen to raw data.
You can build your communicate layer with it.
Give the WinAoE code a look-see - it says it lets Windows talk to ATA over Ethernet devices which means it has to communicate without any of the upper layers of the network stack.
Edited:
As near as I can tell, if you want to send raw ethernet frames, you want NdisSend and friends.
As well as winpcap and NDIS you could also look at raw sockets which are a standard part of the Windows API and don't require you to write driver code http://msdn.microsoft.com/en-us/library/ms740548(v=vs.85).aspx.