We’ve replicated the NO_TX issue and we’re working on a fix and improvements to our system tests - we work pretty hard on these to ensure no regressions so this escape is notable & serious. The imp is not sinking any current (the TX pin is correctly tristated) but RX events cause issues.
In the meantime, note that you do not need to use NO_TX; you can configure the serial port with RX/TX and then reconfigure the TX pin after this point - you then claim the function away from the UART.
@takissd Would appreciate more details (your device IDs, description of the code you’re running, when devices are going offline, do multiple devices at the same site hit issues at the same time, etc) to dev-team@electricimp.com
Release 30 has updated WiFi drivers, which should only be better than the previous ones (in theory), but they are different.
Layers above that have not changed since release 27 (eg, TCP keepalive behavior, etc) and we’ve not seen any regression in devices being able to stay connected.
"In the meantime, note that you do not need to use NO_TX; you can configure the serial port with RX/TX and then reconfigure the TX pin after this point - you then claim the function away from the UART."
I tried changing NO_TX to 0 (RX/TX), ie no flags, but still the same problem, so just changed it to the NO_CTSRTS and what with the
I’m having what I think is an issue similar to @ takissd. Is there any easy way to determine what (connection?) problem is being experienced by device 20000c2a6906bb7a (I’m assuming there’s no risk in publicizing a device ID!)? It seems to run just fine for hours and then goes offline for no apparent reason. It’s at a client site on a hidden WiFi network with the claim of no network issues and no network changes. A simple power cycle brings the device (imp002) back online. This occurred yesterday morning and again early last evening ( 18:25 EDT). I’m heading there to reboot it in a few minutes.
like i said before, i also see more random “WiFi-Outage” Errors as before.
Nothing changed at the WiFi side of my Network. My Log says this:
`Aug 28 22:30:59 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 IEEE 802.11: disassociated due to inactivity
Aug 28 22:31:00 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Aug 28 22:34:50 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 IEEE 802.11: authenticated
Aug 28 22:34:50 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 IEEE 802.11: associated (aid 1)
Aug 28 22:34:50 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 RADIUS: starting accounting session 53FCE4CF-00000092
Aug 28 22:34:50 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 WPA: pairwise key handshake completed (RSN)
Aug 29 05:21:35 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 IEEE 802.11: disassociated due to inactivity
Aug 29 05:21:36 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Aug 29 05:25:22 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 IEEE 802.11: authenticated
Aug 29 05:25:22 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 IEEE 802.11: associated (aid 1)
Aug 29 05:25:22 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 RADIUS: starting accounting session 53FCE4CF-000000A6
Aug 29 05:25:22 x.x.x.x hostapd: ath0: STA 0c:2a:69:00:07:96 WPA: pairwise key handshake completed (RSN)
`
In the past, this was every time in relation with WMM and WMM PowerSave. Changing to IEEE 802.11g solved the issue but slows down the entire WiFi. Because WMM is absolutely needed for IEEE 802.11n you can’t turn it off on most standard WiFi AP’s with factory firmware. I didn’t actually tested it, but in the past i could see improvements when i’am disable powersavemode at the Imp.
On the UART thing: the workaround is to add NO_CTSRTS to the flags, even though yes there’s no RTS or CTS lines on that UART in the first place. Alternatively a fixed improm should be along shortly.
Hello Hugo, i have send the email with the info, please take a look at it. Once again, different networks (different locations) and devices used to work perfect before the update.
Thanks
@chrischi Does your code manage the connection? If so, can you give details on how you’re doing it? (ie, if you’re using server.connect(), what timeout are you using?)
@ctmorrisonhvacsp Same question. I see your device giving up on the connection and reconnecting regularly.
Could you try adding this code to the top of your device code? This implements basic connection management in that it connects when the device starts and if the connection goes away it will continuously retry the connection.
server.setsendtimeoutpolicy(RETURN_ON_ERROR, WAIT_TIL_SENT, 60); function reconnect(v) { if (v != SERVER_CONNECTED) server.connect(reconnect, 60); } server.onunexpecteddisconnect(function(v) { reconnect(v); }); reconnect(NOT_CONNECTED);
This code is only to keep devices online; if you have a device that sleeps and wakes this shouldn’t be required. Do you have a sleeping device that fails to appear with release 30?
Release 30.15 has now been pushed to all developer devices
Thanks go to Chrischi and takissd who set up debug rigs remotely (imps monitoring other imps) that allowed us to replicate the issue regularly enough to find the problem quickly.
This release has the uart issue addressed, bugs related to connection maintenance fixed, and also will more quickly recover if the wifi chip crashes.
