home-climate-control / esphome2influxdb Goto Github PK

To reproduce

Cause a NaN payload to be produced by any of the ESPHome devices (for example, physically disconnect a 1-Wire sensor without restart).

Expected behavior

Application keeps working, having logged a problem.

Actual behavior

Application breaks for good with the exception message below. Deferred sample queue grows until it hits the limit and samples start to be dropped on the floor (queue poisoning).

Relevant log entries

2020-12-17 16:22:09,012 DEBUG MqttReader MQTT Call: 607fa016-76a2-4aa5-9297-4215e5fdff2a [messageArrived] topic=/esphome/45FB71/sensor/water-heater-out/state,
 message=nan
2020-12-17 16:22:09,013 WARN InfluxDbWriter MQTT Call: 607fa016-76a2-4aa5-9297-4215e5fdff2a [messageArrived, consume] can't write sample, deferring remaining
1 samples for now
 java.lang.NumberFormatException: null
        at java.math.BigDecimal.<init>(BigDecimal.java:497) ~[?:1.8.0_252]
        at java.math.BigDecimal.<init>(BigDecimal.java:383) ~[?:1.8.0_252]
        at java.math.BigDecimal.<init>(BigDecimal.java:809) ~[?:1.8.0_252]
        at com.homeclimatecontrol.esphome2influxdb.InfluxDbWriter.consume(InfluxDbWriter.java:147) [esphome2influxdb.jar:?]
        at com.homeclimatecontrol.esphome2influxdb.MqttReader.consume(MqttReader.java:227) [esphome2influxdb.jar:?]
        at com.homeclimatecontrol.esphome2influxdb.MqttReader.consume(MqttReader.java:189) [esphome2influxdb.jar:?]
        at com.homeclimatecontrol.esphome2influxdb.MqttReader.messageArrived(MqttReader.java:165) [esphome2influxdb.jar:?]
        at org.eclipse.paho.client.mqttv3.internal.CommsCallback.deliverMessage(CommsCallback.java:514) [org.eclipse.paho.client.mqttv3-1.2.2.jar:?]
        at org.eclipse.paho.client.mqttv3.internal.CommsCallback.handleMessage(CommsCallback.java:417) [org.eclipse.paho.client.mqttv3-1.2.2.jar:?]
        at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:214) [org.eclipse.paho.client.mqttv3-1.2.2.jar:?]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]

As an Application Maintainer, I want to enable test coverage calculation as a build pipeline so that I can have an idea about what code can be (somewhat) trusted.

Expected Behavior

Kotlin native MQTT client is used in Kotlin code.

Actual Behavior

Eclipse Paho MQTT client is used. Not cool.

Candidates

• https://github.com/davidepianca98/KMQTT

Expected Behavior

Wiki reflects the current state of affairs

Actual Behavior

The expected behavior is unattainable since different branches of the code, a lot of them long lived, may exhibit totally different behavior and may be affected by totally different bugs.

Corrective Action

Move the documentation to version controlled code base, retain links to the documentation in Wiki, along with MOST basic FAQ answers.

See Also

home-climate-control/dz#276

Expected Behavior

ESPHome devices appear automagically

Actual Behavior

Everything needs to be configured by hand

Acceptance Criteria

• ESPHome devices configured with MQTT Client Component are recognized as such;
• Configuration entry templates are emitted so that they can be incorporated into persistent configuration;
• A flag must be provided to allow automatically discovered devices to start emitting InfluxDB feeds immediately, regardless of whether a persistent configuration entry exists.

Description will be provided upon completion

Eclipse Paho MQTT client seems to be lagging, while HiveMQ is in active development. Not to mention the annoying issue with creating random directories.

Actual behavior

Need to provide the configuration.

Desired behavior

The application starts up and starts producing at least something exciting with no need to configure it.

Small isolated project. Why not?

At this point, there are no plans to turn the project over to Kotlin completely, let's shake things down and iron out the wrinkles.

It would be nice to have this application run unattended as a background process.

Desired Behavior

When the configuration file changes, the configuration is reloaded

Actual Behavior

The application needs to be restarted in order to read the new configuration. Uncool.

Reference: https://github.com/home-climate-control/esphome2influxdb/runs/1544440044?check_suite_focus=true

Root cause: ErrorProne requires special treatment with JDK 1.8

Because reasons.

References:

• #19
• Kotlin Flow

Self-explanatory.

Expected result

MQTT connection stays on as long as the broker is up

Actual result

MQTT connection drops once in a while

Expected behavior

The application can be accessed, monitored, and configured without a restart via Web interface

Actual behavior

None of that is happening

Because why not. Opens up startup latency improvements (not that you need them once in 6 months) and bridges to Kotlin Flow.

Action taken

Two sensors configured, with following parameters:

• Same topic prefix
• room-0-temperature source for one
• room-0-temperature-1wire source for the other

Expected result

• Two tags are created in the InfluxDB database, room-0-temperature and room-0-temperature-1wire

Actual result

• Samples for the sensor with a longer source are improperly matched to the sensor with the shorter source - both samples end up with the same (shorter) source tag (room-0-temperature).