I'm developing a new firmware for an IoT device, one of its features is to create a WiFi SoftAP using an ESP8266. This new device is based on an old device firmware that I developed 4 years ago.
Now all works perfect until I close the WiFi in my phone; I remember that the old ESP8266 send a string like "0,CLOSED" witch means that the TCP device connected to the SoftAP has being disconnected; by that signal I can indicate with an LED if somebody is connected to the IoT device; but my currently ESP8266 only send that string after the TCP timeout is over.
There's different AT command firmwares for ESP8266?
I just need that the ESP send something to let my microcontroller knows that the TCP connection has being closed.
ESP firmware version:
AT version:0.40.0.0(Aug 8 2015 14:45:58)
SDK version:1.3.0
Ai-Thinker Technology Co.,Ltd.
Build:1.3.0.2 Sep 11 2015 11:48:04
Related
A couple questions.
TLDR is sending UDP broadcast packets on a Wifi network to allow for discovery of a IoT device (Raspberry PI) a conventional practice?
Long version: I'm working on an IoT project for a class. Based on other IoT devices I've used (a Christmas carol lighting system and music player), we decided to utilize an already working application (https://github.com/balena-os/wifi-connect). The way it works is it runs on the Raspberry PI and hosts a wifi endpoint through the RPI's network card that the user can connect to. Once a user connects to this Wifi endpoint on his/her Iphone, a Wifi selection and password entry page appears on his/her Iphone. The user enters the Wifi/password that the IoT device (Raspberry PI) should connect to. The entered Wifi will then be connected to by the Raspberry PI. The user can then connect to the entered Wifi as well and now both the user's Iphone and Raspberry PI will be connected to the same Wifi network.
We decided to send UDP packets to the broadcast address of the Wifi network from the IoT device, so that users connected to the Wifi (via their Iphones) can "discover" the IoT devices IP address by listening for UDP packets. Once the user discovers the IoT device's IP address, they can send HTTP RESTful API calls to the IoT device. I was wondering if the described process is conventionally used.
# script we are using to send UDP broadcast packets
import socket
import time
server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
server.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
server.settimeout(0.2)
message = b"message"
while True:
server.sendto(message, ('<broadcast>', 16123))
time.sleep(1)
We tried this setup at a public library, using their free public wifi. However, the UDP broadcast packet discovery process failed. UDP broadcast packets were sent out by the IoT device, but were not received by the Iphone. We're wondering if this has something to do with a firewall. We could successfully send UDP broadcast packets from a Macbook (via a python script) to an IOS emulator residing on the same Macbook, such that the source IP address of the packet was the same as the recipient. Is there a firewall rule such that a broadcast packet sent from IP address [A] can be delivered back to IP address [A] but not to IP address [B].
Also, I didn't mess around with the port number, which might have helped if certain ports were disabled by a firewall. I'm not sure. Help is appreciated. We are both relatively new to this.
DNS-SD (RFC6763) is the a fairly common and standardized way to do network discovery. It actually supports both TCP & UDP services. It was originally invented by Apple under the brand name "Bonjour" for printer discovery.
So yes, it is common to use UDP broadcast packets (via DNS-SD) for IoT device discovery on a Wifi network.
I'm developing apps for the HoloLens 2, and my current project involves a server on LAN that hosts a multiplayer experience. I developed this auto discovery mechanism using UDP multicast so that HoloLens 2 clients can find what ip the server is on just by listening for these UDP multicast packets.
During testing, the battery was running low, so I plugged it into Windows, and all my UDP multicast stuff just stopped working on the HoloLens. I don't know why.
I'm sure there's a setting somewhere for it, but I don't know where or if it can even be changed.
I've encountered this issue before on Windows where I had to go into the network adapter settings for IPv4 and change the interface metric to 1 under advanced TCP/IPv4 settings. With that setting on 1, Windows can receive UDP multicast packets, otherwise it does not.
I have a RaspberryPi which is configured to automatically connect to my iPhone's wifi hotspot. I need to take the RaspberryPi to various locations for testing, and I often need to leave it at a location for extended periods of time (without my iPhone hotspot there). The RaspberryPi needs an internet connection in order to complete the testing properly.
I am trying find a solution which would allow me to SSH (or connect some other way) into the RaspberryPi while it is connected to my iPhone's wifi hotspot. This would allow me to add a new wifi network/password when I move to a new location (I usually can't get the wifi network/password in advance). In other words, I would move into a new location, the RaspberryPi would be connected to my hotspot and would begin testing, and once I obtain the wireless network/password for that location, I want to connect to the RaspberryPi to add that information so it can connect to the location's wifi network instead of my hotspot.
I don't have a portable monitor for the RaspberryPi so I can't just hook it up to a screen and make the changes that way.
Does anyone have any suggestions? Thanks in advance.
On the phone running this hotspot, I am assuming you can install apps that permit you to SSH into the Pi, headless? I'm doing this regularly, my choice app is JuiceSSH.
Alternately, a laptop connected to the same phone hotspot running an SSH client such as Putty can connect to the Pi across the same AP, also headlessly. You can update your WPA_supplicant file and reboot the Pi, making sure to bring down your hotspot before it fires up again and joins the new AP. I'm also doing this regularly.
Given the time (4 months) that's passed, you've likely figured this out already...
Since I haven't installed windows 8 on PC yet, I'm not able to compile my program for phone and test whether or not will it works.
The question is: can I use DHCP ports (67 and 68), create there sockets and send/receive data in my app?
Reference of Socket API doesn't mention anything, however those ports can be locked by system DHCP client.
Since DHCP is a simple UDP protocoll it should be possible. You just need to check if it is possible on wp8 to open the ports in that low range. In linux that requires root permission, but luckily we use Windows.
I bought an Bluetooth ELM327 to read codes out of my cars diagnostic ports
I connect to it via Bluetooth in windows and it makes a serial-over-bluetooth com port 4
which any application running on my windows will connect quite happily.
I then found a few apps for the iphone and android etc that connect to these ELM gadgets via WIFI and not Bluetooth (because for some reason you cannot pair to these devices of iphone)
Now obviously I can buy a WIFI enabled ELM327 - but it costs £130 and my Bluetooth one cost £15
So after reading about this a bit I found out that the WIFI enabled ones you connect up as ad-hoc network and the smartphone(iphone) app tenets in port 23 that relays normal serial commands.
So obviously in the WIFI enabled one there must be some processor that runs an nano-os with telnet and some rs-323 translators and not sure what else.
How, using Windows 7 will i be able to relay any incoming WIFI requests for Telnet port 23 to my COM 4 that is connected to my Bluetooth ELM327 ..
As this is surely all that is needed by the Smartphone app.
You dont have to connect using a Bluetooth library like suggested ... because you are already connected to the device and have COM4 exposed to you. SO all you have todo is use a telnet library and translate and handle the handshake then realy the infomation as serial data.
There's no feature built in to Windows (or any other platform I know of) for such a scenario.
It would be fairly straightforward however to write a program to listen on port 23 and open a bluetooth connection when connected to, and then forward the data received on each connection out onto the other.
For instance one could use my .NET library 32feet.NET (e.g. http://32feet.codeplex.com/wikipage?title=General%20Bluetooth%20Data%20Connections etc etc) along with TcpListener from the .NET framework class libraries.