RPIEasy

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

Message
Author
User avatar
enesbcs
Normal user
Posts: 292
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: 64
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: 292
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: 292
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: 64
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: 292
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: 64
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: 64
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: 292
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: 292
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: 64
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: 64
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: 292
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: 292
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: 64
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

Post Reply

Who is online

Users browsing this forum: No registered users and 8 guests