Auto discovery fro Home Assistant is not consistent for Dallas sensors about ems-esp32 HOT 21 CLOSED

Hi,
I also found the issue with '-' in the names the other day as I experimented with a bash script to analyze the best format.
Meanwhile I have added a third HA format that uses the sensor ID instead the volatile sensor number.
(no '-' in the names)
Also added a global name to the 'dev' node (so HA does not use the very first sensor name anymore as fallback).
I have cloned the project and will send a pull request next week or so.

Dieter

from ems-esp32.

Thanks for reporting. I haven't tested the Dallas changes on the ESP32 yet so this is probably a bug.

from ems-esp32.

Hi,
if you can give me some hints how it should look (or a working version number), then I can create a pull request.

from ems-esp32.

It is in dallassensor.cpp line 325: ha should stick to format NUMBER
correct line:

    uint8_t dallas_format = Mqtt::ha_enabled() ? Mqtt::Dallas_Format::NUMBER : Mqtt::dallas_format();

from ems-esp32.

I can confirm that the change from Michael works.
Shall I provide a pull request or do you change yourself? (it is a simple change, just one word needs to be changed)

A nasty effect of the NUMBER format is that the numbers to ID assignment is volatile.
I added two more sensors and my nice names I had assigned in HA are now mixed up.
The reason is how the sensors are found - this is by design of the one wire bus.

Two workarounds come to my mind:
1: use the unique_id from the sensors as the index (not sure how this could be done in HA)
2: add some code that allows to name the sensors inside the EMS-ESP

Dieter

from ems-esp32.

3: replace the names E.G. "DALLAS SENSOR 1" with a name based on the ID of the sensor.
That seems the easiest solution from my point of view.
Only a very few lines....

Though it is breaking change for existing users. Making it an option adds more work to the web interface. Conditional compile?

Dieter

from ems-esp32.

I've fixed the format in esp32_dev. Thanks for testing.

We had the discussion about sensor format some times. I also prefer the ID, but most people want a readable number and change sensors rarely. If you only want to test something,with additional sensors, add a sensor while running, than the new sensor is added last to the list. Only on reboot the list is sorted new.

I don't have HA, so i can not test the discover feature. But if you want to try, you have to adapt the HA discover settings in dallassensor.cpp to use ID format if selected.
I think it is mainly "val_tpl" and "name" to set to the id-format.
line 325 : uint8_t dallas_format = Mqtt::dallas_format();
line 358: if (dallas_format == Mqtt::Dallas_Format::SENSORID) { snprintf_P(str, sizeof(str), PSTR("{{value_json.%s}}"), sensor.to_string().c_str()); } else {...
line 362: if (dallas_format == Mqtt::Dallas_Format::SENSORID) { snprintf_P(str, sizeof(str), PSTR("Dallas Sensor %s"), sensor.to_string().c_str()); } else {...

and maybe something else to make it work.

from ems-esp32.

Hi,
I forked to make experiments. After I have a solution I will provide a pull request.

My hope is that I find a solution inside HA. The ID is transferred already, so perhaps only the auto discovery string needs adjustment.

PS: After cloning to local it did miss the (generated) file WWWData.h. Had not seen this in my older tries.
Perhaps the order of the build is not correct and a virgin build fails? (I did not change anything yet).
With that file from my first (other directly) try it builds fine)

from ems-esp32.

the WWWData.h file is created by a script which platformio.ini calls (pre:scripts/build_interface.py) so it should build, if you have npm installed.

from ems-esp32.

I found a bug in the dallas sensor HA Discovery. You can't use dashes '-' in the topic name. fixed now.

from ems-esp32.

Hi @FauthD , I was reviewing your PR and I don't think it's needed anymore. If you want to perserve the Dallas ID's to keep the order, use the MQTT format called 'sensor ID' and in HA they will show up as sensors with underscores, like:

from ems-esp32.

Hi Proddy,
in my test with emulated mqtt (bash script with mosquitto_pub) I found that HA does not like the hyphens).
The first idea was to use the SensorID format.
I will do a retest and provide the results.

The other changes are regarding the missing name for the group of sensors. That is still a good thing.

Will test now.

from ems-esp32.

Hi Proddy,
test results:
HA needs the sensor name to start with an ALPHA character and there must be no hyphens. I also had seen that in the docs.
With SensorID format it creates the logical sensor objects, but they do not receive values and stay "unknown".

These are the MQTT topics I sent to emulate the SensorID format:
testfh/dallassensor_data {"99-1234-5678-0000":"temp":20.0,"99-1234-5678-0001":"temp":21.0,"99-1234-5678-0002":"temp":22.0}

And the discovery topic:
homeassistant/sensor/testfh/dallas_99-1234-5678-0000/config {"dev_cla":"temperature","stat_t":"testfh/dallassensor_data","unit_of_meas":"°C","val_tpl":"{{value_json.99-1234-5678-0000.temp}}","name":"99-1234-5678-0000","uniq_id":"dallas_99-1234-5678-0000","dev":{"ids":["testfh"],"name":"Myname","mf":"Fauth","mdl":"Test"}}

There is a chance that my emulation does something wrong, so please review the topics above (4 eyes see more..)
What wonders me is that your screenshot shows values. And I recall I had seen values in some early experiments as well.
Perhaps it is the version of HA? I currently use "Home Assistant 2021.2.3" and for sure have updated between my early tests and now.

Many regards, Dieter

from ems-esp32.

Do you have a link what exactly in HA is not allowed?
As far as i understand @proddy this topic: homeassistant/sensor/testfh/dallas_99-1234-5678-0000/config
is not allowed, but a change to homeassistant/sensor/testfh/dallas_99_1234_5678_0000/config
is ok.
All other values are allowed with hyphens. Do you have other information?

In your example {"99-1234-5678-0000":"temp":20.0} is not valid json. and {value_json.99-1234-5678-0000.temp} would point to a nested json {"99-1234-5678-0000":{"temp":20.0}}
We have now plain json {"99-1234-5678-0000":20.0} and {value_json.99-1234-5678-0000} which fits.

If HA needs a change in uniq-id or name we can also change there the - to _

from ems-esp32.

Hi Michael,
just saw that my value topic was wrong from experimenting.
Here is the correct one:
testfh/dallassensor_data {"99-A234-5678-0000":20.0,"99-B234-5678-0001":21.0,"99-C234-5678-0002":22.0}

And the discovery topic:
homeassistant/sensor/testfh/dallas_99-A234-5678-0000/config {"dev_cla":"temperature","stat_t":"testfh/dallassensor_data","unit_of_meas":"°C","val_tpl":"{{value_json[99-A234-5678-0000]}}","name":"99-A234-5678-0000","uniq_id":"dallas_99-A234-5678-0000","dev":{"ids":["testfh"],"name":"Myname","mf":"Fauth","mdl":"Test"}}

Same results.
I will search the name validation for HA again.

'_' works, that is something I have tested. But then decided to remove that since most other projects do not add these.

from ems-esp32.

Hi,
here are my two script files (renamed .sh to .txt for the forum).
It is trow away code. They use the hyphens and have no ALPHA as first char in names.

config.txt
discover.txt
send.txt

from ems-esp32.

This talks about some details:
https://www.home-assistant.io/docs/mqtt/discovery

The ID of the node must only consist of characters from the character class [a-zA-Z0-9_-] (alphanumerics, underscore and hyphen).

Finally I found something about names:
https://www.home-assistant.io/docs/configuration/troubleshooting/
Pretty much at the end of the page:

ENTITY NAMES
The only characters valid in entity names are:
Lowercase letters
Numbers
Underscores
If you create an entity with other characters then Home Assistant may not generate an error for that entity. However you will find that attempts to use that entity will generate errors (or possibly fail silently).

But that is still not what we search for.
I checked with https://jsononline.net/json-validator#:~:text=How%20to%20Use%20JSON%20Validator%20by%20JSONonline.net%3F%20These,be%20shown%20in%20front%20of%20your%20screen%20quickly. and the hyposn are ok.

Will keep searching.

from ems-esp32.

I dont use HA, i can not test anything with HA, only check with mqtt exlorer that the structure is as expected. But i dont know what i have to expect. The only description i found here: https://www.home-assistant.io/docs/mqtt/discovery/, but this allows hyphens. Now what's wrong? In exactly which field are the hyphens forbidden?

The discovery topic need to follow a specific format:
<discovery_prefix>/<component>/[<node_id>/]<object_id>/config

    <component>: One of the supported MQTT components, eg. binary_sensor.
    <node_id> (Optional): ID of the node providing the topic, this is not used by Home Assistant but may be used to structure the MQTT topic. The ID of the node must only consist of characters from the character class [a-zA-Z0-9_-] (alphanumerics, underscore and hyphen).
    <object_id>: The ID of the device. This is only to allow for separate topics for each device and is not used for the entity_id. The ID of the device must only consist of characters from the character class [a-zA-Z0-9_-] (alphanumerics, underscore and hyphen).

from ems-esp32.

So far I did not find yet the valid character definitions. Will ask in HA forum.
But I can tell that things start to work if we remove hyphens and add a ALPHA character.
So this topic payload does not work:
testfh/dallassensor_data {"99-A234-5678-0000":20.0,

and this works:
testfh/dallassensor_data {"D99A23456780000":20.0,

from ems-esp32.

Hi,
the name limitations do no really apply anymore. What I had seen was for older version and came from Python2 (Jinja2).
And I had an error in my bash script for testing: This string did miss the "'":
"{{value_json['99-A234-5678-0000']}}".
Now it looks like it works with the hyphens and without the extra alpha character.

Sorry for the confusion that I created and thanks for your patience !!

I am going to revoke my changes regarding the HA_UNIQUE format since it is really superfluous.
But will send another pull request with the global device name for further discussions. That would improve behavior with HA.
Shall we open a new topic for this? Or can we discuss in the pull request? (I have not much experience with Github, comming from BitBucket).

Dieter Fauth

from ems-esp32.

@FauthD could do that PR again on this repo branch?

from ems-esp32.