Skip to content

Working with a wired LAN #56

Closed
Closed
@atitoff

Description

@atitoff

Will the library work with a wired network, such as a ESP32 + ethernet LAN8720A?

Activity

kevinkk525

kevinkk525 commented on Mar 27, 2021

@kevinkk525
Contributor

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:

ESP8266 = platform == 'esp8266'
ESP32 = False
PYBOARD = platform == 'pyboard'
LINUX = True 

(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

atitoff commented on Mar 27, 2021

@atitoff
Author

Many thanks!
Your fork is working!
So far only tested on Linux

if platform == "linux":
    config["client_id"]="linux"
kevinkk525

kevinkk525 commented on Mar 27, 2021

@kevinkk525
Contributor

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

atitoff commented on Apr 10, 2021

@atitoff
Author

Debugged for Linux. Everything is working.
Transferred to the board ESP32. The wired lan and webrepl works. The MQTT does not start.

def mqtt_callback(topic, msg, retained):
    # if topic.startswith(b'dali/'):
    #     dali.receive_from_mqtt(topic, msg)
    print(topic, msg, retained)


async def mqtt_conn_handler(client):
    await client.subscribe('dali/#', 1)


mqtt = MQTT(host='192.168.1.107', user='alex', password='bh0020', subs_cb=mqtt_callback, conn_handler=mqtt_conn_handler,
            debug=True)


async def main():
    print('mqtt.connect')
    await mqtt.connect()
    print('mqtt.connected')
    # await dali.run(mqtt.client)
    
    await asyncio.sleep(1)
MPY: soft reboot
WebREPL daemon started on ws://0.0.0.0:8266
Started webrepl in normal mode
mqtt.connect
kevinkk525

kevinkk525 commented on Apr 10, 2021

@kevinkk525
Contributor

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

atitoff commented on Apr 10, 2021

@atitoff
Author

image

image

Later I will watch the Wireshark tcp exchange ...

kevinkk525

kevinkk525 commented on Apr 10, 2021

@kevinkk525
Contributor

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

atitoff commented on Apr 11, 2021

@atitoff
Author

ntptime works

print(ntptime.time())
await asyncio.sleep(5)

671432518
671432523
671432528
671432533

this works too

async def echo(reader, writer):
    data = await reader.read(100)
    print(data)
    writer.write(data)
    await writer.drain()
    writer.close()


async def main():
    asyncio.create_task(asyncio.start_server(echo, "192.168.1.34", 8034))
kevinkk525

kevinkk525 commented on Apr 11, 2021

@kevinkk525
Contributor

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

atitoff commented on Apr 11, 2021

@atitoff
Author

Ok, I'll try.
I did not turn on the wireless interface.

boot.py

import esp

esp.osdebug(None)
import webrepl
import machine
import network

lan = network.LAN(mdc=machine.Pin(23), mdio=machine.Pin(18), power=machine.Pin(16), phy_type=network.PHY_LAN8720,
                  phy_addr=1, clock_mode=network.ETH_CLOCK_GPIO0_IN)
lan.active(True)
lan.ifconfig(('192.168.1.34', '255.255.255.0', '192.168.1.1', '192.168.1.1'))
webrepl.start()
kevinkk525

kevinkk525 commented on Apr 11, 2021

@kevinkk525
Contributor

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

atitoff commented on Apr 11, 2021

@atitoff
Author
import esp
esp.osdebug(None)
import webrepl
import machine
import network


wlan = network.WLAN(network.STA_IF)
ap = network.WLAN(network.AP_IF)
wlan.active(False)
ap.active(False)

lan = network.LAN(mdc=machine.Pin(23), mdio=machine.Pin(18), power=machine.Pin(16), phy_type=network.PHY_LAN8720,
                  phy_addr=1, clock_mode=network.ETH_CLOCK_GPIO0_IN)
lan.active(True)
lan.ifconfig(('192.168.1.34', '255.255.255.0', '192.168.1.1', '192.168.1.1'))
# webrepl.start()

Implemented asyncio TCP echo server

async def echo(reader, writer):
    data = await reader.read(100)
    print(data)
    writer.write(data)
    await writer.drain()
    writer.close()


async def main():
    asyncio.create_task(asyncio.start_server(echo, "192.168.1.34", 8034))

Only the first 8 sessions work. Then the port is closed. Sessions are normal. Here is one session for an example

image

I'll try later without async

kevinkk525

kevinkk525 commented on Apr 11, 2021

@kevinkk525
Contributor

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

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @peterhinch@kevinkk525@spacemanspiff2007@atitoff@beetlegigg

        Issue actions

          Working with a wired LAN · Issue #56 · peterhinch/micropython-mqtt