Big wish - generall HTTP and MQTT Interfaces

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Big wish - generall HTTP and MQTT Interfaces

#1 Post by kr0815 » 21 Nov 2015, 20:15

Is it maybe possible to have in future Versions a General HTTP Interface ?
There are many Units that could be controlled by smple http-requests like http://192.168.1.1/myswitch/on
This would make it easy to use the System for many applications, without needing interfacés for each

Regards
Klaus

lunarok
Normal user
Posts: 34
Joined: 28 Oct 2015, 10:11

Re: Big wish - generall HTTP and MQTT Interfaces

#2 Post by lunarok » 26 Nov 2015, 09:40

I will +1 this request here
As I say on my presentation, general HTTP will permit for exemple to have Jeedom working for receiving push and sending request to ESPeasy. That's all what is needed a general option with the URL for push to give (like many alarm, IPX and other hardware have)

For MQTT they are already general, just missing the topic schema somewhere will be good but that's working with any MQTT broker (at least if you want pure values and not json, don't take domoticz MQTT type)

chrille
Normal user
Posts: 88
Joined: 26 Aug 2015, 15:11
Location: Horsens, Denmark

Re: Big wish - generall HTTP and MQTT Interfaces

#3 Post by chrille » 26 Nov 2015, 11:18

lunarok wrote:I will +1 this request here
As I say on my presentation, general HTTP will permit for exemple to have Jeedom working for receiving push and sending request to ESPeasy. That's all what is needed a general option with the URL for push to give (like many alarm, IPX and other hardware have)

For MQTT they are already general, just missing the topic schema somewhere will be good but that's working with any MQTT broker (at least if you want pure values and not json, don't take domoticz MQTT type)
For MQTT just select OpenHAB and feed into mqttwarn - then it's easy to transform it to any other form of MQTT - even json. This approach should also work for HTTP, as there's a HTTP output module for mqttwarn. I use it to send MQTT data into influxdb and POST/GET to different URL's

- Jan
Jan Chrillesen, Denmark

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#4 Post by kr0815 » 27 Nov 2015, 00:00

mqttwarn Looks interesting, but my Approach would be to the esp in another Network, like at friends, parents, work
is there an open mqttwarn Server ? it Looks like i have to have a Server then in the firnds house ?

chrille
Normal user
Posts: 88
Joined: 26 Aug 2015, 15:11
Location: Horsens, Denmark

Re: Big wish - generall HTTP and MQTT Interfaces

#5 Post by chrille » 27 Nov 2015, 08:30

kr0815 wrote:mqttwarn Looks interesting, but my Approach would be to the esp in another Network, like at friends, parents, work
is there an open mqttwarn Server ? it Looks like i have to have a Server then in the firnds house ?
You can use a single mqttwarn instance for multiple locations, as long as the modules publishes to different topics. You can host a broker and a mqttwarn at home and your friends can connect to that, or you can use a public broker, that everyone connects to - including your mqttwarn instance.

- Jan
Jan Chrillesen, Denmark

lunarok
Normal user
Posts: 34
Joined: 28 Oct 2015, 10:11

Re: Big wish - generall HTTP and MQTT Interfaces

#6 Post by lunarok » 27 Nov 2015, 11:54

Yeah, but if you already use MQTT, it's done you have it in your home automation software (at least for the ones with the right plugins)

General HTTP is simplier, no MQTT broker, no mqttwarn, direct to home automation platform

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: MySensors goes ESP!!

#7 Post by kr0815 » 06 Dec 2015, 14:34

You are totally right about there is no real standart.
a few weeks ago, i wasn´t even thinking about MQTT, i have it installed now, funny to Play with, and it works.

But for simple things / beginners, it´s to complicated, starting already with the needed Broker....

I don´t know about domotics, i´m using Fhem,
FHEM supports many Hardware Interfaces, but it could also be controlled by Telnet or HTTP
A HTTP command, for example, Looks like:
http://<fhem>:8083/fhem?cmd.dummy=set%20dummy%20on&XHR=1
Are such things not possible in Domoticz?


My thinking / wish about a "generall" HTTP-Interface would be:

- possibilty to use Names instead of ip, so i could connect to http://example.com
- possibility to format the Output similar to the MQTT Publishing template already build in
example:
MQTT Publish Template: /fhem/Sensor1/%id%/%valname%
in my case that would be then
/fhem?cmd.dummy=set%id%value&XHR=1

I´m not a good programmer, hacking at the Moment the Thingspeak-Interface for my needs, but would be nice to have a generall solution ?

lunarok
Normal user
Posts: 34
Joined: 28 Oct 2015, 10:11

Re: Domoticz Native integration

#8 Post by lunarok » 06 Dec 2015, 20:35

Again this has already been asked, but if the http protocol was generic and configurable in ESPeasy, it will be usefull for other home automation software.
If Domoticz cannot use a dummy device like any other device it's not the case for alls. FHEM, Jeedom and a lot more will be happy to have it open.

Me for exemple, in Jeedom I will prefer just a general http configuration so the node can push to the home automation (whatever with a json body or full values in URL, I will take care of it) than just another way to have a network with a gateway. ESPeasy is different and nice to play without any need for a gateway and a web interface in addition to the home automation

lunarok
Normal user
Posts: 34
Joined: 28 Oct 2015, 10:11

Re: MySensors goes ESP!!

#9 Post by lunarok » 06 Dec 2015, 20:41

kr0815 wrote:You are totally right about there is no real standart.
a few weeks ago, i wasn´t even thinking about MQTT, i have it installed now, funny to Play with, and it works.

But for simple things / beginners, it´s to complicated, starting already with the needed Broker....

I don´t know about domotics, i´m using Fhem,
FHEM supports many Hardware Interfaces, but it could also be controlled by Telnet or HTTP
A HTTP command, for example, Looks like:
http://<fhem>:8083/fhem?cmd.dummy=set%20dummy%20on&XHR=1
Are such things not possible in Domoticz?


My thinking / wish about a "generall" HTTP-Interface would be:

- possibilty to use Names instead of ip, so i could connect to http://example.com
- possibility to format the Output similar to the MQTT Publishing template already build in
example:
MQTT Publish Template: /fhem/Sensor1/%id%/%valname%
in my case that would be then
/fhem?cmd.dummy=set%id%value&XHR=1

I´m not a good programmer, hacking at the Moment the Thingspeak-Interface for my needs, but would be nice to have a generall solution ?
Hacking the post, for +1 the request for general HTTP interface. We need exactly the same for Jeedom. I think with this, it will make ESPeasy compatible with almost all home automation softwares (and agree with the fact that working with MQTT is nice but when it's so near to work without it's just better for end user)

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#10 Post by Martinus » 08 Dec 2015, 14:42

[Moderated by Martinus: To keep discussion topics clean, I've moved some posts to this topic]

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#11 Post by Martinus » 08 Dec 2015, 16:45

lunarok wrote:... Don't forget the generic HTTP please, will be easier and get a dedicated plugin inside Jeedom for this
Won't forget, but December may not be the best month for spare time. Wife and kids need attention too :oops:

Only just 'recovered' from our dutch "Sinterklaas" event :P

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#12 Post by Martinus » 09 Dec 2015, 16:16

lunarok wrote:... Don't forget the generic HTTP please, will be easier and get a dedicated plugin inside Jeedom for this
But if we 'wrap' the ESP sketch around the MySensors library, there's no need anymore for http, since people can use the available MySensors plugin in Jeedom. True?

lunarok
Normal user
Posts: 34
Joined: 28 Oct 2015, 10:11

Re: Big wish - generall HTTP and MQTT Interfaces

#13 Post by lunarok » 09 Dec 2015, 16:58

Yes, completly true

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#14 Post by kr0815 » 09 Dec 2015, 22:13

Sorry, i can´t agree
If you wrap it around mysensors, the esp could talk to the systems listed at at the Moment at the mysensors page
But ( i know only about FHEM) there is also a maintainer that wrote a Special script to get the values from mysensors into FHEM.All These Systems need code to Support mysensors

Me , for example, i have another System that has nothing to do with home Automation - i log values like temperature to a Server
there´s a german Project http://www.volkszaehler.org , another guy here also asked how to log values to that System.
I´m trying at the moment to "hack" your scripts for my needs, hopefully i´ll be successfull some day :-)
(My idea is to use esp-easy to have sensors at the company, friends, relatives, they could easily integrate it in their home network, and it logs to my volkszaehler server)

my thinking is more, if we have a general http Interface, esp-easy could speak with so many systems, for example my home stereo system could be controlled like that, so why not take an ESP8266, a few Buttons, and have a remote ?
The ability to send somethink like "<URL>:<port>/ <text, whatever>value_from_esp_device<text, whatever>" would make a swiss army knife out of it.

But as it´s your Project, so your decission :-)

Regards
Klaus

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#15 Post by Martinus » 09 Dec 2015, 23:14

kr0815 wrote:But as it´s your Project, so your decission :-)
Regards
Klaus
You're certainly right here, but I'm not a bad guy I think. ;)

But just because we're exploring the MySensor adventure doesn't mean killing the ESP Easy project. And from the list of MySensor controller support, it is clear that not even all of them support the Ethernet gateway anyway.

I'm interested to see how far you're getting along with your own controller plugin development. If it's just a basic HTTP interface I will likely find some spare time to help you out. Maybe you can post it here and I will have a look at it?

regards,

Martinus

lunarok
Normal user
Posts: 34
Joined: 28 Oct 2015, 10:11

Re: Big wish - generall HTTP and MQTT Interfaces

#16 Post by lunarok » 09 Dec 2015, 23:36

My answer "totally agree" was to question of Martinus "so Jeedom users don't need HTTP support if ESP easy is supporting mySensors protocol"
Still my answer, Jeedom will be able to work with the mySensors plugin.

But I agree too that a general HTTP interface and same for the MQTT is a "need" too.
My vision of the perfection will be :

- a general HTTP interface that can be set like :
URL : http:/whateverserverIwant/withanapi?id=<ID>blabla
Body : can be none but also can be build like {'data':{....}}

- a general MQTT interface setable too :
topic format
body value

- a mySensors interface setable with just a controller URL maybe (I ask hek if for their project of mysensors going to ESP it was possible to have the gateway broadcast their presentation so like a node we can do autocreation)

With these 3 interface, you are the king of ESP for sensors :D

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#17 Post by Martinus » 10 Dec 2015, 13:59

MQTT
=====
I think that a generic MQTT interface already exists in ESP Easy. OpenHAB has publish and subscribe templates and all topic naming components can be changed through the web interface like system name, device names, value names. So what if I would rename OpenHAB to Generic, or just make a copy ?

HTTP
=====
For HTTP let's start an experimental controller and see where we end up. I've committed R50 to github with a new controller plugin (008).
Now you can use the publish template in /tools/advanced menu to set the template used for the final HTTP get request using querystring.

You can use the following variables:

%sysname% = ESP Name
%tskname% = Task name
%id% = Task id
%valname% = Value name
%value% = The actual value

Sample:
data.asp?device=%tskname%&param=%valname%&value=%value%

I've done a quick test on a basic asp page running on a Windows IIS server and it seemed to work as expected.
Please let me know if it works for your situation.

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#18 Post by kr0815 » 10 Dec 2015, 15:20

Right now, i wanted to come back to your offer upload my experimental code, when i saw you already wrote something.
I will try it immediately this evening.

What i saw so far:
- i need POST instead of GET, but easy to change
- my HTTP-Request looks like:
POST http://demo.volkszaehler.org/middleware ... d&value=12

550e8400-e29b-11d4-a716-446655441352 describes the channel to log to, so i had to change max length of Task id or Value name

Are you planning also to implement URLs instead of IP Address in the future ? Otherwise i will try to find another solution for that

Best regards

Klaus

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#19 Post by kr0815 » 10 Dec 2015, 20:20

tried it now,

first problem, i try to enter

Code: Select all

/middleware.php/data/%tskname%.json?operation=add&value=%value%
after hitting submit, it shows

Code: Select all

%2Fmiddleware.php%2Fdata%2F%25tskname%25.json%3Foperation%3Dadd%26value%3D%25val
the log says

Code: Select all

The requested URL //middleware.php/data/%tskname%.json?operation=add&val
any idea why %tskname% is not resolved ?

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#20 Post by Martinus » 11 Dec 2015, 08:52

kr0815 wrote:after hitting submit, it shows

Code: Select all

%2Fmiddleware.php%2Fdata%2F%25tskname%25.json%3Foperation%3Dadd%26value%3D%25val
It looks like there's an issue with URLdecoding. The special characters like '/' and '%' are not converted back to normal characters.
It does work on my unit though, so this is a strange bug.
kr0815 wrote:any idea why %tskname% is not resolved ?
Because of the issue above, the % is replaced with %25 and the replace routine doesn't understand it anymore...

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#21 Post by kr0815 » 11 Dec 2015, 09:30

sorry, i think i mixed something up when copying the files, i´ll try it again

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#22 Post by kr0815 » 11 Dec 2015, 15:47

First i thought i made a fault mixing up different versions

But i tried again now, downloaded everything again from GitHub, still same fault

I tried an older Version i still had on my PC (Something like 39 i guess) - no fault
So it can´t be the IDE (1.6.5) or other things like google chrome

The fault is not only with the HTTP-Interface, i also tried some others like MQTT- same problem

Did anybody download / flash the Version from yesterday and could use it without problems ?

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#23 Post by Martinus » 12 Dec 2015, 17:18

kr0815 wrote:First i thought i made a fault mixing up different versions

But i tried again now, downloaded everything again from GitHub, still same fault

I tried an older Version i still had on my PC (Something like 39 i guess) - no fault
So it can´t be the IDE (1.6.5) or other things like google chrome

The fault is not only with the HTTP-Interface, i also tried some others like MQTT- same problem

Did anybody download / flash the Version from yesterday and could use it without problems ?
The bug was introduced with a recent pull request on urlDecode changes. We could try to fix it, but if everyone moves over to ESP core 2.0.0. we could remove all the urlDecode stuff because this is now fixed within the webserver library. Because I use core 2.0.0, I didn't notice the bug.

Could you check the latest build on core 2.0.0. ?

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#24 Post by kr0815 » 12 Dec 2015, 17:21

So do i have to just install core 2.0.0, or do i have to remove all this urldecode things ?

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#25 Post by Martinus » 12 Dec 2015, 17:27

kr0815 wrote:So do i have to just install core 2.0.0, or do i have to remove all this urldecode things ?
Just get core 2.0.0. and it should be ok.

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#26 Post by kr0815 » 12 Dec 2015, 19:03

installed it, it´s working now :-)

What i wonder, with core 2.0.0, the ESP always starts as a acces point / dhcp server ?
I have the right values for my wifi set

If i do a WifiDisConnect, then a WifiConnect, it connects to my Wifi ?


Next big Task is now, how to replace IP Adress by URL, does anybody know if this should even be possible at all with esp8266 ?

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#27 Post by kr0815 » 12 Dec 2015, 22:27

Tried to connect to an URL, now i´m completely lost.

I replaced

Code: Select all

client.print(String("GET ") + url + " HTTP/1.1\r\n" +
               "Host: " + host + "\r\n" +
               "Connection: close\r\n\r\n");

with

Code: Select all

 client.print(String("POST ") + url + " HTTP/1.1\r\n" +
               "Host: test123.de/volkszaehler_neu\r\n" +
               "Connection: close\r\n\r\n");

no, the system crashes completely:
>WIfiDisConnect
>WifiConnect
WIFI : Connecting...
f 0, scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 5
cnt

connected with Power-LAN, channel 6
dhcp client start...
ip:192.168.178.80,mask:255.255.255.0,gw:192.168.178.1
DS : Temperature: 23.94 (28-ff-ec-4-82-15-3-61)
HTTP : connecting to 192.168.178.47
URL: //volkszaehler.org/htdocs/middleware.php/data/f5bd1a60-9c2e-11e5-af62-53e01bdf1cd4.json?operation=add&value=23.94
//volkszaehler.org/htdocs/middleware.php/data/f5bd1a60-9c2e-11e5-af62-53e01bdf1
output: POST //volkszaehler.org/htdocs/middleware.php/data/f5bd1a60-9c2e-11e5-af62-53e01bdf1cd4.json?operation=add&value=23.94 HTTP/1.1
Host: kr123.de/volkszaehler_neu
Connection: close

HTTP : closing connection
HTTP : Delay 1000 ms
DS : Temperature: 24.31 (28-ff-c6-b5-82-15-2-64)
HTTP : connecting to 192.168.178.47
URL: //volkszaehler.org/htdocs/middleware.php/data/c044e270-9c2e-11e5-91fb-55387e68c73e.json?operation=add&value=24.31
//volkszaehler.org/htdocs/middleware.php/data/c044e270-9c2e-11e5-91fb-55387e68c
output: POST //volkszaehler.org/htdocs/middleware.php/data/c044e270-9c2e-11e5-91fb-55387e68c73e.json?operation=add&value=24.31 HTTP/1.1
Host: kr123.de/volkszaehler_neu
Connection: close

HTTP/1.1 400 Bad Request

Date: Sat, 12 Dec 2015 21:25:00 GMT

Server: Apache/2.2.22 (Debian)

Vary: Accept-Encoding

Content-Length: 317

Connection: close

Content-Type: text/html; charset=iso-8859-1



<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><0000, epc3=0x00000000, excvaddr=0x7373657e, depc=0x00000000
body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.2.22 (Debian) Server at kr123.de/volkszaehler_neu Port 80</address>
Fatal exception (9):
epc1=0x4021d0d8, epc2=0x0000
Exception (9):
epc1=0x4021d0d8 epc2=0x00000000 epc3=0x00000000 excvaddr=0x7373657e depc=0x00000000

ctx: cont
sp: 3fff2ca0 end: 3fff30d0 offset: 01a0

>>>stack>>>
3fff2e40: 3ffe99bc 3fff0714 3fff2ec0 4021d0d4
3fff2e50: 40201c9e 00000001 3fff2ef8 4021d4d4
3fff2e60: 3fff3120 00000000 3fff0714 402113b9
3fff2e70: 6464613c 73736572 6170413e 2f656863
3fff2e80: 2e322e32 28203232 69626544 20296e61
3fff2e90: 76726553 61207265 726b2074 2e333231
3fff2ea0: 762f6564 736b6c6f 6865617a 5f72656c
3fff2eb0: 2075656e 74726f50 3c303820 6464612f
3fff2ec0: 73736572 0000003e 000003e8 0009c199
3fff2ed0: 3fff0068 3fff5950 2e323931 2e383631
3fff2ee0: 2e383731 00003734 b5c6ff28 3fff5278
3fff2ef0: 0000000f 0000000f 3fff5278 0000000f
3fff2f00: 00000000 3fff5c88 0000007f 00000071
3fff2f10: 41c28000 3fff5b98 00000001 000001b4
3fff2f20: 402076ac 3fff5b98 000001b4 3fff0c92
3fff2f30: 3fff0e24 3fff2fa0 3fff2fa0 4021159a
3fff2f40: 3ffe99bc 00000000 3fff2fc8 3fff0c92
3fff2f50: 3fff0e24 3fff2fa0 00000001 3fff0c92
3fff2f60: 3fff0e24 3fff2fa0 3fff0d78 4020a5b5
3fff2f70: 3ffe99bc 44203a20 79616c65 00000003
3fff2f80: 3fff0e24 00000001 3ffe99bc 3fff08f3
3fff2f90: 3fff0e24 00000010 00000001 4020a734
3fff2fa0: 40100401 000001c8 3fff3001 4021d65c
3fff2fb0: 3ffe99bc 00000000 000003e8 3fff4a50
3fff2fc0: 0000000f 00000000 3fff4ad0 0000000f
3fff2fd0: 00000000 00000005 41c30000 00000000
3fff2fe0: 00000000 00000000 4021a801 3fff20b0
3fff2ff0: 401015a2 00000000 00000000 40218de8
3fff3000: 3fff1f60 401016e3 3fff20b0 3fff1f60
3fff3010: 3fff0644 3fff0640 4021a8c0 3fff20b0
3fff3020: 3fff0658 0000000a 0000000a 40201c93
3fff3030: 3fff0644 3fff063c 3fff4e80 3fff0640
3fff3040: 3fff0644 3fff063c 3fff0d78 402103c2
3fff3050: 69747055 3120656d 6f432030 63656e6e
3fff3060: 69614674 6572756c 30322073 65724620
3fff3070: 6d654d65 39363220 3f003231 4020a578
3fff3080: 3f0055aa 3fff0e78 3fff1b98 3fff4a70
3fff3090: 00000000 00000000 00000016 40101e31
3fff30a0: 4021a8e1 0000001f 00000012 3fff209c
3fff30b0: 3fffdc20 00000000 3fff2094 4021a909
3fff30c0: 00000000 00000000 3fff20b0 40100114
<<<stack<<<

ets Jan 8 2013,rst cause:1, boot mode:(3,5)

load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld
ªU
INIT : Booting Build nr:50
bcn 0
del if1
mode : sta(18:fe:34:da:69:e2)
WIFI : Connecting...

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#28 Post by Martinus » 13 Dec 2015, 11:23

I'm not an HTML expert, but if you're using the POST verb, shouldn't you actually post something? Right now it looks like you're doing a POST request using a querystring and not posting anything. If the querystring already contains the operation and data, what's there to post in addition?

Or is it just my ignorance in HTML that makes me misunderstanding how things work :mrgreen: :mrgreen:

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#29 Post by kr0815 » 13 Dec 2015, 11:45

I´m neither a HTML expert :-)

What i tried, i have a local copy of this volkszaehler logger on my home Server

Using the first example above, wiith local IP adress in the settings of the web Interface, it works
so i thought i replace just the variable "host" with the web adress, but i don´t know how Client.print thing has to be formated.
i found many examples in the web doing it the same way. (on some Forums, they are discussing whether it´s "\r\n" or just "\n"
maybe it has something to do with DNS / Gateway ?

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#30 Post by kr0815 » 13 Dec 2015, 16:58

Have it partly working now

i only replaced

Code: Select all

char host[20];
  sprintf_P(host, PSTR("%u.%u.%u.%u"), Settings.Controller_IP[0], Settings.Controller_IP[1], Settings.Controller_IP[2], Settings.Controller_IP[3]);
with

Code: Select all

  char host[40] = "esp.kr123.de/volkszaehler.org/htdocs";
  // sprintf_P(host, PSTR("%u.%u.%u.%u"), Settings.Controller_IP[0], Settings.Controller_IP[1], Settings.Controller_IP[2], Settings.Controller_IP[3]);
now i get at least
HTTP : connecting to esp.kr123.de/volkszaehler.org/htdocs
HTTP : connection failed

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#31 Post by kr0815 » 14 Dec 2015, 21:30

It´s working now, thanks a lot :-)
I made a demo set up, so if anybody is interested: http://www.esp.kr123.de , 2 Units logging at the Moment

I hardcoded the URL in the sketch, because i can´t use IPs to log to the server

My wish now, to follow your updates, could you please set max length of %valname% to 50 ?

Best regards

Klaus

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#32 Post by Martinus » 16 Dec 2015, 09:37

kr0815 wrote:My wish now, to follow your updates, could you please set max length of %valname% to 50 ?
I would surely want to change it if it did not bring some 'evil' issues. Changes to these settings structures corrupt the inner working of the ESP. To be safe we have to reset the unit with each update that changes these thing. It also renders previous configuration backups useless. And finally there are limitations on reserved flash storage for these structs. In this case it's only 512 bytes for each task of which already 360 are in use. This change would increase it to 460 leaving only 50 bytes left for future use.

So there's some hesitation to do this right now...

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#33 Post by kr0815 » 16 Dec 2015, 19:40

I completely understand you, no problem, i could make the changes myself in the future versions, it´s just a few lines in espeasy.ino and the webserver

But what do you mean with:
To be safe we have to reset the unit with each update that changes these thing
Maybe this solves my other problem that the unit gets no ip adress
Is it possible to erase the EEPROM ?
I know for arduino there exits some code/sketch to erase the internal eeprom
Is there something similar for the ESP8266 ?

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#34 Post by Martinus » 17 Dec 2015, 14:49

It's difficult to tell the exact issues you will get if you change the structs that are stored in flash without resetting the device. It's a situation that should be avoided unless you really understand the effects of the changes and know how to programmatically fix it.

So if you want to make this kind of customizations, reset the ESP after uploading the modified code. Then it should be fine in general. Don't load saved config files from non-customized versions, as the load/save mechanism is just a plain binary flash sector dump.

But remember that that are also limitations on the maximum structure size. If you exceed those, a reset won't help because data will be overlapping in flash memory and you will not get a warning about this.

There should not be a need to erase this specific flash area with a special tool, as this is done in case of the reset command.
(unless you want to erase the entire ESP flash chip, there seems to be "empty" bin files that could do that using generic ESP flash tools)

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#35 Post by kr0815 » 17 Dec 2015, 19:34

Do you know where to get such a file to erase it completely - for arduino IDE ?
I searched through Google, didn´t find anything

I still have the Problem with my one unit, as described in the other post, not getting an ip adress, so i have to manually do a WifiDisConnect, then a WifiConnect, very strange

Backbone
Normal user
Posts: 106
Joined: 06 Oct 2015, 22:12

Re: Big wish - generall HTTP and MQTT Interfaces

#36 Post by Backbone » 17 Dec 2015, 20:20

https://www.dropbox.com/s/hpw14exd42v3g ... r.ino?dl=0

Clear.ino
Use serial monitor to send E for erase.

Paco

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#37 Post by Martinus » 18 Dec 2015, 10:47

Backbone wrote:https://www.dropbox.com/s/hpw14exd42v3g ... r.ino?dl=0

Clear.ino
Use serial monitor to send E for erase.

Paco
This ESP Easy tool only erases the flash area where normally SPIFFS is located. This area is used for all configuration settings. So it does not wipe the application program in flash.

If you want to fully erase the ESP flash chip, you should use a flash upload tool and upload a bin file with the same size as the flash chip, containing all 0xff values. I've seen these 512 kB empty bin files somewhere but never used it. I guess for ESP12E you would need a 4 MB bin file.

I've heard from Iggr that a program cannot wipe itself (and this of course would require the erase routine to be stored in RAM somehow)
That's why you need an external tool.

kroonen
Normal user
Posts: 26
Joined: 05 Oct 2015, 22:00

Re: Big wish - generall HTTP and MQTT Interfaces

#38 Post by kroonen » 04 Jan 2016, 21:43

Martinus wrote:MQTT
=====
I think that a generic MQTT interface already exists in ESP Easy. OpenHAB has publish and subscribe templates and all topic naming components can be changed through the web interface like system name, device names, value names. So what if I would rename OpenHAB to Generic, or just make a copy ?

HTTP
=====
For HTTP let's start an experimental controller and see where we end up. I've committed R50 to github with a new controller plugin (008).
Now you can use the publish template in /tools/advanced menu to set the template used for the final HTTP get request using querystring.

You can use the following variables:

%sysname% = ESP Name
%tskname% = Task name
%id% = Task id
%valname% = Value name
%value% = The actual value

Sample:
data.asp?device=%tskname%&param=%valname%&value=%value%

I've done a quick test on a basic asp page running on a Windows IIS server and it seemed to work as expected.
Please let me know if it works for your situation.

I can confirm. It works with fhem (fhem.de)

You need to select generic http and port 8083.

for a temperature sensor si7021

On the mqtt publish template, type the following url

fhem?cmd=setreading%20%tskname%%20%valname%%20%value%

for a switch

fhem?cmd=set%20tskname%20%value%

Maybe on the advanced tab a different field for the http generic url?

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#39 Post by kr0815 » 17 Jan 2016, 19:39

Sorry to ask again, but is there any chance to extend max value of %valname% ?
I´m using this great project to log to my Volkszaehler setup, but they use long UUIDs for security reasons, so i need at least 36 characters.
At the moment each time there´s an update, i change everything, but that´s not really confortable

Best regards
Klaus

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#40 Post by Martinus » 18 Jan 2016, 20:40

kr0815 wrote:Sorry to ask again, but is there any chance to extend max value of %valname% ?
I´m using this great project to log to my Volkszaehler setup, but they use long UUIDs for security reasons, so i need at least 36 characters.
At the moment each time there´s an update, i change everything, but that´s not really confortable

Best regards
Klaus
Is this UUID unique for each sensorvalue or unique for each sensor? Can't you join the taskname and taskvalues together to get a max 50 character string?

Suppose UUID for the sensor is:

a301d8d0-903b-1234-94bb-d943d061b6a8

You put the first part in taskname: a301d8d0-903b-1234-94bb-
and remaining part in valuename: d943d061b6a8

And join them in the template like this:

/data/%tskname%%valname%.json

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#41 Post by kr0815 » 18 Jan 2016, 21:34

Unfortunately, the UUID is unique for each value
I was already thinking about combining taskname and taskvalue, but as i have some DHT22, this doesn´t work
It´s not that important, i changed the current release now, and saved it to build future sensors

Martinus

Re: Big wish - generall HTTP and MQTT Interfaces

#42 Post by Martinus » 19 Mar 2016, 13:11

kr0815 wrote:Sorry to ask again, but is there any chance to extend max value of %valname% ?
I´m using this great project to log to my Volkszaehler setup, but they use long UUIDs for security reasons, so i need at least 36 characters.
At the moment each time there´s an update, i change everything, but that´s not really confortable

Best regards
Klaus
With R88, the field size is increased from 25 to 40 characters. Internal flash data migration is needed, but handled using a special fix routine if a pre R88 build is detected. If all goes well, nobody will notice the underlying change.

kr0815
Normal user
Posts: 136
Joined: 18 Nov 2015, 18:24

Re: Big wish - generall HTTP and MQTT Interfaces

#43 Post by kr0815 » 19 Mar 2016, 19:38

Thanks a lot Mártinus,

i will try now the newer versions :-)

lunarok
Normal user
Posts: 34
Joined: 28 Oct 2015, 10:11

Re: Big wish - generall HTTP and MQTT Interfaces

#44 Post by lunarok » 12 Apr 2016, 09:57

Hi,

Very happy to see this, I will implement a Jeedom plugin to make it easier again and generic also on Jeedom side.
@Martinus or anyone can you confirm me this :

%sysname% = ESP Name -> global for one ESP ?
%tskname% = Task name -> name of the task on ESP
%id% = Task id -> ID of the task on ESP
%valname% = Value name -> name of a value in ESP, could have more than one value on one task (for exemple humidity and temp)
%value% = The actual value -> value of the sensor

So the unicity for an equipement is IP/%sysname%
Unicity for an information on an equipement is %id%+%valname%

(I have load R97 on Wemos but I cannot have it connect to my Wifi, as I'm on professionnal travel, these answers will help me prepare the plugin before getting hand on ESP)

lunarok
Normal user
Posts: 34
Joined: 28 Oct 2015, 10:11

Re: Big wish - generall HTTP and MQTT Interfaces

#45 Post by lunarok » 15 Apr 2016, 08:17

Ok, get my Wemos working back at home.

2 questions about Generic HTTP :

1 - is it working with HTTPS ? I can set the port, but not specify it will be https, maybe it will fail if espeasy is not expecting https

2 - the Publish Template field has a limit and it's short, that doesn't permit to put a classical Jeedom API URL for exemple (and I think many if there is an API key + name of param, it's already long). So can it be extend ? and it's almost double neede. If not, I will see for a dedicated service for ESPeasy (this way will solve also point 1, but not secure as no API key)

Post Reply

Who is online

Users browsing this forum: No registered users and 22 guests