Support of homeduino local sensors and weather protocols

[roku133]

Hi rrooggiieerr,

excellent job enabling us to continue with our homeduino implementations in HA.

You have mentioned that you are currently supporting protocols you personally need - this is completely understandable.
Looking into the protocols folder of rfcontrolpy two weather protocols (7, 19) are already available.
File sensor.py seems to basically support local sensors (DHT).

Is there an option to support them in homeassistant-homeduino with limited additional effort?
This extension would be great.

No problems for me to support testing.

[rrooggiieerr]

You can indeed add any missing protocols to rfcontrolpy, just follow any of the other protocols as an example together with the original rfcontroljs code. I think it should be straight forward.

You can then use the Homeduino CLI to test your protocol

[roku133]

Thank you for your explanation.
Existing pimatic protocols may indeed be converted to python based on your examples.
The bigger issue for me is to integrate them afterwards into homeassistant-homeduino since weather protocols 7 and 19 are already available in rfcontrolpy but no accessible in the homeassistant integration. There, weather protocols can not be selected in the configuration part.

[rrooggiieerr]

Ah, I see what you mean. Yes, the HA integration needs some work to implement sensors.
You need to be in sensor.py to implement that

[rrooggiieerr]

If you enable logging of the Homeduino integration do you see any messages from your weather sensors?

[roku133]

Thank you very much for your extensions. 👍

Since I do not use HACS and to avoid any update issues I installed your recent build from scratch after deleting the existing configuration.
The transceiver and a first switch has been added but according to the log the protocol file "switch 1" throws an error. Therefore, the switch does not work.
Great - the weather raw data (protocol weather 4) seems to be available.

My local sensor DHT 22 is connected to GPIO 14 which cannot be selected (pinout attached).

Files:
home-assistant.log
ESP8266_Pinout_Diagrams.pdf

[rrooggiieerr]

Sorry, but this integration is only developed for the original Arduino Nano based Homeduino, and that one only goes till Digital IO 13.

The latest development also doesn't yet support DHT11/22, only digital in, digital out, analog in and PWM out.

You could move the DHT 22 to an other GPIO, but then support still needs to be added to the Homeduino library. The integration actually already has some work done to support DHT11/22 in the future.

[rrooggiieerr]

For switch1, there seems to be something going wrong in the rfcontrol library

[rrooggiieerr]

Did you have the problems with switch1 also with a previous version?

[roku133]

No, it worked without any problems.
Last successful build was from June, 22.

[rrooggiieerr]

Ok, should be fixed now in the latest Github code

[roku133]

again working ...

[rrooggiieerr]

DHT11/22 should now work too, but only on Digital IO 3 till 12

[roku133]

You finally convinced me to reopen my homeduino case and to do the necessary soldering. 😉

I have now selected GPIO 2 which is outside of the range given above. GPIO 2 is the only free pin on my board apart from GPIO 14 to GPIO 16.
There seems to be still a coding issue - see log below:
home-assistant_II.log

By the way, is it that problematic to expand the GPIO range up to 16 supporting also the capabilities of ESP devices which are widely used?

[rrooggiieerr]

GPIO 2 should actually work too. The first 2 GPIO are used for the serial port, and those are on GPIO 0 an 1, hence the confusion from my side.

The goal of my homeduino integration was to support the original homeduino which is based on the Arduino Nano and which I have myself. If I start to support other boards than the Arduino Nano I open up a rabbit hole with all kind of specifications and setups. The next person want to have support for the Arduino Mega with 53 digital IO and 16 analog inputs. It's just not worth my effort my own free time after all.

Also, most people using an ESP will be using ESPHome I guess, which will integrate better in Home Assistant.

I'll look into the 'Homeduino' object has no attribute 'add_dht_read_callback', that should be in the new homeduino library, but apparently there's something wrong

[rrooggiieerr]

I think the latest version should work, try the new code and give it a try

[roku133]

Far enough, I understand your concerns and appreciate your activities.
Perfect, temperature and humidity now are available.

[rrooggiieerr]

You could also give the weather sensor a try. I couldn't test it myself due to lack of equipment

[rrooggiieerr]

Could you give the latest code a try?

[roku133]

Great, weather data of protocol weather4 are now available in the log. 👍👍
However, the related devices and entities have not been setup.
This seems to be a special issue of this protocol. During the setup of the remaining weather protocols 7 and 19 at least one device and one entity sensor.temperature and sensor.temperature_2, respectively have been generated. The remaining entities of weather7, humidity and lowBattery are missing.

Log:
home-assistant_IV.log

[roku133]

Meanwhile, I have added the missing protocol weather4 to both if statements and
native_unit_of_measurement to my local sensor.py.
As expected weather4 and weather7 now behave identical, only sensor.temperature will be generated, entity humidity is not available.

HA log reports the following error:
Platform homeduino does not generate unique IDs. ID weather4-94-3 already exists - ignoring sensor.temperature_2
Platform homeduino does not generate unique IDs. ID weather4-175-1 already exists - ignoring sensor.temperature

Concerning both devices temperature values will only be read once.

[rrooggiieerr]

Ah, I see what you did, and also why no unique id is generated, that's a bug in my code.

[rrooggiieerr]

Current Github code should now also support weather4 (I solved it in a bit more generic way) and generate a unique id

[rrooggiieerr]

I didn't create a sensor for lowBattery yet

[roku133]

Just tested your latest code.
At first, I have deleted the existing weather devices.
After setting them up again no devices / entities have been generated.
HA log doesn't show any entry.

Modified if statements now always false?

[rrooggiieerr]

Yes, there is something wrong wit the if statement, I went back to hard coded protocol names. Check again please

[roku133]

Device and entities are now available. 👍
Values are shown but there is no update.
Please also add native_unit_of_measurement as in the DHT case.

[roku133]

After the deactivation of the homeduino transceiver DHT entities show not available but the weather entities keep the old and outdated values.

[rrooggiieerr]

I don't own any of the hardware you have, so whatever I'm doing is a bit trial and error. I think the changes made are already quite substantial. Maybe you can first try to build further upon the available code and try to make it work.

[roku133]

Just a small finding in sensor.py:
Temperature value is not an integer therefore self._attr_native_value has to be changed.
...
try:
self._attr_native_value = values.get(self.field)
self._attr_available = True
...

[rrooggiieerr]

I don't see what the problem is and don't have any test data or hardware to test. Can you make the needed changes yourself and create a pull request?

[rrooggiieerr]

Ok, I see it, but you can still create pull request for future changes

[roku133]

The small change did it.
Due to integer values for the temperature no change was visible for a long period. Now it is perfectly working.

You are challenging me:
I will not be able to provide additional code due to my very limited python skills.
What I can offer is to continue testing and to try to (partially!) understand your code.
I see your challenge generating code without any chance to verify it due to lack of HW. Therefore, your results are impressive.
It would be great if you can still add lowBattery supported by my tests.

[rrooggiieerr]

Thanks for your contribution, both by means of coffee and with your pull request @roku133!

I will look into the lowBattery support, but only in August as I'm running a bit out of time before going on holidays. If you dare the challenge, the lowBattery should be implemented in the binary_sensor.py. In the async_setup_entry there needs to be added an extra elif entry_type == CONF_ENTRY_TYPE_RF_DEVICE and config_entry.data.get(CONF_RF_PROTOCOL) == "weather4": and then creating the sensor.

If you like to get involved in other ways you could also add a translation file for your language, I'm guessing German, by translating the custom_components/homeduino/translations/en.json and name it custom_components/homeduino/translations/de.json

[roku133]

Based on your hints I will try it. To be honest - I am not convinced that I will succeed.
No problem at all to wait till August.