Page 1 of 1

Read device IP and device details via serial

Posted: 19 Nov 2020, 19:23
by Misiu
Hi all,
I'm trying to create a new version of flasher based on tasmotizer ( and nodemcu-pyflasher (

I've found one nice thing that I'd like to try first (I'm a beginner with Python)

I found this code that reads device IP via serial:

Code: Select all

class DeviceIP(QDialog):
    def __init__(self, port: QSerialPort):
        super(DeviceIP, self).__init__()

        self.setWindowTitle('Device IP address')

        self.ip = QLineEdit()
        font = self.ip.font()

        btn = QDialogButtonBox(QDialogButtonBox.Close)

        self.layout().addWidgets([self.ip, btn]) = b''

        self.port = port

        self.re_ip = re.compile(r'(?:\()((?:[0-9]{1,3}\.){3}[0-9]{1,3})(?:\))')

            self.port.write(bytes('IPAddress1\n', 'utf8'))
        except Exception as e:
            QMessageBox.critical(self, 'Error', f'Port access error:\n{e}')

    def read(self):
   += self.port.readAll()
            match ='utf8'))
            if match:
can I do a similar thing with EspEasy? Can I read device info via serial? I think this would be useful.

BTW can we flash ESP Easy via esptool ( if yes can someone post or link an instruction?

Re: Read device IP and device details via serial

Posted: 19 Nov 2020, 19:41
by TD-er
Yep ESPtool is also used in PlatformIO, so I know that should be usable

And it is also possible to read settings (not all) via serial.

For example the command "settings" will output quite a lot of information via serial like this:

Code: Select all

System Info
  IP Address    :
  Build         : 20111
  Name          : Breadboard
  Unit          : 93
  WifiSSID      : MikroTik2
  WifiKey       : TopSecret
  WifiSSID2     :
  WifiKey2      :
  Free mem      : 7176

Re: Read device IP and device details via serial

Posted: 20 Nov 2020, 12:50
by Misiu

thank you for the reply. Reading settings works perfectly :D

Now I need to dig into flashing code.

Tasmotizer has one feature that I like: The exe file is small and it is only a one-time download. You can flash by selecting a bin file or by release, after selecting that option the app will download the bin file and will flash the device.
The URL that has the release version is:
Do you plan to have a similar server for ESPEasy?

I've also noticed that when I listen on serial port (rate 115200) I get a lot of useful info:

Re: Read device IP and device details via serial

Posted: 20 Nov 2020, 14:23
by TD-er
About the plan for a download server, as that has become a bit more clear today.

Today I received a notice from Travis about their plans and pricing for the (compared to CI.
As you may have seen, the builds on lately are a lot less useful as their servers tend to be overloaded with work.
So a build may sometimes take over 24h to complete after it has been submitted.
Also the build servers themselves aren't really fast compared to modern hardware.
A typical build (on Travis servers) does take roughly 2h30m in compute cycles (e.g. 5 threads can build all in 30 minutes)
Just to compare, I can make a similar build on my dev computer in 12 minutes, so the Travis hardware isn't that fast either.

Their new "free" plan has 10'000 credits each month.
A build minute costs 10 credits, so this means in about 7 or 8 builds a month we're out of free credits.

As I was already looking for options to make a build server for "custom user builds", I now plan to also include a build setup for PR's and nightly builds to run on that server.
So in the near future there will be a build server + a hosted mirror for most requested binary files.

This will then be the go-to source for flash tools like you plan to make and also what we would like to have in the new UI.

Re: Read device IP and device details via serial

Posted: 20 Nov 2020, 14:32
by Misiu
@TD-ed thanks for the reply.
The first step is the flashing, then I'll think about downloading the binaries.

Why are you using Travis? I see many projects are switching from Travis to GitHub actions, even Arduino core is using them:
There is a migration guide: ... ub-actions

I'm not 100% sure, but for public repos Github Actions are totally free. maybe worth looking into it?

Re: Read device IP and device details via serial

Posted: 20 Nov 2020, 14:49
by TD-er
Misiu wrote: 20 Nov 2020, 14:32 [...]
I'm not 100% sure, but for public repos Github Actions are totally free. maybe worth looking into it?
Travis was already used when I joined the project.
And Travis is still free for open source public repos.

So that has not changed.
But what has changed recently is that Travis is currently taking a lot more time to process builds.
Not sure if that's a temporary thing, or maybe it has to do with shifting resources to a paid one or perhaps there is currently a lot more activity in open source projects.
After all, building resources are not free and have to be paid somehow, so I don't blame them to setup a paid plan.

Given Travis is still free for Open Source, technically there isn't a difference between Travis and GitHub Actions.
GitHub Actions may be faster in building right now, but that's no guarantee for the future as Travis was also very quick in building until a few months ago.

Like I said, building resources have to be paid somehow and I guess the same will apply for GitHub Actions.
Because of the support made by our Patreons there is some budget for this. But at the current pricing of the non free Travis, you can buy a server for less than 1 year of subscription with a lot more building power.

A CI/CD tool like Travis and probably GitHub Actions only act on development activity like PR's and merges.
But we also really would like to have a feature for users to ease building custom builds selecting the plugins they need.
For that we need to have some paid build service as I have not found anything out there for free.

Amazon AWS may also be an option, but it is really hard to get an idea of the true costs of a build service on AWS as they have so many parameters in their paid plan for CPU cycles, memory usage, needed storage, traffic, 95-percentile bandwidth, etc.

So that's why I am thinking about a build service/server and maybe also creating some Docker image to help out distribute the load where possible.