Climate sensor

[Sonusss]

It would be nice if we could add climate sensors like DHT22 or similar...

[fvanroie]

You can add custom sensors if you compile your own binary, see this thread in the discussions.

[Sonusss]

Oh, I see but unfortunately my programing knowledge is not at the right level for this...

[fvanroie]

It's not that hard when you use a tool like gitpod. We have a guide for that in the documentation.

We can help with the coding by providing a custom template if you let us know the hardware that you are using. Basically it can be as simple as editing a few text files and press run.

In order to make an integrated sensor, we have to limit the number of supported sensors down to just a couple... I have no idea what sensors are the best, mostly used, cheapest, ... tbh. If it's manageable to include some for the less technically inclined, we can accommodate.

Feel free to join the discussion I linked to. It's OK to let us know that route is not for you. So it can still be an enhancement, but we need to limit its scope and offer a solution that benefits most users.

[Sonusss]

Thanks a lot ! I have already a lanbon L8 and played with your wonderful firmware. I'd like to add a AM2302 (DHT22) 1 wire temperature/humidity sensor which is very popular and cheap https://datasheetspdf.com/pdf-file/942482/ETC/AM2302/1

If you can provide the template I'll try to manage a build as suggested

[nagyrobi]

The Dallas DS18b20 is also a very simple, 1-wire universal temperature sensor, its biggest advantage is not only that it requires a single GPIO, but also that up to 254 of them can be connected in parrallel on the same pin, as they identify themselves towards the bus by their serial number.

[Sonusss]

I agree totally @nagyrobi Personally I would say that adding support for the 3 following sensors would cover almost every need:

• AM2302/DHT22 (1wire)
• DS18B20 (1wire)
• BME280 (I2C)

[nagyrobi]

Let's start small, first step 1 wire would be good enough.

[fvanroie]

Digging through my sensors bin, I don't seem to have any of these sensors. I'll order some from aliexpress but it's going to take a while to ship...

I might get my hands on a couple of Dallas sensors sooner though.

[EnricoSanchez]

First of all thanks for this great project. But could you please add the bme280 sensor for heating control. So I don't need any additional hardware to use the display better for smart room control

[fvanroie]

Adding a sensor not the hard part. But to what endpoint/topic does the sensor data need to be sent and in what format? On the receiving end there has to be a controller or some logic that processes these messages, like the Custom Component.

If I know what the message requirements are, it will be a lot easier to provide the data in a way that can be processed.

[Qargh]

(Not) One data model fits them all.

I'm sure if I ask nine people in wich form the collected data of a bme280 for example should be transmitted i will get ten answers :-). The Temperature for example:

• temp: "19.6 °C" -> will be nice to show it on a screen but for math you need to parse the value first.
• temp: 19,600 -> great for most european math. In USA ... oops ... you'll need a lot of ice. And by the way. °C or °F?
• temperature: 19.6, tempUnit: "Celsius" -> show on screen as it is ... no way ... but concatenating and localising may be easier then parsing ... hmmm

Going further:

• how should the data be structured if you have .. lets say two temp units to measure a delta? So what suggestion for a format is the right one?
• People out there all have their own preferences which sensors or other hardware they want to attach and what automatic behavior they need. If you take a short look at the Tasmota Firmware or ESP Easy you can see which dimensions the support of devices and ruled behavior can reach easily.

Lets see some more docs:

• Amazon Alexa
• Google Smarthome
• EnOcean EEP
• Tasmota firmware
• ESP Easy - BME280

Wow, keep this horse in check!

As I remember there are several requests (Issues and Discussions) to support alternative hardware within OpenHASP the last 2 years. But I think it will take some "glue" between the CUSTOM Interface and the different hardware implementations to get that managed.

Maybe:

• some more advanced examples on howto get managed a build and deploy pipeline for the firmware.
• some examples on how to create a "controller" on other Smart Home Systems (e.g. openHAB).
• some guidelines for the "glue".
• it's all there and i don't know the www links (if true, please tell me)

But to end the philosophizing. This is my suggestion for the data format.

{
  "custom": {
    "<topic compliant string>": {
      "customId": "<topic compliant string>",
      "meta": {
        "deviceType": "eg. BME208",
        "pressureUnit": "hPa",
        "tempUnit": "C"
      },
      "properties": {
        "lastUpdate": "<iso8601 utc zulu time>",
        "temperature": 21.7,
        "humidity": 66.6,
        "pressure": 988.6
      }
    }
  }
}

Remarks:

• Just read the json properties in chain as the custom topic (eg. /custom/CUSTOM_ID/properties/temperature)
• populate meta less more then properties and not in the "get sensor data" callback
• don't use an array's in the "custom" property or numeric indexes. Stay with a reasonable and informativ custom_id. It will make trouble if you want to do things like a JSON Merge or JSON Patch on more advanced "controllers" in the backend. And, be honest, what is "/plate_46/state/custom/8/xyz"?

Regards to all the lovely work on OpenHASP.

[EnricoSanchez]

Adding a sensor not the hard part. But to what endpoint/topic does the sensor data need to be sent and in what format? On the receiving end there has to be a controller or some logic that processes these messages, like the Custom Component.

If I know what the message requirements are, it will be a lot easier to provide the data in a way that can be processed.

For me, it would bei enough when in see im my mqtt Broker (i use iobroker with mqtt Adapter) an additonal datapoint, like for example a Display Button, but with the temperature , so i can use the state to control my heating valve and also send it back to the Display

[Janverhu]

I just finished my_custom.ccp which features a motion sensor and a dht22 temp/humidity sensor. I'm fairly new to c++, arduino and openHasp so comments are welcome. I thought some folks here would be interested... my_custom .cpp.txt

[Humancell]

There some other critical aspects to adding sensors into a device. You really must also include an identifier of exactly what part/chip/transducer is providing the data so that you can know the accuracy and range of the sensor.

We often think that getting the temperature or humidity is enough, but without understanding the accuracy of the part or where the reading is within it's operational range, your code could be making bad choices in controlling things.

[Janverhu]

Sure, for my application which is not a critical one it suffices to double check the numbers with another device I know is accurate. I had to change my design a couple of times and ended up with an external case for the sensor because the board gives off too much heat. But that’s the responsibility of the diy’er to do…

[fantasmisiciliani]

@fvanroie I added the arduino-sht library in platform-override.ini and wrote few lines of code in my_custom.cpp to read from an SHT31 sensor, but I found that Wire (first I2C port) is already initialized (Wire1 is used by the touchscreen) and I had to call Wire.end() before re-initializing it with my custom pins. In this way it works, but is there something I broke? I have a WT32-SC01 Plus with openHASP 0.7.0-rc2.