webAPI v2 documentation

[sanderkob]

Describe the bug
documentation for webAPIv2 missing (or not easy to find)

Device information

• Firmware version 2.9.0-beta4
• Hardware revision cve 55/27
• Type/model number Itho CVE-S ECO
• CC1101 RF module enabled yes

Desktop (please complete the following information):

• OS: windows 10
• Browser chrome
• Version 131.0.6778.86

[arjenhiemstra]

After activation of API v2, the API page of the add-on contains info about the API v2.

Any suggestions to have this info elsewhere?

[sanderkob]

My mistake, page refreshing gave me the documentation for WebAPI v2.

As to the documentation, some parts have not been updated.
E.g. the command http://.../api.html?get=currentspeed in webAPI v2 does not return a number but a JSON string.
Since much of the communication in my system relies on api commands (not MQTT) via Node-RED, I have some work to do.
I will send the changes I had to make, this may help updating the documentation.

[arjenhiemstra]

As to the documentation, some parts have not been updated.

Yes of course! Didn't update that part yet.

I will send the changes I had to make, this may help updating the documentation.

Thanks a lot!!

[arjenhiemstra]

And to add to that, if you have general feedback about the API, see any inconsistencies etc. please let me know!

[sanderkob]

I made the changes in Node-RED. For the query api.html?get=ithostatus the response key/value pairs are nested so e.g. in Node-RED msg.payload.temp becomes msg.payload.data.ithostatus.temp.
Bracket notation works as before, e.g. msg.payload.data.ithostatus["CO2level (ppm)"].
I noticed that the response to a setting query (api.html?getsetting=) in API v1 already did return the new format JSON, so in this case I did not have to make changes going to API v2.
As to the documentation, in API v1 the result from the query api.html?get=currentspeed is given as string whereas it actually is a number (similar to the state topic in mqtt). The documentation for API v2 does not need changes but it would be helpful to state that the ithostatus key/value pairs are nested inside the members data and ithostatus. An example may help.

[arjenhiemstra]

in API v1 the result from the query api.html?get=currentspeed is given as string whereas it actually is a number (similar to the state topic in mqtt).

Thats interesting, it should be a string just like v2.

The code producing the string for v1:

ithowifi/software/NRG_itho_wifi/main/tasks/task_web.cpp

Lines 584 to 590 in f287881

	if (strcmp(q->value().c_str(), "currentspeed") == 0)
	{
	char ithoval[10]{};
	snprintf(ithoval, sizeof(ithoval), "%d", ithoCurrentVal);
	request->send(200, "text/html", ithoval);
	return;
	}

is the same as for v2:

ithowifi/software/NRG_itho_wifi/main/tasks/task_web.cpp

Lines 838 to 844 in f287881

	if (strcmp(value, "currentspeed") == 0)
	{
	char ithoval[10]{};
	snprintf(ithoval, sizeof(ithoval), "%d", ithoCurrentVal);
	response["currentspeed"] = ithoval;
	return ApiResponse::status::SUCCESS;
	}

Maybe the JSON lib handles string input differently compared to the WebServer lib, or the browser displays it differently?

[sanderkob]

Solved. In Node-Red I used the http request node with return set to parsed json object. That returned a number. When set to binary buffer it returned 0x31 0x35, being the string representation of *15.* Op di 3 dec 2024 om 22:47 schreef Arjen Hiemstra ***@***.***>:

…

in API v1 the result from the query api.html?get=currentspeed is given as string whereas it actually is a number (similar to the state topic in mqtt). Thats interesting, it should be a string just like v2. The code producing the string for v1: https://github.com/arjenhiemstra/ithowifi/blob/f287881e817b62525102817c3809ccf261c6776c/software/NRG_itho_wifi/main/tasks/task_web.cpp#L584-L590 is the same as for v2: https://github.com/arjenhiemstra/ithowifi/blob/f287881e817b62525102817c3809ccf261c6776c/software/NRG_itho_wifi/main/tasks/task_web.cpp#L838-L844 Maybe the JSON lib handles string input differently compared to the WebServer lib, or the browser displays it differently? — Reply to this email directly, view it on GitHub <#278 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIL5KVGA3DJVF3DW4GDBDLL2DYRHXAVCNFSM6AAAAABSSIVLQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJVGYYTONJTGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>