You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since this library controls the WLAN component directly, it can't be used with a wired network (as it is). But it shouldn't be difficult to adapt it for a wired network.
The easiest way might be to use my fork which has unix port support, which means I already made changes to have it working without any network interface (because the unix port doesn't have a network interface). This might already be enough to work with a wired network if you start/connect that network manually before starting the library and if that network is stable and doesn't need any manual reconnects of the network interface. So for testing you'd just need to replace the platform strings to "simulate" having a linux platform so no WLAN is being used:
Note that I have never worked with a wired LAN and I don't know if manual (re-)connects might be needed if the network adapter drops/loses the connection. In that case you'd need to program a workaround to reconnect the LAN and make a change to the constructor that lets you define the network interface so you can choose between WLAN and LAN.
Is the webrepl reachable? Because it doesn't show the real ip Adress in what you posted.
Can you connect to your broker manually using socket.socket()?
Webrepl runs as a server so maybe it behaves differently than outgoing connections. Does ntptime sync work or general network connections? Eg dns lookups
Did you disable both wlan interfaces?
Looks line ntptime uses udp sockets. Can you test normal sockets? Just connect them to the broker like the examples of an echo client for python.
It's not surorising to me that servers work, they care less about where a connection comes from, while an outgoing connection might try to use a different interface. Did you explicitly disable wlan interfaces?
Not turning it on doesn't necessarily mean it is off. Often it is needed to explicitly disable the wireless ap. So maybe try with st.active(False) and ap.active(False)
As mentioned in my earlier replies, please test the echo CLIENT or just a simple, manual outgoing tcp connection to a server (either python echo server on your PC or to your mqtt broker directly) to see if outgoing connections work correctly.
We already established that incoming connections work.
Activity
kevinkk525 commentedon Mar 27, 2021
Since this library controls the WLAN component directly, it can't be used with a wired network (as it is). But it shouldn't be difficult to adapt it for a wired network.
The easiest way might be to use my fork which has unix port support, which means I already made changes to have it working without any network interface (because the unix port doesn't have a network interface). This might already be enough to work with a wired network if you start/connect that network manually before starting the library and if that network is stable and doesn't need any manual reconnects of the network interface. So for testing you'd just need to replace the platform strings to "simulate" having a linux platform so no WLAN is being used:
(My fork: https://github.com/kevinkk525/micropython-mqtt Note that the constructor works slightly different, check the README. Apart from that, it's pretty much a drop-in replacement)
atitoff commentedon Mar 27, 2021
Many thanks!
Your fork is working!
So far only tested on Linux
kevinkk525 commentedon Mar 27, 2021
Note that I have never worked with a wired LAN and I don't know if manual (re-)connects might be needed if the network adapter drops/loses the connection. In that case you'd need to program a workaround to reconnect the LAN and make a change to the constructor that lets you define the network interface so you can choose between WLAN and LAN.
atitoff commentedon Apr 10, 2021
Debugged for Linux. Everything is working.
Transferred to the board ESP32. The wired lan and webrepl works. The MQTT does not start.
kevinkk525 commentedon Apr 10, 2021
Is the webrepl reachable? Because it doesn't show the real ip Adress in what you posted.
Can you connect to your broker manually using socket.socket()?
atitoff commentedon Apr 10, 2021
Later I will watch the Wireshark tcp exchange ...
kevinkk525 commentedon Apr 10, 2021
Webrepl runs as a server so maybe it behaves differently than outgoing connections. Does ntptime sync work or general network connections? Eg dns lookups
Did you disable both wlan interfaces?
atitoff commentedon Apr 11, 2021
ntptime works
this works too
kevinkk525 commentedon Apr 11, 2021
Looks line ntptime uses udp sockets. Can you test normal sockets? Just connect them to the broker like the examples of an echo client for python.
It's not surorising to me that servers work, they care less about where a connection comes from, while an outgoing connection might try to use a different interface. Did you explicitly disable wlan interfaces?
atitoff commentedon Apr 11, 2021
Ok, I'll try.
I did not turn on the wireless interface.
boot.py
kevinkk525 commentedon Apr 11, 2021
Not turning it on doesn't necessarily mean it is off. Often it is needed to explicitly disable the wireless ap. So maybe try with st.active(False) and ap.active(False)
atitoff commentedon Apr 11, 2021
Implemented asyncio TCP echo server
Only the first 8 sessions work. Then the port is closed. Sessions are normal. Here is one session for an example
I'll try later without async
kevinkk525 commentedon Apr 11, 2021
As mentioned in my earlier replies, please test the echo CLIENT or just a simple, manual outgoing tcp connection to a server (either python echo server on your PC or to your mqtt broker directly) to see if outgoing connections work correctly.
We already established that incoming connections work.
33 remaining items