Info about send to own api

Hello everyone,
i am looking for get data by “send to own api”.
if i put the url and path of my php, i can’t reach my file. any idea? if call directy by url i reach him without problems. You can help me?
Very thanks.

Is it the original master firmware ? I do not recognize the layout.
The port and the rest a good ?

It looks like this in a config that works:

// define own API
static const char HOST_CUSTOM[] PROGMEM = "";
static const char URL_CUSTOM[] PROGMEM = "/influx/dataModuleAir_v2_wifi.php";

Are you sure you have no typos in URL or so?

Hello pjt and Ben21 , thank you for your reply,
if called by browser, i reach the php script without problems.
now for testing, if call my url i create a blank json file in host folder.
what do you thnik?

Can you read the serial logs in USB? It should point the issue out.

Hello, this is my log:

2022-11-26 09:26:17: a2022-11-26 09:26:20: ## Sending to custom api: 
2022-11-26 09:26:20: Start connecting to
2022-11-26 09:26:20:
2022-11-26 09:26:20: 80
2022-11-26 09:26:20: /davis/airquality/lora.php
2022-11-26 09:26:20: {"esp8266id": "6503506", "software_version": "NAMF-2020-44", "sensordatavalues":[{"value_type":"SDS_P1","value":"2.20"},{"value_type":"SDS_P2","value":"1.00"},{"value_type":"HECA_temperature","value":"20.95"},{"value_type":"HECA_humidity","value":"50.15"},{"value_type":"HECA_Tdc","value":"0.00"},{"value_type":"HECA_RHdc","value":"0.00"},{"value_type":"HECA_dc","value":"0.00"},{"value_type":"BME280_temperature","value":"20.60"},{"value_type":"BME280_pressure","value":"102652.48"},{"value_type":"BME280_humidity","value":"49.02"},{"value_type":"samples","value":"100166"},{"value_type":"min_micro","value":"1326"},{"value_type":"max_micro","value":"214147"},{"value_type":"signal","value":"-43"}]}
2022-11-26 09:26:39: Not succeeded 
2022-11-22022-11-26 09:26:39: validate request auth...
2022-11-26 09:26:39: validate request auth...
2022-11-26 09:26:40: validate request auth...

about servers I don’t know too much, but if i paste my url by browser, create file locally.
seems that system not call my page

2022-11-26 09:26:20:
2022-11-26 09:26:20: 80

HTTP and port 80 or HTTPS and port 433 maybe?

Hello is there any update. I try to get the values into a simple node red.
When I call directly from a browser. Node red will receive the call und response just the same values.
My configuration:

Any suggestions?

I was told, you should not write http://, only the adress.

unfortunately not
i try a lot of posible configurations.

following the code it should be easy. I don’t understand why.
Server “”
URL “/sensor”
Port 1880

#define HOST_MADAVI “
#define URL_MADAVI “/data.php”
#define PORT_MADAVI 80

#define HOST_DUSTI “”
#define URL_DUSTI “/v1/push-sensor-data/”
#define PORT_DUSTI 80

I also changed it to:


Hello, I’ve been using my own api for a while now and everything works fine.

My setup:

A server running on Apache with php installed.
A file with
then send to your database the json.

My config for the sensor:
static const char HOST_CUSTOM2[] PROGMEM = “192.168.*.”;

static const char URL_CUSTOM2[] PROGMEM = “/myFile.php”;

#define PORT_CUSTOM2 80

Try port 80 and not 1880 (port maybe close by your server)
Check server logs for communication and php logs for errors in the json parsing.
Use postman to “simulate” the POST request on you server.

Hope this hepl

1 Like

Well, it seems to work fine for me with an internal IP address. But just changing the server name to my domain name, the port to 443 and the checkbox for https checked. It just doesn’t work. No requests are even logged at the webserver.

Doing a post using Curl on the commandline, to the same endpoint on my domain, from the network my sensor is located, the request does come through. So there seems to be some issue with https API calls to domain names from the sensor device as far as I can see.

Unfortunately, I cannot debug it further.

This is what I get back from the logs, which isn’t helpful to determine a root cause;

## Sending to - BME280
Succeeded -
## Sending to 
Succeeded -
## Sending to opensensemap: 
Succeeded -
## Sending to custom api: 
Time for Sending (ms): 1712

Hi and welcome.

Please send some pictures of the web config interface. I need to see the way you typed the addresses etc. There are some subtilities.

Are you an ESP8266 or ESP32 ?

Thank you for your response, here is the config I currently use:

And I use and ESP8266


firstly remove www.
Then maybe put the path in the server line and only /incoming on path
And incoming without .php?

well, the api endpoint server really is only available including the www subdomain. And since it is not a php script, adding .php would not be helpful. The same goes for the path, it needs to be exactly the way it is since that’s where the endpoint is configured on the webserver.

I tested the endpoint using a curl command to see if it works, from the same network the sensor is placed and that works. Changing the server name to an internal url where it points to the same webapplication in development mode, it works too. So this, to me, seems only changing the hostname and the protocol http to https and the port would be the issue. Sounds logical right? Unless there is a strict requirement in the firmare that prevents a post to a domain with the www addition I don’t know about.

Have you tried without www.?

No I didn’t, because I know the API isn’t available on the domain without www.
But I did just now. Unfortunately without result.

Hi. I assume you’re using the release version NRZ-2020-133.

That version of the firmware has a minimal set of SSL ciphers to use when using HTTPS. The server you are connecting to has a very restrictive set of SSL ciphers (which is good, security wise) and doesn’t offer the ciphers needed by the NRZ-2020-133 firmware. So a HTTPS connection to that server will fail (you might see messages like ‘no shared cipher’ in the server logs when that happens).

You might want to try an Auto Update of the firmware to the Beta version. That one has more SSL ciphers to use (including the ones needed by your API-server).

Thanks for the info @Phaze-III ! Sounds like a very plausible reason indeed. I’ll update soon and post the results once I have them. (I’m on NRZ-2020-133 indeed)