Wrong state topic (stat_t) in homeassistant config payload for TPMS-Jansite-Solar

[riegelbrau]

The TPMS-Jansite-Solar is supported by OMG since FSK can be enabled. With OMG 1.60 and 1.70 I face the following behaviour running OMG on a LilyGo. The sensor data is sent with the mqtt topic OMG/OMG_lilygo_rtl_433_ESP/RTL_433toMQTT/TPMS/Jansite-Solar/5e512a and this payload

{
	"model": "Jansite-Solar",
	"type": "TPMS",
	"id": "5e512a",
	"flags": 197,
	"pressure_kPa": 68.8,
	"temperature_C": 18,
	"code": "5e512ac5492b009413",
	"mic": "CRC",
	"protocol": "Jansite TPMS Model Solar",
	"rssi": -75,
	"duration": 21000
}

When ohdisc=true is set, the HASS config message for openHAB is created under this topic: homeassistant/sensor/TPMS-Jansite-Solar-5e512a-pressure_kPa/config (example for pressure). The payload is

{
	"stat_t": "+/+/RTL_433toMQTT/Jansite-SolarSolar/5e512a",
	"dev_cla": "pressure",
	"name": "pressure",
	"uniq_id": "TPMS-Jansite-Solar-5e512a-pressure_kPa",
	"val_tpl": "{{ value_json.pressure_kPa }}",
	"state_class": "measurement",
	"device": {
		"ids": [
			"TPMS-Jansite-Solar-5e512a"
		],
		"cns": [
			[
				"mac",
				"TPMS-Jansite-Solar-5e512a"
			]
		],
		"mdl": "Jansite-Solar",
		"name": "TPMS-Jansite-Solar-5e512a",
		"via_device": "OMG_lilygo_rtl_433_ESP"
	}
}

As you can see, the json value for stat_t contains the wrong topic +/+/RTL_433toMQTT/Jansite-SolarSolar/5e512a. The type part TPMS is missing and the two consecutive strings SolarSolar look like a typo, where only one should be.

Steps to reproduce the behavior:

1. Set the config parameter ohdisc to true.
2. Let the sensor send some data by changing the environment pressure or temperature.
3. See good looking mqtt message, but wrong HASS config message.

Expected behavior: The config message should contain "stat_t": "+/+/RTL_433toMQTT/Jansite-Solar/5e512a"

Screenshots MQTT explorer shows this config message:

Environment (please complete the following information):

• OpenMQTTGateway version used: V1.60 self compiled and 1.70 uploaded from the web.
• Library version related to the problem is rtl_433 Where do I see the version of RCSwitch library?

Additional context OMG Information: ```

{

	"latest_version": "v1.7.0",
	"title": "OpenMQTTGateway",
	"release_url": "https://github.com/1technophile/OpenMQTTGateway/releases/tag/v1.7.0",
	"installed_version": "v1.7.0",
	"entity_picture": "https://github.com/1technophile/OpenMQTTGateway/raw/development/docs/img/Openmqttgateway_logo_mini_margins.png",
	"release_summary": ""
}

I posted this in the community earlier without getting any comments: https://community.openmqttgateway.com/t/still-mismatch-between-ha-config-message-and-real-topic-from-rtl-433-esp/2964

Regards, Christoph

[riegelbrau]

Ther is another mismatch. The state topic in the config message should include TPMS like this: +/+/RTL_433toMQTT/TPMS/Jansite-Solar/5e512a. I did'nt recognize this before. I will update the original post above, too.

[riegelbrau]

Any comments or findings regarding this issue?

[riegelbrau]

I tried to figure out, where in the code the wrong stat_t payload is created, but without success, because I am not familiar with this kind of cpp development. May be someone can do this? Is there an option to debug the code while recreating the issue?

[1technophile]

Hello,

Thanks for the detailled issue. I would advise to take a look at: https://github.com/1technophile/OpenMQTTGateway/blob/417d28fb20974b3330bc63f7ee01a8ae88d126e0/main/ZgatewayRTL_433.ino#L145

This is where the magic happens

[riegelbrau]

Thanks for the hint! I tried to figure out, where the state topic is created and I feel it could be here: I cannot see, what the code exactly does, so I would like to activate the DISCOVERY_TRACE_LOG. How can I do that?

[riegelbrau]

I found the reason for the wrong state topic. This code: // Remove the key from the unique id to extract the device id String idWoKeyAndModel = idWoKey; idWoKeyAndModel.remove(0, strlen(pdevice->modelName)); idWoKeyAndModel.replace("-", "/"); DISCOVERY_TRACE_LOG(F("idWoKeyAndModel %s" CR), idWoKeyAndModel.c_str()); topic = topic + "/" + String(pdevice->modelName) + idWoKeyAndModel; ... tries to remove the modelName from the uniqueid, but does not respect the prefix "TPMS-" which comes from the type parameter. This results to the missing "TPMS" and the remaining string "Solar" in the state topic. I could fix this for me by removing the type key from the naming_keys: //const char naming_keys[5][8] = {"type", "model", "subtype", "channel", "id"}; // from rtl_433_mqtt_hass.py const char naming_keys[5][8] = {"model", "subtype", "channel", "id"}; // from rtl_433_mqtt_hass.py Now the MQTT messages are looking good, but until now the Thing does not appear in my openHAB inbox. I will test this further on.

[riegelbrau]

When I use a sensor, that is not already present in openHAB, the corresponding Thing appears in the Inbox. So this case is now working for me. But how to create a universal fix for this? Does somebody know, how to add the type key in the code above when creating the idWoKeyAndModel? It then should the be named idWoKeyAndModelAndType.

[riegelbrau]

I checked the source code of rtl_433_esp and figured out, that the type is published only for the TPMS sensors. So all these sensors will run into this bug. Furthermore I've got managed to create a version on platform.io that works with the type included in NAMING_KEYS. I tested with my Jansite-Solar sensor and it works with openHAB. How to proceed in contributing the code? How to create and test a PR?

I was a programmer in Assembler, Cobol, LotusScript and some scripting languages, but I'm not familiar with the frameworks used here. Please advise, what to do or where to read how to proceed.

Regards Christoph

[1technophile]

You can start by downloading GitHub desktop, create a branch, push it and submit a PR from it.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity.

[riegelbrau]

This issue should be solved by #1960.