Feature request

[harfordhawk]

I love this code and it works great, but I want to use it to attach nodemcu to existing wired alarm panel. It works great for monitoring 2 'doors', and I really just want to be able to adjust code to use as many pins on the nodemcu as available and just get status messages from each, similar to the way it does now.. I am not so good at adjusting code to do that.. can you give me example code that just monitors those pins? thanks so much

[marthoc]

This would be easy to implement and in fact I’ve been thinking of releasing a new project that does exactly this - NodeMCU has 8 or 10 (I think) inputs that can be used for this, so could probably retrofit an existing alarm system with a few NodeMCUs pretty easily. Glad to know I’m not the only one that’s been thinking about it. If you give me a few days or so, I’ll get back to you with some code to test. Sound good?

[marthoc]

@harfordhawk Quick question - on your existing alarm system, do the wired sensors each have just two wires that connect to the existing controller?

[harfordhawk]

thank you! I hooked up to the door 1 and 2 with current code and it works pretty well! Great way to retrofit old alarm system that we really don't use!

On Thu, Dec 14, 2017 at 11:27 AM, Mark Coombes notifications@github.com wrote:

This would be easy to implement and in fact I’ve been thinking of releasing a new project that does exactly this - NodeMCU has 8 or 10 (I think) inputs that can be used for this, so could probably retrofit an existing alarm system with a few NodeMCUs pretty easily. Glad to know I’m not the only one that’s been thinking about it. If you give me a few days or so, I’ll get back to you with some code to test. Sound good?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/marthoc/GarHAge/issues/10#issuecomment-351761578, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKWFbP4z6Jw1IdIZjKuhacW9OvSkcmpks5tAUxrgaJpZM4RAu6n .

[harfordhawk]

well I am mostly interested in the simple door / window sensors so yeah, just simple magnetic switches 2 wires,, I ran a common from each to a ground on board then one each to d5 and d6

On Thu, Dec 14, 2017 at 11:35 AM, Mark Coombes notifications@github.com wrote:

Quick question - on your existing alarm system, do the wired sensors each have just two wires that connect to the existing controller?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/marthoc/GarHAge/issues/10#issuecomment-351763992, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKWFThvHar1Hm5CP8q2Cks4ku4LOV7rks5tAU40gaJpZM4RAu6n .

[harfordhawk]

by the way, I am trying to use it as a mqtt binary sensor... I am getting some slow to no responses in that mode, but not sure if it's just me or what

On Thu, Dec 14, 2017 at 11:38 AM, mack goodman mackgoodman@gmail.com wrote:

well I am mostly interested in the simple door / window sensors so yeah, just simple magnetic switches 2 wires,, I ran a common from each to a ground on board then one each to d5 and d6

On Thu, Dec 14, 2017 at 11:35 AM, Mark Coombes notifications@github.com wrote:

Quick question - on your existing alarm system, do the wired sensors each have just two wires that connect to the existing controller?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/marthoc/GarHAge/issues/10#issuecomment-351763992, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKWFThvHar1Hm5CP8q2Cks4ku4LOV7rks5tAU40gaJpZM4RAu6n .

[marthoc]

Hmm... you shouldn’t be getting “slow to no” responses; my experience is that the door state changes are reported virtually instantly. One way to start tracking down the cause is to connect the NodeMCU to your computer via USB (and thereby powering it over USB) and watching the serial monitor as you unplug one of the door sensor wires (simulating an open/close). The state change should be instantly reported on the serial monitor. If you can run mosquitto_sub in a different window at the same time with this command: mosquitto_sub -h your.broker.ip.address -t "#" -v ...you should see an MQTT message arrive at the broker instantly.

[marthoc]

Maybe also post your configuration.yaml entry for the binary sensor (unless you’re just using what I suggest in README.md).

[marthoc]

@harfordhawk I just added something for you to test: https://github.com/marthoc/EntrHAnce/releases. Please do and let me know how it goes! I've only verified that it compiles, but I haven't tested it at all yet myself. Please raise any issues on the EntrHAnce page, not here.

Closing this issue.

[harfordhawk]

thanks! I will let you know when I test it out

On Fri, Dec 15, 2017 at 12:14 AM, Mark Coombes notifications@github.com wrote:

@harfordhawk https://github.com/harfordhawk I just added something for you to test: https://github.com/marthoc/EntrHAnce/releases. Please do and let me know how it goes! I've only verified that it compiles, but I haven't tested it at all yet myself. Please raise any issues on the EntrHAnce page, not here.

Closing this issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marthoc/GarHAge/issues/10#issuecomment-351915661, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKWFa6EVsffd3Vc2sHEdv_rc7pKJuamks5tAgAtgaJpZM4RAu6n .

[harfordhawk]

been testing it and it loads fine . I see the publishing on the serial monitor Acouple of things...

1. it seems that I need about 5 seconds between open and close to be consistent. otherwise it sometimes does not toggle.

2. I can't find what the name of the topic is, at least it doesn't publish in HA

here is my config

binary_sensor 2:

• platform: mqtt name: "test Door" state_topic: "entry/1/status"

On Fri, Dec 15, 2017 at 7:50 AM, mack goodman mackgoodman@gmail.com wrote:

thanks! I will let you know when I test it out

On Fri, Dec 15, 2017 at 12:14 AM, Mark Coombes notifications@github.com wrote:

@harfordhawk https://github.com/harfordhawk I just added something for you to test: https://github.com/marthoc/EntrHAnce/releases. Please do and let me know how it goes! I've only verified that it compiles, but I haven't tested it at all yet myself. Please raise any issues on the EntrHAnce page, not here.

Closing this issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marthoc/GarHAge/issues/10#issuecomment-351915661, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKWFa6EVsffd3Vc2sHEdv_rc7pKJuamks5tAgAtgaJpZM4RAu6n .

[marthoc]

The info is in README.md of the dev branch, sorry. The topic is entry/pin# (so entry/1, etc.). You’ll also need to change the on and off payloads to open and closed.

[harfordhawk]

okay, sorry I did not read that... seems to be working except the response is sometimes incorrect when fast switching. that may be just a function of timing and asking too much from the mqtt ?? anyway thank you very much for this code!

On Fri, Dec 15, 2017 at 9:37 AM, Mark Coombes notifications@github.com wrote:

The info is in README.md of the dev branch, sorry. The topic is entry/pin# (so entry/1, etc.). You’ll also need to change the on and off payloads to open and closed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marthoc/GarHAge/issues/10#issuecomment-352021033, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKWFZsLyjVbHaci7Qc7cSrOt3o8ES0Xks5tAoQfgaJpZM4RAu6n .

[marthoc]

I think it’s related to the way I’m denouncing the switch inputs. I’ll test today and see if I can’t tweak it.

[marthoc]

Also - what MQTT broker are you using? If it’s the embedded broker, you might want to test with mosquitto to rule that out.

[harfordhawk]

i am running mosquitto on the Rpi.. seems to work fine for some other sensors I have.

Just a thought.. maybe there is a way to put a redundancy in to check status of pins? I don't know anything about that but just thinking

On Fri, Dec 15, 2017 at 10:05 AM, Mark Coombes notifications@github.com wrote:

Also - what MQTT broker are you using? If it’s the embedded broker, you might want to test with mosquitto to rule that out.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marthoc/GarHAge/issues/10#issuecomment-352028040, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKWFc6eBL7ZksPx0Hyspsl64pRtTblfks5tAorPgaJpZM4RAu6n .

[harfordhawk]

i have noticed with the garage code that if the door is opening and shut quickly it sometimes gets lost in the updates, then 30sec to a min later it reports correctly, usually.

On Fri, Dec 15, 2017 at 10:08 AM, mack goodman mackgoodman@gmail.com wrote:

i am running mosquitto on the Rpi.. seems to work fine for some other sensors I have.

Just a thought.. maybe there is a way to put a redundancy in to check status of pins? I don't know anything about that but just thinking

On Fri, Dec 15, 2017 at 10:05 AM, Mark Coombes notifications@github.com wrote:

Also - what MQTT broker are you using? If it’s the embedded broker, you might want to test with mosquitto to rule that out.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marthoc/GarHAge/issues/10#issuecomment-352028040, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKWFc6eBL7ZksPx0Hyspsl64pRtTblfks5tAorPgaJpZM4RAu6n .

[marthoc]

I think it’s my debounce code. Essentially, when an input changes state (either high to low or vice versa, meaning a door has opened or closed), the code says, take that as the new state and don’t accept any new state changes for 2 seconds (given that reed switches are very bouncy, when they change state they may open and close several times). This prevents the broker from getting several open/closed/open/closed/open messages. So with the garage code, which I’ve reused here, if you open a door and then close it right away, it’s not going to pick that up until the debounce time has passed and the next time through the loop when the input is read again.

But it should be on the order of a few seconds delay in the HA frontend, not 30s to a minute.

As to redundancy, the inputs are supposed to be read on each loop through the code, which should be happening many many times per second. So if there’s a different state, the code should be picking that up very quickly and reporting the change.

I will investigate more and see if I can replicate this, and maybe change the debounce code since this is an issue that affects GarHAge as well.

[harfordhawk]

could just be my HA code that is working too hard or not efficiently.. I got a lot of stuff reporting! haha

On Fri, Dec 15, 2017 at 10:33 AM, Mark Coombes notifications@github.com wrote:

I think it’s my debounce code. Essentially, when an input changes state (either high to low or vice versa, meaning a door has opened or closed), the code says, take that as the new state and don’t accept any new state changes for 2 seconds (given that reed switches are very bouncy, when they change state they may open and close several times). This prevents the broker from getting several open/closed/open/closed/open messages. So with the garage code, which I’ve reused here, if you open a door and then close it right away, it’s not going to pick that up until the debounce time has passed and the next time through the loop when the input is read again.

But it should be on the order of a few seconds delay in the HA frontend, not 30s to a minute.

As to redundancy, the inputs are supposed to be read on each loop through the code, which should be happening many many times per second. So if there’s a different state, the code should be picking that up very quickly and reporting the change.

I will investigate more and see if I can replicate this, and maybe change the debounce code since this is an issue that affects GarHAge as well.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marthoc/GarHAge/issues/10#issuecomment-352034869, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKWFRv0hLAED6FH7O5pfhMlLnQUKFoWks5tApFTgaJpZM4RAu6n .

[marthoc]

That could be it, honestly. Code in HA runs asynchronous meaning it gets scheduled for execution, and the Pi only has so many resources...

[marthoc]

OK so I had a chance to wire up my test unit. I'm not seeing any of the delays that you are with updating the state. Really the best way to check what part of your automation flow is responsible for the delay is to have the serial monitor open (and the NodeMCU connected to your computer via USB obviously), and also have a mosquitto_sub window open to watch for incoming messages at the broker.

When I change an input state (I've just wired the inputs to buttons I can push to pull the pin low), there's an instant message on the serial monitor and at the broker I'm watching via mosquitto_sub. So I think that your problem is either a faulty NodeMCU, some network latency, or latency introduced by running Home Assistant on the Raspberry Pi. My HA is set up on an Intel NUC so there's no concern about processing power there.

If you don't mind testing with the serial monitor and mosquitto_sub to help me verify that the latency is introduced outside of my code, I would appreciate it!

One snag I noticed is that D8 wasn't reacting properly; a bit of research revealed that you can't enable the internal pullup resistor on D8, so it can't be used for our purposes. That leaves 7 usable inputs per NodeMCU, which isn't bad - most existing alarm systems in sane-sided houses could probably be retrofitted with 2 or 3 NodeMCU's, I'd guess, which is still a pretty cheap way to do it.

Thanks for your help with this! Any other questions or comments please let me know.

[harfordhawk]

I did what you said and it seems to be working properly... I think my lag be associated with either overtaxed rpi or possibly flaky wifi in the area where the nodemcu is... thanks for your code again!

On Fri, Dec 15, 2017 at 2:28 PM, Mark Coombes notifications@github.com wrote:

OK so I had a chance to wire up my test unit. I'm not seeing any of the delays that you are with updating the state. Really the best way to check what part of your automation flow is responsible for the delay is to have the serial monitor open (and the NodeMCU connected to your computer via USB obviously), and also have a mosquitto_sub window open to watch for incoming messages at the broker.

When I change an input state (I've just wired the inputs to buttons I can push to pull the pin low), there's an instant message on the serial monitor and at the broker I'm watching via mosquitto_sub. So I think that your problem is either a faulty NodeMCU, some network latency, or latency introduced by running Home Assistant on the Raspberry Pi. My HA is set up on an Intel NUC so there's no concern about processing power there.

If you don't mind testing with the serial monitor and mosquitto_sub to help me verify that the latency is introduced outside of my code, I would appreciate it!

One snag I noticed is that D8 wasn't reacting properly; a bit of research revealed that you can't enable the internal pullup resistor on D8, so it can't be used for our purposes. That leaves 7 usable inputs per NodeMCU, which isn't bad - most existing alarm systems in sane-sided houses could probably be retrofitted with 2 or 3 NodeMCU's, I'd guess, which is still a pretty cheap way to do it.

Thanks for your help with this! Any other questions or comments please let me know.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marthoc/GarHAge/issues/10#issuecomment-352091359, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKWFY2V1dEJBEbOOTz8eCa7p7SbRDZCks5tAshUgaJpZM4RAu6n .

[bradcurtis]

Very cool,

I have the NodeMCU as well. I updated the code to include a temperature/humidity and motion sensors.