RPIEasy

Moderators: Voyager, BertB, rtenklooster, Stuntteam, grovkillen, TD-er

Message
Author
User avatar
enesbcs
Normal user
Posts: 295
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: RPIEasy

#51 Post by enesbcs » 11 Jan 2019, 18:19

iron wrote:
11 Jan 2019, 10:17
I am having difficulty uploading the MQTT cert file via the <ip>/filelist page. I can upload a .jpg and a .txt but not the TLS.pem, file even after I renamed it to TLS.txt
I'm opened /filelist just now from RPIEasy hosted by a Raspberry Pi Zero W.
(As browser i used a Firefox v63.0 on a desktop Ubuntu Linux OS.)
Clicked to Upload, browsed a "TLS.pem" file (~1.5kb size) from my desktop, clicked Upload, and TLS.pem appeared at the RPIEasy files/ directory with no problem.
To investigate it, please feel free to open a new issue at the github.
1. Update your RPIEasy from Github
2. Set Tools->Advanced->Web Log level to "Debug"
3. Retry uploading the problematic file and post the logs. (Also describe details about the OS, browser, complete path name of the file on your system, and attach the problematic file if possible)

User avatar
iron
Normal user
Posts: 67
Joined: 24 Sep 2016, 08:37
Location: Veria, Greece
Contact:

Re: RPIEasy

#52 Post by iron » 11 Jan 2019, 19:16

enesbcs wrote:
11 Jan 2019, 18:19
iron wrote:
11 Jan 2019, 10:17
I am having difficulty uploading the MQTT cert file via the <ip>/filelist page. I can upload a .jpg and a .txt but not the TLS.pem, file even after I renamed it to TLS.txt
I'm opened /filelist just now from RPIEasy hosted by a Raspberry Pi Zero W.
(As browser i used a Firefox v63.0 on a desktop Ubuntu Linux OS.)
Clicked to Upload, browsed a "TLS.pem" file (~1.5kb size) from my desktop, clicked Upload, and TLS.pem appeared at the RPIEasy files/ directory with no problem.
To investigate it, please feel free to open a new issue at the github.
1. Update your RPIEasy from Github
2. Set Tools->Advanced->Web Log level to "Debug"
3. Retry uploading the problematic file and post the logs. (Also describe details about the OS, browser, complete path name of the file on your system, and attach the problematic file if possible)
FF "solved" the upload issue (Chrome still doesn't)

Connected to :

mqtt.gbridge.kappelt.net
MQTT server: mqtt.gbridge.kappelt.net
MQTT port: 8883
MQTT protocol: Version 3.1
TLS: TLS V1.2

MQTT.fx connects to it

Device log shows disconnects

19:36:06 Event: GenMQTT#Connected
19:36:06 Event: GenMQTT#Disconnected

-D
-D

User avatar
enesbcs
Normal user
Posts: 295
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: RPIEasy

#53 Post by enesbcs » 11 Jan 2019, 21:11

iron wrote:
11 Jan 2019, 19:16
FF "solved" the upload issue (Chrome still doesn't)
Thank you for this information I can reproduce this bug with Chrome, and created a new issue for it.
iron wrote:
11 Jan 2019, 19:16
Connected to :

mqtt.gbridge.kappelt.net
MQTT server: mqtt.gbridge.kappelt.net
MQTT port: 8883
MQTT protocol: Version 3.1
TLS: TLS V1.2

MQTT.fx connects to it

Device log shows disconnects

19:36:06 Event: GenMQTT#Connected
19:36:06 Event: GenMQTT#Disconnected
I've used http://test.mosquitto.org/ for testing, but will try kappelt.net.

UDPATE: Refresh from Github then clear and readd you Controller Password, then Submit. I think issue will be fixed now.

User avatar
budman1758
Normal user
Posts: 208
Joined: 15 Apr 2017, 05:13
Location: Riverside CA USA

Re: RPIEasy

#54 Post by budman1758 » 12 Jan 2019, 19:47

This is a request for update instructions to add to the readme in the Git page. I have been using "git-pull" and then rebooting the Pi. Was wondering if there is an easier way to update without rebooting the PI. My be helpful for all users. Thanks. :D

Perhaps an update mechanism in the tools page? Should I make a Git issue?
"The glass is twice as big as it needs to be".

User avatar
enesbcs
Normal user
Posts: 295
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: RPIEasy

#55 Post by enesbcs » 12 Jan 2019, 20:29

budman1758 wrote:
12 Jan 2019, 19:47
This is a request for update instructions to add to the readme in the Git page. I have been using "git-pull" and then rebooting the Pi. Was wondering if there is an easier way to update without rebooting the PI. My be helpful for all users. Thanks. :D

Perhaps an update mechanism in the tools page? Should I make a Git issue?
If you are using the run.sh startup script (if "RPIEasy autostart at boot" checked, than run.sh is used for sure) then you can use "Tools->Exit"... after "git-pull". This way RPIEasy stopping itself, but run.sh kicks it back, so in fact it is not an exit, but a restart without rebooting the Pi. :)
Issue for some kind of update mechanism can be add, but will be tagged as "ETA: Next stable release", this is still a beta.

User avatar
iron
Normal user
Posts: 67
Joined: 24 Sep 2016, 08:37
Location: Veria, Greece
Contact:

Re: RPIEasy

#56 Post by iron » 14 Jan 2019, 18:36

enesbcs wrote:
11 Jan 2019, 21:11
iron wrote:
11 Jan 2019, 19:16
FF "solved" the upload issue (Chrome still doesn't)
Thank you for this information I can reproduce this bug with Chrome, and created a new issue for it.
iron wrote:
11 Jan 2019, 19:16
Connected to :

mqtt.gbridge.kappelt.net
MQTT server: mqtt.gbridge.kappelt.net
MQTT port: 8883
MQTT protocol: Version 3.1
TLS: TLS V1.2

MQTT.fx connects to it

Device log shows disconnects

19:36:06 Event: GenMQTT#Connected
19:36:06 Event: GenMQTT#Disconnected
I've used http://test.mosquitto.org/ for testing, but will try kappelt.net.

UDPATE: Refresh from Github then clear and readd you Controller Password, then Submit. I think issue will be fixed now.
I could never connect to kappelt.

I just connected to cloudMQTT without security and I can publish / subscribe.

Yet in the log :

19:32:01 Event: GenMQTT#Connected
19:32:07 Unit alive: 3
19:32:07 Unit alive: 3
19:32:07 Unit alive: 3
19:32:14 Unit alive: 1
19:32:14 Unit alive: 1
19:32:14 Unit alive: 1
19:32:26 Unit alive: 2
19:32:26 Unit alive: 2
19:32:26 Unit alive: 2
19:32:26 MQTT connection error: 5

Although I am connected to cloudMQTT !!!

-D
-D

User avatar
enesbcs
Normal user
Posts: 295
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: RPIEasy

#57 Post by enesbcs » 14 Jan 2019, 21:53

iron wrote:
14 Jan 2019, 18:36
Yet in the log :

19:32:01 Event: GenMQTT#Connected
19:32:07 Unit alive: 3
19:32:07 Unit alive: 3
19:32:07 Unit alive: 3
19:32:14 Unit alive: 1
19:32:14 Unit alive: 1
19:32:14 Unit alive: 1
19:32:26 Unit alive: 2
19:32:26 Unit alive: 2
19:32:26 Unit alive: 2
19:32:26 MQTT connection error: 5

Although I am connected to cloudMQTT !!!

-D
I've found a possible solution: MQTT servers do not like if password supplied after connect(). I applied a new variable to sign if password already applied and reverted back from connect_async() to simple blocking connect() method to make sure that disconnect will not arrive sooner than connect.

FYI: I can use cloudMQTT and kappelt.net MQTT servers without any problem.

seb82
Normal user
Posts: 10
Joined: 05 Sep 2018, 10:56

Re: RPIEasy

#58 Post by seb82 » 16 Jan 2019, 09:26

Just tested it on an old Raspberry 1 and it is really nice. I like it.

To keep everything consistent with other ESPEasy devices, would it be possible to take in account %tskname% and %valname% in the MQTT topics ? This is the default publish topic when selecting OpenHAB MQTT in ESPEasy : /%sysname%/%tskname%/%valname%

Thanks again

User avatar
iron
Normal user
Posts: 67
Joined: 24 Sep 2016, 08:37
Location: Veria, Greece
Contact:

Re: RPIEasy

#59 Post by iron » 16 Jan 2019, 12:46

enesbcs wrote:
14 Jan 2019, 21:53
iron wrote:
14 Jan 2019, 18:36
Yet in the log :

19:32:01 Event: GenMQTT#Connected
19:32:07 Unit alive: 3
19:32:07 Unit alive: 3
19:32:07 Unit alive: 3
19:32:14 Unit alive: 1
19:32:14 Unit alive: 1
19:32:14 Unit alive: 1
19:32:26 Unit alive: 2
19:32:26 Unit alive: 2
19:32:26 Unit alive: 2
19:32:26 MQTT connection error: 5

Although I am connected to cloudMQTT !!!

-D
I've found a possible solution: MQTT servers do not like if password supplied after connect(). I applied a new variable to sign if password already applied and reverted back from connect_async() to simple blocking connect() method to make sure that disconnect will not arrive sooner than connect.

FYI: I can use cloudMQTT and kappelt.net MQTT servers without any problem.
I moved from VM to RPi B+

Testing to cloudMQTT (no security)

This is the log :

11:44:44 Event: GenMQTT#Connected
11:45:01 Event: Clock#Time=Wed,11:45
11:45:03 MQTT connection error: 5 Invalid user/pass!
11:45:12 Event: GenMQTT#Disconnected

It can't be that difficult...

-D
-D

User avatar
iron
Normal user
Posts: 67
Joined: 24 Sep 2016, 08:37
Location: Veria, Greece
Contact:

Re: RPIEasy

#60 Post by iron » 16 Jan 2019, 15:31

I need to send the system for a reboot every time I make any changes to the MQTT settings to get rid of the "issues".
Gets connected... stays connected... no disconnects... no user/pass warnings...

This is so far for the non secure... moving along with a TLS connection... will report back.

-D
-D

User avatar
enesbcs
Normal user
Posts: 295
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: RPIEasy

#61 Post by enesbcs » 16 Jan 2019, 18:44

iron wrote:
16 Jan 2019, 15:31
I need to send the system for a reboot every time I make any changes to the MQTT settings to get rid of the "issues".
Gets connected... stays connected... no disconnects... no user/pass warnings...

This is so far for the non secure... moving along with a TLS connection... will report back.
I am very sorry, but it is not easy for me to solve an issue, that i am unable to reproduce. :(
I think there are some network connection issues behind it, if a disconnect notification arrives from mqtt broker, i thought it is logical that there are no connection.. and when arriving connect notification and broker sends error 5 with it, it is not at all certain that previous connection remained active or disconnected (or never connected)... i think i have to implement an own connection testing method, that is not relying on these callbacks.

User avatar
enesbcs
Normal user
Posts: 295
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: RPIEasy

#62 Post by enesbcs » 16 Jan 2019, 18:53

seb82 wrote:
16 Jan 2019, 09:26
Just tested it on an old Raspberry 1 and it is really nice. I like it.

To keep everything consistent with other ESPEasy devices, would it be possible to take in account %tskname% and %valname% in the MQTT topics ? This is the default publish topic when selecting OpenHAB MQTT in ESPEasy : /%sysname%/%tskname%/%valname%

Thanks again
Nice to hear it.

I am a little uncertain what do you need exactly.
Default setting is:

Code: Select all

%sysname%/#/state
When you change it to:

Code: Select all

/%sysname%/#
Then RPIEasy will automatically translate it to:
/%sysname%/taskname/valuename
with payload that contains the value.

Because "#" character will be replaced by taskname and valname automatically. This is the default behaviour of the Generic MQTT controller. I can implement %taskname% and %valuename% if the above is not working with OpenHab.

User avatar
iron
Normal user
Posts: 67
Joined: 24 Sep 2016, 08:37
Location: Veria, Greece
Contact:

Re: RPIEasy

#63 Post by iron » 17 Jan 2019, 10:02

enesbcs wrote:
16 Jan 2019, 18:44
iron wrote:
16 Jan 2019, 15:31
I need to send the system for a reboot every time I make any changes to the MQTT settings to get rid of the "issues".
Gets connected... stays connected... no disconnects... no user/pass warnings...

This is so far for the non secure... moving along with a TLS connection... will report back.
I am very sorry, but it is not easy for me to solve an issue, that i am unable to reproduce. :(
I think there are some network connection issues behind it, if a disconnect notification arrives from mqtt broker, i thought it is logical that there are no connection.. and when arriving connect notification and broker sends error 5 with it, it is not at all certain that previous connection remained active or disconnected (or never connected)... i think i have to implement an own connection testing method, that is not relying on these callbacks.
Why am I having such difficulties connecting to a secure MQTT ?

08:50:32 MQTT controller: mqtt.gbridge.kappelt.net:8883 connection failed

I use the same credentials on MQTTfx and all work at once with no issues...

What can I possible be doing wrong... you mentioned success with kappelt

A manual post returns :

08:58:17 CMD: publish gBridge/u326/d942/onoff,1
08:58:17 MQTT capable controller not found!

Which sounds reasonable as there is no connection established.

I use MQTTS/with cert and I point the "Server certificate file:" to the .pem file I previously uploaded

-D
-D

User avatar
iron
Normal user
Posts: 67
Joined: 24 Sep 2016, 08:37
Location: Veria, Greece
Contact:

Re: RPIEasy

#64 Post by iron » 17 Jan 2019, 16:46

Hello,

' Password1# ' seemed to be the issue.. changing it to ' Password1 ' (no ' # ' at the end) now works in the RPIeasy.

Parsing issue ?

-D
-D

User avatar
enesbcs
Normal user
Posts: 295
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: RPIEasy

#65 Post by enesbcs » 17 Jan 2019, 18:12

iron wrote:
17 Jan 2019, 16:46
Hello,

' Password1# ' seemed to be the issue.. changing it to ' Password1 ' (no ' # ' at the end) now works in the RPIeasy.

Parsing issue ?
This is very interesting.. there were "#" at the end of your password? And also a space: " "?
I do not do any parsing with the password, it is supplied to the Paho mqtt client without modifications. Except that JsonPickles library encodes all variables to the "data/controllers.json" file, which i have no influence over, as it is an external library.
UPDATE: I've tested, jsonpickles handle # characters without error, it may be located in the paho mqtt library.
UPDATE2: Paho Mqtt library does some strange (_pack_str16() is strange for me) utf-8 based conversions on the password string, but i do not see any problem there.
Altough "#" in Python has a special meaning.

Does that mean that MQTTS connection works with the new password?

seb82
Normal user
Posts: 10
Joined: 05 Sep 2018, 10:56

Re: RPIEasy

#66 Post by seb82 » 19 Jan 2019, 09:22

enesbcs wrote:
16 Jan 2019, 18:53
[...]
I am a little uncertain what do you need exactly.
[...]
Because "#" character will be replaced by taskname and valname automatically. This is the default behaviour of the Generic MQTT controller. I can implement %taskname% and %valuename% if the above is not working with OpenHab.
Indeed, my need was not very clear. In fact for publish topic I use %sysname%/%valname% for all my ESPEasy devices (ie without %tskname%). This was mainly for my home automation system (Jeedom with MQTT plugin) to avoid automatic creation of sub-devices. I also find it easier to read though this means being sure valname is unique (as I use this kind of name it is ok: t_room1, t_outdoor, ...).

If it is easy to implement %taskname% and %valuename% that would be great as it provides more flexibility. Otherwise, I can certainly survive without it :)

User avatar
enesbcs
Normal user
Posts: 295
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: RPIEasy

#67 Post by enesbcs » 19 Jan 2019, 10:57

seb82 wrote:
19 Jan 2019, 09:22
Indeed, my need was not very clear. In fact for publish topic I use %sysname%/%valname% for all my ESPEasy devices (ie without %tskname%). This was mainly for my home automation system (Jeedom with MQTT plugin) to avoid automatic creation of sub-devices. I also find it easier to read though this means being sure valname is unique (as I use this kind of name it is ok: t_room1, t_outdoor, ...).

If it is easy to implement %taskname% and %valuename% that would be great as it provides more flexibility. Otherwise, I can certainly survive without it :)
%tskname% and %valname% is now supported in C014. Altough the Command topic needs # sign also, this signs the end of the Subscribe topic. For ex: "%sysname%/#%valname%/set"

User avatar
iron
Normal user
Posts: 67
Joined: 24 Sep 2016, 08:37
Location: Veria, Greece
Contact:

Re: RPIEasy

#68 Post by iron » 19 Jan 2019, 11:07

enesbcs wrote:
19 Jan 2019, 10:57
seb82 wrote:
19 Jan 2019, 09:22
Indeed, my need was not very clear. In fact for publish topic I use %sysname%/%valname% for all my ESPEasy devices (ie without %tskname%). This was mainly for my home automation system (Jeedom with MQTT plugin) to avoid automatic creation of sub-devices. I also find it easier to read though this means being sure valname is unique (as I use this kind of name it is ok: t_room1, t_outdoor, ...).

If it is easy to implement %taskname% and %valuename% that would be great as it provides more flexibility. Otherwise, I can certainly survive without it :)
%tskname% and %valname% is now supported in C014. Altough the Command topic needs # sign also, this signs the end of the Subscribe topic. For ex: "%sysname%/#%valname%/set"
I s the cmd supported ?

%sysname%/#%valname%/cmd
with payload a command such as : gpio,<pin>,<state>

-D
-D

User avatar
enesbcs
Normal user
Posts: 295
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: RPIEasy

#69 Post by enesbcs » 19 Jan 2019, 17:07

iron wrote:
19 Jan 2019, 11:07
I s the cmd supported ?
%sysname%/#%valname%/cmd
with payload a command such as : gpio,<pin>,<state>
Yes, but the above will not work.
If you use this in the "Command topic"

Code: Select all

%sysname%/#%valname%/
Or even this:

Code: Select all

%sysname%/#%valname%/set
Then the controller will watch for:
%sysname%/cmd
and executes payload, for example gpio,<pin>,<state>
The # character marks the end of the subscribe topic. There are no reason for including the value name for this purpose.

The command topic serves other purpose, if you leave it as default:
%sysname%/#/set
then the controller will process all arriving messages for %sysname%/ and if it is ending with /set then tries to decode the TASKNAME and VALUENAME from the topic in the very same way, as the Report topic works, and tries to forward the incoming payload to this task. (if task is available) For obvious reasons this method may not work as expected, if not using the default topic templates.
But frankly i am a Domoticz user anyway, so i am not using it. :) I just pointed a method for using two way mqtt communication, which i am using with Domoticz MQTT.

User avatar
iron
Normal user
Posts: 67
Joined: 24 Sep 2016, 08:37
Location: Veria, Greece
Contact:

Re: RPIEasy

#70 Post by iron » 19 Jan 2019, 18:21

enesbcs wrote:
19 Jan 2019, 17:07
iron wrote:
19 Jan 2019, 11:07
I s the cmd supported ?
%sysname%/#%valname%/cmd
with payload a command such as : gpio,<pin>,<state>
Yes, but the above will not work.
If you use this in the "Command topic"

Code: Select all

%sysname%/#%valname%/
Or even this:

Code: Select all

%sysname%/#%valname%/set
Then the controller will watch for:
%sysname%/cmd
and executes payload, for example gpio,<pin>,<state>
The # character marks the end of the subscribe topic. There are no reason for including the value name for this purpose.

The command topic serves other purpose, if you leave it as default:
%sysname%/#/set
then the controller will process all arriving messages for %sysname%/ and if it is ending with /set then tries to decode the TASKNAME and VALUENAME from the topic in the very same way, as the Report topic works, and tries to forward the incoming payload to this task. (if task is available) For obvious reasons this method may not work as expected, if not using the default topic templates.
But frankly i am a Domoticz user anyway, so i am not using it. :) I just pointed a method for using two way mqtt communication, which i am using with Domoticz MQTT.
The # in my %sysname%/#%valname% was a typo meant it to be %sysname%/%valname%, sorry.

When I flip a gpio such as: gpio,5,1 I only get the payload "1" reported back but not the path "5" the payload belongs to.

I am subscribed via MQTTfx @ (kappelt) gBridge/u326/# (where I see all events passed the last /). Upon initial connection of the Generic MQTT to it I see a "PING" payload under gBridge/u326/Status.
When I trigger the gpio gpio,5,1 one would expect the payload to show under the pin number path such as gBridge/u326/5 with paylod of 1 but I only see gBridge/u326/ with payload of 1
This way I am not aware of the gpio that reported its value.

At least this is how the default ESPEASY works.

BTW I can not trigger a gpio w/o declaring it in the Tasks first ? (even after I set it as output at /pinout) ?

-D
-D

User avatar
iron
Normal user
Posts: 67
Joined: 24 Sep 2016, 08:37
Location: Veria, Greece
Contact:

Re: RPIEasy

#71 Post by iron » 19 Jan 2019, 18:31

%sysname%/#/ is what it takes to report properly... that last / made the difference

-D
-D

User avatar
enesbcs
Normal user
Posts: 295
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: RPIEasy

#72 Post by enesbcs » 19 Jan 2019, 20:40

iron wrote:
19 Jan 2019, 18:31
%sysname%/#/ is what it takes to report properly... that last / made the difference
I guess that it is working now as needed. :)
The PING payload is implemented in the latest commit, this is the only reliable way i found to check if the MQTT connection is opened and usable.

gpio command is located in the Switch plugin, this is by design, and this was the default working mode in ESPEasy at 2018 summer, when i started to code RPIEasy, and i prefer this method, as i am using RPIEasy on PC's where GPIO is not available. And there are more plugins which have usable commands, such as playaudio which is based on pygame, usbrelay which depends on HID package.. all of them needs their plugin to be loaded, at least to check dependencies, before try to use them. Modularity is my primary goal.

User avatar
iron
Normal user
Posts: 67
Joined: 24 Sep 2016, 08:37
Location: Veria, Greece
Contact:

Re: RPIEasy

#73 Post by iron » 19 Jan 2019, 21:34

enesbcs wrote:
19 Jan 2019, 20:40
iron wrote:
19 Jan 2019, 18:31
%sysname%/#/ is what it takes to report properly... that last / made the difference
I guess that it is working now as needed. :)
The PING payload is implemented in the latest commit, this is the only reliable way i found to check if the MQTT connection is opened and usable.

gpio command is located in the Switch plugin, this is by design, and this was the default working mode in ESPEasy at 2018 summer, when i started to code RPIEasy, and i prefer this method, as i am using RPIEasy on PC's where GPIO is not available. And there are more plugins which have usable commands, such as playaudio which is based on pygame, usbrelay which depends on HID package.. all of them needs their plugin to be loaded, at least to check dependencies, before try to use them. Modularity is my primary goal.
That automatically means an MCP GPIO extender with 16 GPIOs is out of the question as there not enough tasks.

-D
-D

User avatar
enesbcs
Normal user
Posts: 295
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: RPIEasy

#74 Post by enesbcs » 19 Jan 2019, 21:58

iron wrote:
19 Jan 2019, 21:34
That automatically means an MCP GPIO extender with 16 GPIOs is out of the question as there not enough tasks.
RPIEasy has 48 tasks enabled maximum. But if you wish, i can raise it to 256 tasks. RPI is an embedded computer and until you are out of it's 512-1024MB RAM, you can fill it.

Otherwise only 1 piece of Switch input plugin is needed to work with gpio command. If you want to maintain an Output status, you need one Output helper Plugin (P029) per pin. (Switch input is for tracking input's status, gpio command will not work on input pins as you know: the pin states (in/out) has to be defined before use in RPi.GPIO.) Although commands are in the Switch plugin for historical reasons, i can move them to the output plugin, but i do not see much meaning.

User avatar
harm501
Normal user
Posts: 9
Joined: 12 Aug 2016, 12:36
Location: Neede , NL

Re: RPIEasy

#75 Post by harm501 » 20 Jan 2019, 12:29

I build a update script for RPiEasy

https://github.com/haraldtux/rpieasy-update

have fun
Greetings Harald
Esp Easy user from R76 , think cool, think old school!

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests