Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mDNS failing. And what port is Openmrnlite listening to? #1

Open
dsj782 opened this issue Oct 17, 2019 · 10 comments
Open

mDNS failing. And what port is Openmrnlite listening to? #1

dsj782 opened this issue Oct 17, 2019 · 10 comments

Comments

@dsj782
Copy link

dsj782 commented Oct 17, 2019

First, what TCP port is OpenMRNlite listening to? I can ping the ESP32, but not sure which port I should configure in JMRI. (using the WiFi option).

Second, code uploads, starts, but then I get this:
Updating CDI file /spiffs/cdi.xml (len 6089)
[WiFiMgr] Starting WiFi Manager task
[WiFi] Starting TCP/IP stack
[WiFi] Initializing WiFi stack
[WiFi] Configuring WiFi stack
[WiFi] Starting WiFi stack
[WiFi] [1/36] Waiting for SSID connection.
[WiFi] Setting ESP32 hostname to "esp32_50101011823".
[WiFi] Starting DHCP services.
[WiFi] Station started, attempting to connect to SSID: MOTO8F3C.
Allocating new alias 8E5 for node 050101011823
[WiFi] Connected to SSID: MOTO8F3C
[DHCP] [2/36] Waiting for IP address assignment.
[WiFi] IP address is 192.168.99.43, starting hub (if enabled) and uplink.
[mDNS] Initializing mDNS system
[mDNS] Setting mDNS hostname to "esp32_50101011823"
[Uplink] Starting mDNS searching for _openlcb-can._tcp.
[mDNS] No matches found for service: _openlcb-can._tcp.
[Uplink] mDNS search failed.
[Uplink] Starting mDNS searching for _openlcb-can._tcp.
[mDNS] No matches found for service: _openlcb-can._tcp.
[Uplink] mDNS search failed.
[Uplink] Starting mDNS searching for _openlcb-can._tcp.
[mDNS] No matches found for service: _openlcb-can._tcp.
[Uplink] mDNS search failed.
[Uplink] Starting mDNS searching for _openlcb-can._tcp.
[mDNS] No matches found for service: _openlcb-can._tcp.
[Uplink] mDNS search failed.
[Uplink] Starting mDNS searching for _openlcb-can._tcp.
[mDNS] No matches found for service: _openlcb-can._tcp.
[Uplink] mDNS search failed.
[Uplink] Starting mDNS searching for _openlcb-can._tcp.
[mDNS] No matches found for service: _openlcb-can._tcp.
[Uplink] mDNS search failed.
[Uplink] Starting mDNS searching for _openlcb-can._tcp.
[mDNS] No matches found for service: _openlcb-can._tcp.
[Uplink] mDNS search failed.
Over and over.

Any ideas what is going on?

@atanisoft
Copy link

The default behavior for the ESP32 is not to enable the HUB mode in the CDI. This is due primarily to the ESP32's performance on TCP/IP as a HUB leads to lost CAN frames and timeouts. You CAN enable it via the JMRI CDI editor BUT it will very likely have performance issues.

The mDNS behavior you are seeing is expected as the ESP32 is searching for a HUB that advertises itself as providing "_openlcb-can._tcp". Since it is not finding anything advertising that service it retries the search after a few seconds.

@dsj782
Copy link
Author

dsj782 commented Oct 18, 2019 via email

@atanisoft
Copy link

We currently have CMRI and it looks like both will be used on our layout.I would like to have the ESP32 talking to JMRI vi a network interface/WiFi.

Often times groups will start with a mixture of LCC and non-LCC components and over time migrate exclusively over to one system. As for JMRI talking to the LCC side via WiFi, that would be easiest using a rPi as the LCC hub. This can be done using the OpenMRN hub application. JMRI will talk to the hub and the ESP32 nodes should be able to find it via mDNS and connect.

I can convert CMRI to MQTT and MQTT to CMRI, using an USB attached ESP32, with MadLeech's library.

Depending on the type of CMRI IO nodes you are using, you might be able to directly swap in an ESP32 as an LCC IO device to bridge the two systems.

Maybe do the same with LCC to MQTT/MQTT to LCC?

I'm not sure there is much benefit in doing this or if it is even feasible.

@atanisoft
Copy link

I've replicated the mDNS publish failure on the latest ESP-IDF/Arduino-ESP32 and have filed espressif/esp-idf#4217. I'll be looking at options to improve this in the default configurations.

@balazsracz
Copy link
Member

I think there is a true missing feature here, namely that it is difficult to connect to a device that has been freshly flashed. Once the user had a chance to edit the configuration, there are a number of features that exist and useful:

  • the hub can be turned on which allows a remote JMRI to connect to the esp32
  • the uplink can be enabled with a fixed IP and port number, connecting to another hub that does not have mDNS (including a builtin hub in JMRI).

However, all of these are only achievable if the user can edit the configuration. That is only possible if the user managed to connect a JMRI to the esp32 network. So this is a chicken-and-egg problem.

I see a few ways to get out of this:

  1. enable the hub listener to be on by default (we should not be advertising it via mdns as default though -- tat should be a setting with default off).
  2. use the serial port via gridconnect and have the option to enable that (from code). Then JMRI can be connected as if it was a USB-CAN adapter and the config can be set that way.
  3. add functions to connect to remote hub or have a way in the code to set the default fallback connection to the remote hub.

@atanisoft
Copy link

I agree, there is a missing piece here. I'm not certain that enabling the hub mode is a good idea as the ESP32 has a hard time with serving the CDI when operating as a hub. From my testing it has less than a 50% success rate and when it doesn't load the SSID connection goes down and can not recover without a reset (bug in WiFi driver, Espressif already working on a fix).

Of the three options you have proposed the best would likely be the third. A fourth option to consider would be port my StateFlow httpd/dns code over to OpenMRN (uses BSD sockets so it is portable) and expose a version of the node config UI shown in JMRI but only for "this" node.

@balazsracz
Copy link
Member

balazsracz commented Oct 20, 2019 via email

@atanisoft
Copy link

JMRI node config dialog rendered as HTML directly on the ESP32, similar to this:
image
But rendered in a dynamic fashion based on the CDI.xml.

@dsj782
Copy link
Author

dsj782 commented Oct 23, 2019 via email

@atanisoft
Copy link

  1. The differences between an ESP8266 and ESP32. The ESP32 has a built in can controller, the esp8226 does not

One other critical difference of the two, the esp32 is a dual core 240MHz SoC vs single core 80MHz SoC.

How to setup the CDL screens.

The node itself provides an XML document to JMRI which generates the UI fields dynamically. The XML document describes the node's configurable attributes (name, description, IO, etc). As for using the CDI UI, that would be very node and task specific.

How to add more i/o ports.

The ESP32IOBoard example defines 8 pins for input and 8 pins for output. There are a few other pins available on the ESP32 but there may be some restrictions on their usage. It is possible to use an I2C GPIO expander but there is currently no example for this or the support code for it (though I've seen it done with the OpenMRN stack).

What and where is "print_all_packets()?

This method is defined here. It adds a DisplayPort instance to the stack which prints the CAN packets as they are sent/received. Something similar to this could be used for your CAN -> MQTT bridge but a different approach would be required for MQTT -> CAN.

While I like LCC, it does have a few drawbacks.

What drawbacks have you found? I can agree with @balazsracz that there is a gap in the current offering of OpenMRNLite in that you can not easily specify the default behavior of the node when operating only on WiFi. This is something I'd like to improve upon after evaluating the full set of options available to us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants