Home Weather example bug fixes and updates

[axelclark]

This update fixes HomeWeatherDisplay.init/1 argument and HomeWeatherDisplay.handle_info/2 return format bugs. I increased the polling interval to 30s to minimize flicker. I shortened the text to get it to fit on the top line (I don't think the current GrovePi.RGBLCD implementation uses the second line). I made a couple other minor updates. It also adds the generated rel/config.exs file (not sure if this should be part of the project or included in .gitignore).

[fhunleth]

It sounds like you ran into two LCD bugs. The flicker is due to a bug that I copied over from the Python code. 30 seconds between updates is fine and certainly sufficient for this use case, but is the flicker bothersome at one update/second? As for the single line, I saw that once and then couldn't reproduce it. I can get two lines over here, but I know that when I reproduced the single line bug, it didn't go away all evening. Working around both for now seems reasonable.

[axelclark]

Since an event is triggered when either the humidity or temp changes and there is no threshold for a change in DHT11.DefaultTrigger, the LCD is getting pushed constant updates when polling is at 1 second.

[adkron]

Should we update the trigger to handle handle the changes a little better or is the code here a better place to handle it?

[axelclark]

For a home temperature/humidity display, I think polling every 30 seconds is fine. If it was a digital food thermometer then maybe every second or less would be necessary. In fact, it may be able to handle 1 second polling, I just found the default of .1 second to be too frequent.

What are you ideas for modifying the trigger? I considered making the change be greater than 1 before an event is triggered, but looking at the output I'm not sure that will solve the problem. Many of the readings vary by greater than 1, so the events are still going to be coming in constantly. I think it is probably fine in the code unless you have a good way to update the trigger.

[adkron]

How about a moving hysteresis trigger? The range could change by moving only one degree as long as that degree is in the same direction as it recently changed. If it moves in the opposite direction it must move two degrees to trigger.

20 C -> 21 C (trigger) -> 22 C (trigger) -> 21 C (no trigger) -> 22 C (no trigger) -> 20 C (trigger) -> 20 C (no trigger) <- 18 C (trigger)

I know that is a complicated example, but I hope it clarifies what I'm trying to say.

Another option would be to say that it has to change in the same direction for a certain amount of polls. This is closer to a trigger bounce algorithm.

[axelclark]

I don't think we'll ever be able to poll at the default 100 ms because the RGBLCD.set_text/1 function requires 100 ms to execute:

defmodule GrovePi.RGBLCD do
...
  def set_text(text) do
    send_text_cmd(0x01) # clear display
    Process.sleep(50)
    send_text_cmd(0x0c)
    send_text_cmd(0x28)
    Process.sleep(50)
    send_chars(text)
  end
end

With the Python Home Weather Display project, the reading from the DHT and writing to the RGBLCD are synchronous. With the Poller process, our reading/writing are async so the polling interval needs to be considered.

I reduced the polling interval to 1_000 ms and it is working fine. 30 seconds may have been excessive to solve the problem mentioned above. I can push an update to reduce the polling to 1_000 ms with no issues.

With one second polling, the DHT is getting triggered between {22, 34} and {20, 23} maybe every every 10s. I don't why it would be getting these different readings. I'm not sure what the right hysteresis approach would be for these types of readings or whether it is worth complicating the trigger to address these readings.

[adkron]

Sounds good to me. Let's just update the interval for the example. I'll play with the sensor, hopefully while on vacation next week.

Amos King Binary Noggin

On May 24, 2017, at 15:03, Axel Clark notifications@github.com wrote:

I don't think we'll ever be able to poll at the default 100 ms because the RGBLCD.set_text/1 function requires 100 ms to execute:

defmodule GrovePi.RGBLCD do ... def set_text(text) do send_text_cmd(0x01) # clear display Process.sleep(50) send_text_cmd(0x0c) send_text_cmd(0x28) Process.sleep(50) send_chars(text) end end With the Python Home Weather Display project, the reading from the DHT and writing to the RGBLCD are synchronous. With the Poller process, our reading/writing are async so the polling interval needs to be considered.

I reduced the polling interval to 1_000 ms and it is working fine. 30 seconds may have been excessive to solve the problem mentioned above. I can push an update to reduce the polling to 1_000 ms with no issues.

With one second polling, the DHT is getting triggered between {22, 34} and {20, 23} maybe every every 10s. I don't why it would be getting these different readings. I'm not sure what the right hysteresis approach would be for these types of readings or whether it is worth complicating the trigger to address these readings.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[axelclark]

Ok, I've updated the polling interval to 1 second. Let me know if you see anything else that should be updated. @fhunleth and @adkron, thanks for your help and guidance! It has been really cool to have the opportunity to contribute to this project!

[adkron]

Thank you so much, @axelclark, ❤️