I am new for esp8266 device. Actually I'm interfacing esp8266 wifi device with Arduino for wifi and Android based home automation. But when I switch on the light that time, wifi connection automatically disconnecting.
Why it's happening? And what is the reason behind that?
I would guess switching on the AC device either causes electrical interference (the spark on the relay can be quite bad) which breaks your WIFI signal, or interrupts the power supply to the ESP8266, which can cause WIFI to fail.
But you really really really need to be more descriptive if you want a helpful answer :)
What is your exact setup, what is connected to what, and how, how are your power supplies organized, etc.
I wouldn't rule out a software error either, so can you give some details on your software setup also?
Be specific on the details on the failure, what does 'wifi connection automatically disconnecting' mean, exactly? Log files help.
I have had a lot of issues with EMI and RFI when it comes to media or commands with automation and distributed AV. In fact there is still one area of my house approx. 2sqft that simply goes not get any wifi and will kill hdmi data. i have done certain things to adapt to it while I figure out the issue but if it was an EMI or RFI issue you would be able to hear it with a tone generator used to sniff wires. If it is an EMI issue it could possibly be a bad ground connection and i am assuming that is what my issue is however it is an extremely high voltage and current wiring (not romex it carries the power to the hvac and steam room unit) and will have to wait to shut down all the power to the house and possibly get an electrician over here also to make sure I don't burn the house down or electrocute myself. Being zapped isn't that bad if the breaker trips but this particular one is a bit worrisome.
Related
Nearby Share sometimes uses bluetooth to transfer the files because of which it is very slow. Sometimes it is not at all handy to transfer files that are more than 100 MB. Initially I thought Bluetooth is used only for handshaking purposes. But later I realized that the files are itself transferred via bluetooth. I'm curious to know why should the files be transferred via bluetooth when it can be transferred via wifi direct. A lot of third party apps including Google Files use wifi direct to transfer the files. So why does a built-in functionality like Nearby Share should use bluetooth. The sole purpose of Nearby Share itself is to achieve fast file transfer with wifi direct and without internet. So if the files are transferred via bluetooth there is no point in using Nearby Share.
I'm also curious to know the various modes of file transfer present in Nearby share. There are three modes: Data, Wifi Only and Without Internet. I'm really curious to know why is an internet connection required to transfer files when Nearby Share is meant for file transfer without Internet. Is it meant for handshaking purposes in Web RTC?
(Disclaimer: I work on Nearby Share)
Nearby Share will always attempt to upgrade to WiFi before sending files larger than 1MB. A grace period of 10sec is given for that upgrade before fallback mechanisms kick in and the file is sent over Bluetooth as a last resort. Even after falling back to Bluetooth, the devices will continue to attempt to upgrade to WiFi in the background, but some failures are unrecoverable and the file will fully send over Bluetooth. Note that urls and very small files will immediately send over Bluetooth.
This upgrade can fail for a multitude of reasons. Most commonly, it's a concurrency issue. The same radio is used for Bluetooth, p2p WiFi, and your normal access point connection and it must be time-shared accordingly. If all 3 want to be on different channels, you will miss messages -- it's a guarantee. If these messages are important, such as the authentication frames when connecting over WiFi Direct, then the connection will fail. If these messages are less important, they may be resent until successfully received, but it will lower throughput for the transfer such that even 5GHz WiFi can look to be as slow as Bluetooth.
Nearby Share tries to avoid this in a few ways. When regulations allow, we will attempt to start the WiFi Direct group on the same channel as the access point. This way, the phone doesn't have to timeshare (although it does have the side effect of colliding with messages from the access point. But generally, both sides will back off a random amount and retransmit, and the loss is less than the loss of multi-channel concurrency). Unfortunately, many countries do have regulations that allow certain (or all) 5GHz channels only indoors -- in those cases, the access point can be set up to utilize it but WiFi Direct cannot.
We also prefer mediums like WiFi Direct over Hotspot, as WiFi Direct commonly uses CTS2SELF frames to advertise "Do not transmit for this duration". Unfortunately it's not as straightforward a message as "I am going off channel, do not try to communicate with me" -- CTS2SELF has the side affect of quieting all communication over the access point even if it wasn't directed to the phone -- but it does get the point across.
We pause any Bluetooth activity we have control over, to reduce the need to timeshare with it. In some severe cases, where the OEM has implemented timesharing that's too aggressive, we will turn off the Bluetooth radio to forcefully interrupt Bluetooth activity, but this is disruptive and usually a bad user experience.
We may try to send the data over your access point itself instead of setting up WiFi Direct. This can avoid the MCC situation described above, but comes at the cost that the data needs to be re-encrypted (because we don't know what other devices are connected over LAN and might be eavesdropping), and it does introduce another hop, as the data needs to go through the AP even if the devices are side-by-side. TDLS helps avoid that last issue, but it has limitations (eg. it won't use 40/80/160MHz bandwidth if the AP isn't set up for it, and it'll send over 2.4GHz if the AP is on 2.4GHz).
Other possible failures include the device getting into a bad state (toggling airplane mode can help here), the Android version being too low (ideally both devices should be R+, as it's almost impossible to fix bugs on older Android OS versions, even though we try), or just bad luck.
I am working on my Bachelor Thesis and I have to implement an application using Google Nearby Connection API. The goal is to develop a disaster assistance app.
I tested Google Nearby Connection for the past two day and I have some problems, quesitons.
I have 6 devices, 4 Motorola G (2nd Generation), 1 Nexus 5X and 1 OnePlus 5T. They all are up to date. I also use the latest version of Google Nearby
'com.google.android.gms:play-services-nearby:15.0.1'
Here are my questions:
The Motorola devices ask for a pairing code to connect one to another, but even when the pairing is accepted they do not connect.
Some device connect flawlessely (OnePlus and Nexus) but the Motorola have problems connecting, the often throw this error : STATUS_BLUETOOTH_ERROR
Is it possible to create a mesh application that will forward message form device to device? With the testing I made I am starting to wonder if that's really feasable.
During my testing I often discover and advertise in the same time. Is there a better way to do so that might avoid problems?
I used the documentation of google and some other ressources I found online.
Here is the code I had at the end: Gist Link
Thank's a lot for the help guys!
Disaster assistance apps have actually been talked about a lot on our team, as a really interesting use-case. I work on Nearby, the team that built (and maintains) Nearby Connections. It's definitely feasible, once you know the limitations.
I believe that Motorola bug has been fixed on our internal builds, so look out for it in the coming months. The update will be pushed out to all devices (you don't need to update your app) in 1.5~2 months. Wish we could push it faster, but it is what it is. They should be connecting if the pairing dialog is accepted, though. If that's not working, I unfortunately don't have a work-around.
We've found that toggling Bluetooth is the best way to get around STATUS_BLUETOOTH_ERROR, as the radio can get into a bad state (especially on Android versions older than N... which is... a lot of Android versions...). We do our best to toggle semi-often, by toggling the radio after apps stop using Nearby Connections, but sometimes that's not enough. In extreme cases, the phone may have to be rebooted. This error can also go away on it's own, and can also be somewhat alleviated by stopping discovery before connecting.
Yup, meshes are definitely possible. For an always connected mesh, you'll want to use P2P_CLUSTER. Try to keep 3~4 simultaneous connections per device (and have some kind of logic to avoid forming islands). Once the devices are connected, you'll need to build a protocol to send messages, flooding the network for broadcasts or hoping between nodes for directed messages. Other ways to solve this problem that I've seen are using advertise / discovery to transmit short pieces of information asynchronously, or setting up a timer (eg: Once an hour, everyone scans and tries to connect to exchange data, and then quickly disconnects), or forming a 'snake-like' connection where everyone connects to at-most 2 devices and forms a long string of connections.
Advertising is usually lightweight, but discovery can be hard on the radio. We turn it off internally while you connect, but we turn it back on for the duration of the connection. This can lead to flaky connections. If you're able, try to limit discovery to short bursts.
PS: You can check my post history to get some more in depth information about Nearby Connections.
PPS: In the future, break up your stack overflow questions into smaller, more pointed questions. It's more helpful for people searching in the future.
Referencing blog posts like this one, and SO questions like this one. I am going to assume that this is a general behavior (and not a bug on my side). The common answer seems to be something to the effect of: "Change the BLE firmware so it actively disconnects."
The question which is not well addressed is how Android apps handle what must be a very common occurrence? Connection is lost unexpectedly due to "range", I.E. radio signal strength.
Is there a way for an app to be notified "immediately" on the loss of connection?
It does seem unrealistic that all apps just sit there for something like the 20 seconds which is mentioned as a core OS timeout value. Is that what we should all be doing even though my equivalent app on iOS knows about the loss of connections in less than 1s?
Example 1
One common type of BLE device is the "Find my keys" type. Many of them have a feature to alert the user when you leave the "keys" unintentionally. I assume that this uses the connection going down as an indicator of you walking too far away. Right?
Example 2
Your app is supposed to be notified of of value changes from a characteristic on the device. This would be any kind of sensor data where you have some threshold is being crossed for example. I can think of plenty of examples where you'd want to know immediately that your "sensor" is out or range.
Known Workarounds
I have seen one workaround amounting to constantly monitoring the RSSI to the BLE device but that seems like it would eat up a lot of battery. Similarly any failure to write to a characteristic (that normally succeeds) could also be used, again with battery life paying a price.
Something approaching a definitive answer to this questions seems like a good resource.
In latest versions of Android they lowered the default timeout to 5 seconds, which is of course much better.
I guess most peripherals send their own Connection Update request where they can set a different timeout value, which solves that issue (except for the small time between connection setup and until the connection update has gone through).
So called "out of range" detector apps are according to me pretty useless and hard to make good because BLE devices will probably sometimes temporarily disconnect anyway, even though they are in range.
For your actual question if it's possible to "immediately" get notified on the loss of the connection, the basic answer is no, because the Bluetooth controller doesn't send anything to the main cpu that packets were lost (that's the whole purpose of having a timeout so you are allowed to have packet losses). But you can of course try to poll the rssi or set up a flow where the peripheral every constant interval sends a notification and then you can in your app detect if you don't get the notification after some amount of time. But in this case it's smarter to just set your own timeout (from the peripheral) using the connection parameter update procedure.
We are making a SIP-related solution and I am requested to compose an app on a customized android pad(4.4.*). Unluckily, the pad is from 3rd party and accordingly we hardly do further jobs on the framework or driver......
On the Pad, a LAN port is designed over USB and we plan to access network via LAN. Besides, no power key is populated on the cover.....
Now the question is: Since the pad sleeps, the LAN connection is stopped soon. I fully understand it's a normal behavior that android conducts. I am trying to acquire known wake lock(partial or WIFI lock) to stop USB controller from sleeping ... but, currently, little progress. is there any usb-related wake lock, just like wifi lock ?
I have solved the problem from the perspective of HW .... I am not sure the solution is really meaningful to the current topic. But I think that sharing the idea with you is the major goal of the forum running.
a MOS component is added along the power line controlling Screen. Then I manipulate the connection/disconnection by sending command to MCU....
Based on my experiences , it is really hard to extend functionality on a poor quality of pad ... poor post-sales support.......
Hope you it's helpful to you.
I'm currently working on an android project and I am trying to find the best way to go about setting up communication between two android phones.
One android phone will be docked on a mobile platform e.g. an R/C car. I want this phone to receive simple control signals ("forward", "backward", "left", "right", "gotoCoordinate") sent from another android phone. I also want the docked phone to be able to return status signals.
Preferably I want the communication to happen via GPRS. I'm aware of the difficulties concerning P2P-communications and I'm currently looking into "Android Cloud To Device Messaging." (http://code.google.com/android/c2dm/index.html)
I'd like to hear about your experience with Android C2DM (glad to hear about delay from transmit to receive) and your thoughts on utilizing it in my project. I'd appreciate other suggestions on how to go about this. I'm expecting to have to deal with relatively high latency using this method, but of course preferably lowest possible.
C2DM makes no guarantee about the "delivery or order" of the messages, and it is limited in the number of messages you can send (a high limit, but still a limit). It's not really for low-latency stuff like controlling an RC car. It's better for non-realtime events.
http://code.google.com/android/c2dm/
For lower latency stuff using GPRS you can setup a third party server on your own and have both phones communicate through it. I've done that for several Android apps using straight up TCP sockets and it works reasonably well (and it would be even faster/better if you went UDP). Using GPRS may still have too much latency, depending on your needs, but it's a tradeoff (it's very convenient, almost always there, other methods are not).
The ideal way to do this would be to combine whatever is available and fallback gracefully, and test the latency once connected to make sure the network is up to par, or bail out. For example, use the local WiFi network if it's available. That is to say, have both devices "register" with a third party server as they startup, then if they're both on the same WiFi just have them communicate directly (run a server on or both, and clients on one or both, get information about discovery and such from the registration). If they are not on WiFi then fall back to GPRS, but realize there will be more latency, of course. Finally, once any method has been established send some test messages to check latency.
I know this isn't really an "answer," it's more of a stream of consciousness about this, but it wouldn't fit in a comment, and I thought it might help ;).
(Full disclosure: I've worked on Android apps that connect multiple mobile devices and multiple TVs, some over GPRS, some Wifi, some directly. I work for a company (MOVL) that makes a platform for stuff like that, it's more focused on mobile-TV-mobile, but it supports mobile-mobile also. In all it's not too hard to do yourself with regular networking, the tricky part is getting the latency down and picking the correct method for each device.)