Help me find a GUI that works with "Ethernet2.h"

Projects General Guidance
1

Hi guys.

We are searching for some GUI software which is able to communicate with an Arduino Leonardo ETH, which uses the "Ethernet2.h" in applications.

We have tried the Azande GUI and Device Druid, but even though the developer was very helpful in modifiying his own code to communicate with Ethernet, we never get it to work with the updated "Ethernet2.h". Device Druid didn't have a code that worked for our project either.

Now, I've use this site as reference:

https://playground.arduino.cc/Main/InterfacingWithSoftware

But either they use serial commonication, or they use Bluetooth or wi-fi, which isn't what we are looking for. We are not interested in a GUI-solution, which you can control from your smartphone.

So what should our GUI software be able to do?
(Will spare you for all details, but just try to give a simplified explantion)

Well, first of all we use the Leonardo ETH board, which is mounted at 2-300 meters depth in the ocean. The Arduino must be able to turn on/off LED lamps in the ocean via a relay module. Just simple "high" or "low" command to a relay.
Earlier we used an embedded website on the board to turn on/off outputs, but we dont want to use browser control (f.ex. Google Chrome) anymore because of some problems with that solution.

Also - if the GUI software if able to dim LED lights via PWM, that would be extra awesome.

So what do you think ? Do you know of a GUI-program that could work with "Ethernet2.h" after reading the above?

Any inputs are welcome :slight_smile:

Thanks.

2

Earlier we used an embedded website on the board to turn on/off outputs, but we dont want to use browser control (f.ex. Google Chrome) anymore because of some problems with that solution.

What problems ?
Why not fix them rather than looking for alternatives ?

3

You don't need to use Ethernet2 anymore. The latest release of the Arduino Ethernet library will work fine with your Leonardo ETH. I'm not sure why the Ethernet library would work but not the Ethernet2 library, but that's what I understand you to be saying.

4

marengsen:
Earlier we used an embedded website on the board to turn on/off outputs, but we dont want to use browser control (f.ex. Google Chrome) anymore because of some problems with that solution.

It seems to me you have two options. Either the Arduino runs the server software and the client is at the user end. Or the Arduino runs the client software and the server is at the user end.

If you have already written a working server program for the Arduino it seems sensible to stick with that. if for some reason you don't want to use an off-the-shelf browser such as Chrome then you can easily write a client program using, for example, Python. But the complicated part of writing a program is usually the business of creating the GUI. Personally I find it much simpler to use a browser program to provide the GUI.

What problems have you had using Chrome?

...R

5

Robin2:
It seems to me you have two options. Either the Arduino runs the server software and the client is at the user end. Or the Arduino runs the client software and the server is at the user end.

If you have already written a working server program for the Arduino it seems sensible to stick with that. if for some reason you don't want to use an off-the-shelf browser such as Chrome then you can easily write a client program using, for example, Python. But the complicated part of writing a program is usually the business of creating the GUI. Personally I find it much simpler to use a browser program to provide the GUI.

What problems have you had using Chrome?

...R

Hi there - thanks for your answer.

A super short explanation about our project is this:
We are filming the bottom of the ocean, in 1080p60FPS. We are using an Arduino to control LED lamps for the camera, and activate laser modules to give some distance on the recorded movie. Think of it as a type of ROV, which doesn't have motors or propellers, but is being dragged after a research vessel, through a 500 meter reinforced coax-cable.

The problem with using Chrome is a bit hairy to explain, but I'll do my best below.
I have left out some technical details to spare you from more confusion. :slight_smile:

Lets say the whole system was up and running. I loaded chrome and typed in the IP-address for the Arduino.

The embedded website pops up, showing tow buttons and their state (as text), to turn on/off LED lamps and lasers. If I click "ON", the LED turns on. If I click "OFF" the LED lamps turns off. The same for the lasers.

Next the arduino-code was built in such a way, that in order to check the on/off state of the lamps and lasers; the Chrome browser would refresh every 4 seconds, so it could update the text under the button, showing if devices are ON or OFF. Not sure if this is the right way to do it.

Now, lets pretend we are looking at the website, with LEDs "ON" and the power for the Arduino disappears, which can happen in our project (f.ex. due to user-mistakes - longer explanation). After some seconds, Chrome goes "offline", saying the embedded website is down, which is true.

When the power for the arduino comes back on, the arduino boots up again. In our code we have done so that the relay for the LEDs and lasers should be "OFF" from the beginning, but Chrome can sense the website is back on, and reloads the last page it knew, which is quite fine for normal website-browsing, but not in our case. Even though we set the relay to "OFF" on a fresh boot, the website overwirtes this and suddenly the relay is "ON".

When the "ROV" is being dragged on deck, we dont want the end-users (fishermen) to risk being hit by the lasers or LED lamps , but it has happned before.

And that's basically the problem here. We tried to stop Chrome or Firefox to reload a last known page if the power supply for the ROV is turned off (which is totally fine), and bunch of other settings, but it never quite worked.

So you could say we have two refreshing things going on.. one every 4 seconds in the code, to check state of the buttons, so to speak, and Chrome refreshing the last known page before the website went offline (which is the true problem). Even if Chrome doesn't reload the page automatically after arduino boots up again, when you click the link we made for the website, it still does this.

I'm still not sure if this is sort of a buffer "problem" in Chrome or whats going on, but we tried to disable anything in Chrome that looked like cookies or what looked like other "memory-stuff".

Not sure if any of this makes sense, but please write back if I need to explain it a bit better.

Thanks!

6

marengsen:
Now, lets pretend we are looking at the website, with LEDs "ON" and the power for the Arduino disappears ...

There are probably many ways to deal with your concern.

The way I would do it is to build a simple Python webserver (using the Bottle web framework) and build the Arduino program as a client that makes requests to the server at regular intervals.

It is easy to write Python code to deal with the potential failure of the Arduino response without getting mixed up.

And I would use the same Python program to present the GUI to the Chrome browser - but Chrome would just be a display and input system with no involvement in the system "control"

If you don't like Python you can do the same sort of thing with Ruby and Sinatra and almost certainly with any other programming language.

...R

7

did you try header "Cache-Control: no-store"?

8

Hello marengsen,

I know noting about under water RoVs but your project fascinates me! I can't help you with the web stuff but this stuck out as needing a comment:

When the "ROV" is being dragged on deck, we don't want the end-users (fishermen) to risk being hit by the lasers or LED lamps , but it has happened before.

I would have thought that relying on a remotely provided signal to provide this kind of safety protection would be unwise, regardless of the kind of remote signal. I would have thought some kind of interlock on the RoV would be appropriate, for example a pressure switch that prevents the lasers and lamps coming on until the RoV is some particular depth under the water, or maybe a big manually operated switch that those handling the RoV must operate as they put it in to and take it out of the water.