HandleHttpCommand() to return application/json content-type header

[BrettSheleski]

Currently HandleHttpCommand() return the content-type of text/plain with content that is JSON-ish.

Proposal:

Check the response's Accept header. If it is set to "application/json" then set the response to "application/json". The content will have to be modified in this case to be valid json. It seems that all responses follow the format of "RESULT = " followed by json. There are cases (eg: /cm?cmnd=gpios) which returns several lines in the format of "RESULT = " followed by json on each line. Therefore it may make sense to wrap all responses in a json array.

Something like (over simplified code):

String json = "[";

for(int i = 0; i < numberOfMessages; ++i){
  if (i > 0) json += ",";

  json += getCommandResultJson(i);
}

json += "]"

...

WebServer->send(200, FPSTR(HDR_CTYPE_JSON), json);

...

Why bother?

I'm currently implementing a new set of SmartThings Device Handlers & SmartApps. There is a limitation (aka: bug) within SmartThings where if the response's content type is anything other than application/json or text/xml, then it is not accessible by its callback methods handling the response. The above seems like a fairly simple solution to this problem. I could also see it being useful for other use cases as well.

[arendst]

Looked at it and think I found a reasonable alternative.

1. Remove result (or any value as this can be changed with command SetOption4)
2. Return only valid JSON by adding JSON lines removing {} if needed:

{"GPIOs1":"0 (None),1 (DHT11),2 (AM2301),3 (SI7021),4 (DS18x20),5 (I2C SCL),6 (I2C SDA),7 (WS2812),8 (IRsend),9 (Switch1),10 (Switch2),11 (Switch3),12 (Switch4),13 (Button1),14 (Button2),15 (Button3),16 (Button4)","GPIOs2":"17 (Relay1),18 (Relay2),19 (Relay3),20 (Relay4),21 (Relay5),22 (Relay6),23 (Relay7),24 (Relay8),25 (Relay1i),26 (Relay2i),27 (Relay3i),28 (Relay4i),29 (Relay5i),30 (Relay6i),31 (Relay7i),32 (Relay8i)","GPIOs3":"33 (PWM1),34 (PWM2),35 (PWM3),36 (PWM4),37 (PWM5),38 (Counter1),39 (Counter2),40 (Counter3),41 (Counter4),42 (PWM1i),43 (PWM2i),44 (PWM3i),45 (PWM4i),46 (PWM5i),47 (IRrecv),48 (Led1),49 (Led2)","GPIOs4":"50 (Led3),51 (Led4),52 (Led1i),53 (Led2i),54 (Led3i),55 (Led4i),56 (MHZ Tx),57 (MHZ Rx),58 (PZEM Tx),59 (PZEM Rx)"}

Using lint:

{
	"GPIOs1": "0 (None),1 (DHT11),2 (AM2301),3 (SI7021),4 (DS18x20),5 (I2C SCL),6 (I2C SDA),7 (WS2812),8 (IRsend),9 (Switch1),10 (Switch2),11 (Switch3),12 (Switch4),13 (Button1),14 (Button2),15 (Button3),16 (Button4)",
	"GPIOs2": "17 (Relay1),18 (Relay2),19 (Relay3),20 (Relay4),21 (Relay5),22 (Relay6),23 (Relay7),24 (Relay8),25 (Relay1i),26 (Relay2i),27 (Relay3i),28 (Relay4i),29 (Relay5i),30 (Relay6i),31 (Relay7i),32 (Relay8i)",
	"GPIOs3": "33 (PWM1),34 (PWM2),35 (PWM3),36 (PWM4),37 (PWM5),38 (Counter1),39 (Counter2),40 (Counter3),41 (Counter4),42 (PWM1i),43 (PWM2i),44 (PWM3i),45 (PWM4i),46 (PWM5i),47 (IRrecv),48 (Led1),49 (Led2)",
	"GPIOs4": "50 (Led3),51 (Led4),52 (Led1i),53 (Led2i),54 (Led3i),55 (Led4i),56 (MHZ Tx),57 (MHZ Rx),58 (PZEM Tx),59 (PZEM Rx)"
}

Or status 10:

{"StatusSNS":{"Time":"2017-12-17T15:46:58","ENERGY":{"Total":0.000,"Yesterday":4.000,"Today":0.000,"Power":0.00,"Factor":0.00,"Voltage":0.00,"Current":0.000},"SHT1X":{"Temperature":23.6,"Humidity":46.3},"HTU21":{"Temperature":24.4,"Humidity":44.7},"BMP280":{"Temperature":25.7,"Pressure":1022.7,"SeaPressure":1023.2},"TempUnit":"C"}}

using lint:

{
	"StatusSNS": {
		"Time": "2017-12-17T15:46:58",
		"ENERGY": {
			"Total": 0.000,
			"Yesterday": 4.000,
			"Today": 0.000,
			"Power": 0.00,
			"Factor": 0.00,
			"Voltage": 0.00,
			"Current": 0.000
		},
		"SHT1X": {
			"Temperature": 23.6,
			"Humidity": 46.3
		},
		"HTU21": {
			"Temperature": 24.4,
			"Humidity": 44.7
		},
		"BMP280": {
			"Temperature": 25.7,
			"Pressure": 1022.7,
			"SeaPressure": 1023.2
		},
		"TempUnit": "C"
	}
}

Even the error messages are now JSON:

{"WARNING":"Enable weblog 2 if response expected"}

Soon provided by next Commit to 5.10.0b

[BrettSheleski]

Nice! Thanks.

[BrettSheleski]

Taking a look at your example output for "gpios", wouldn't it make more sense to return each result as an array?

Instead of the following

{
	"GPIOs1": "0 (None),1 (DHT11),2 (AM2301),3 (SI7021),4 (DS18x20),5 (I2C SCL),6 (I2C SDA),7 (WS2812),8 (IRsend),9 (Switch1),10 (Switch2),11 (Switch3),12 (Switch4),13 (Button1),14 (Button2),15 (Button3),16 (Button4)",
	"GPIOs2": "17 (Relay1),18 (Relay2),19 (Relay3),20 (Relay4),21 (Relay5),22 (Relay6),23 (Relay7),24 (Relay8),25 (Relay1i),26 (Relay2i),27 (Relay3i),28 (Relay4i),29 (Relay5i),30 (Relay6i),31 (Relay7i),32 (Relay8i)",
	"GPIOs3": "33 (PWM1),34 (PWM2),35 (PWM3),36 (PWM4),37 (PWM5),38 (Counter1),39 (Counter2),40 (Counter3),41 (Counter4),42 (PWM1i),43 (PWM2i),44 (PWM3i),45 (PWM4i),46 (PWM5i),47 (IRrecv),48 (Led1),49 (Led2)",
	"GPIOs4": "50 (Led3),51 (Led4),52 (Led1i),53 (Led2i),54 (Led3i),55 (Led4i),56 (MHZ Tx),57 (MHZ Rx),58 (PZEM Tx),59 (PZEM Rx)"
}

return the following instead:

{
	"GPIOs1": ["0 (None)","1 (DHT11)","2 (AM2301)","3 (SI7021)","4 (DS18x20)", ...],
	"GPIOs2": ["17 (Relay1)", ...],
	"GPIOs3": [ ... ],
	...
}

Therefore no further parsing would be necessary by any clients other than json-parsing.

On a side note, why are these returned as multiple properties anyway? Wouldn't it make more sense to just return as a single large array?

[arendst]

I agree on the Array usage and will implement.

It's multiple properties because of the maximum allowed MQTT string size. It overflows the (current) maximum string length leading to missed data and non JSON format. A larger string will influence RAM and performance of the ESP8266.

[BrettSheleski]

Gotcha. I figured it had something to do with that.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.