I am pretty new to my sensors. Definitely new to creating pcbs. But I did manage some how to create a small pcb in eagle, did the laser toner transfer method and etched it at home, drilled the holes and soldered it all up and go it working. Next step is to design and 3dprint my custom case and get it mounted.

Thanks for all the help you guys have given me.

Hey Guys,
Figured I would try to start a new thread for this. Last week I posted the code so far as I have for the milight integration in to 2.0 here.

https://github.com/brunkj/MySensorsMiLight

I have not been able to work on it since. If anyone wants to take a crack at it and has some milights, feel free

I think this could be a very cheap way to replace hue and the $$ that goes with it.

My uploaded code as of now will allow you to pair with your bulb, you have to send the "ON" command with in something like 3 seconds of turning on your light. That's how it pairs. Once you pair, you can send on and off. There is code there from previous versions for some of the other stuff like color change and dim. But I have not figured that part out as far as how I need to send the data.

If @ted is still around he may be able to help even more so since he wrote the original. Im just hack jobbing his code up to 2.0 lol

So, I have looked in to this. I even had a fitbit that i was hoping to use to determine if I fell asleep at night and turn off lights in my home automation system.

The down side I ran into is this. I had fitbit setup with ifttt since that was something it could interface with. The sleep detection worked. HOWEVER. It only actually posted info to IFTTT when you woke up, at that point, all sleep related data was submitted. So it didn't track it real time.

I have been looking in to how to integrate sleep in to my HA but also like you mentioned quality of sleep. The fitbit utilizes motion to determine "restless" sleep. Attaching a bunch of sensors to myself doesn't seem like it would yield comfortable natural sleep. So potentially stuff like a mesh of piezo sensors under a mattress topper would work. that would detect when the values change indicating turning, movement.

Temperature should be easy (fitbit probably does it, i had a cheap one so it did not).

If you want to get crazy (which if i had time i would go this route) you can get a fitness watch with a certain chip in it, and reprogram it.

https://www.youtube.com/watch?v=SBHyQ1OSM-4

That's what he did. This could be REALLY REALLY cool. You could code in your own parameters and what not, since it's bluetooth LE you could track it via phone or just remote sensors.

Once you have some basic "restless" night tracking you could do some experimenting (even with the fitbit).

• track your sleep for a week or 2 to get a baseline of how much time each night you sleep "restless"
• change thermostat temp up/down - track again and compare.
• monitor body temp and see if warmer/colder = restless. find sweet spot.
• integrate body temp monitor to HA system to control thermostat to keep you correct temp

If you make any progress, definitely let me know, i would be interested to see what you come up with!

any plans to add an RTC on this and be able to timestamp the log entries? I have some sensors that only wake up and do readings every 90 minutes. But sometimes they just stop doing it. So time stamps on the logs would be good to see if there is anything happening right around the time it stops reporting.

So I have a new development. I noticed something strange. The mysgw stopped again today. I went digging through the syslog around the same time. Didn't see anything just before it went offline, but i did notice that shortly after it went offline it said that the carrier dropped for the nic.

Apr  2 15:50:55 raspberrypi mysgw: TSF:MSG:READ,200-200-0,s=2,c=2,t=25,pt=0,l=0,sg=0:
Apr  2 15:50:55 raspberrypi mysgw: GWT:TPS:TOPIC=mygateway1-out/200/2/2/0/25,MSG SENT
Apr  2 15:51:07 raspberrypi mysgw: TSF:MSG:READ,200-200-0,s=2,c=1,t=23,pt=2,l=2,sg=0:25
Apr  2 15:51:07 raspberrypi mysgw: GWT:TPS:TOPIC=mygateway1-out/200/2/1/0/23,MSG SENT
Apr  2 15:52:27 raspberrypi dhcpcd[377]: eth0: carrier lost
Apr  2 15:52:27 raspberrypi kernel: [  461.474897] smsc95xx 1-1.1:1.0 eth0: link down
Apr  2 15:52:28 raspberrypi dhcpcd[377]: eth0: deleting address fe80::669:d81d:83fb:3aaa
Apr  2 15:52:28 raspberrypi avahi-daemon[226]: Withdrawing address record for fe80::669:d81d:83fb:3aaa on eth0.
Apr  2 15:52:28 raspberrypi avahi-daemon[226]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::669:d81d:83fb:3aaa.
Apr  2 15:52:28 raspberrypi avahi-daemon[226]: Interface eth0.IPv6 no longer relevant for mDNS.
Apr  2 15:52:28 raspberrypi dhcpcd[377]: eth0: deleting default route via 192.168.2.1
Apr  2 15:52:28 raspberrypi dhcpcd[377]: eth0: deleting route to 192.168.2.0/24
Apr  2 15:52:28 raspberrypi avahi-daemon[226]: Withdrawing address record for 192.168.2.71 on eth0.
Apr  2 15:52:28 raspberrypi avahi-daemon[226]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.2.71.

So i decided to check a few other times in the last 48 hours and sure enough. Same thing. It seems that something is causing the nic to think it lost it's connection to the switch. The mysgw seems to go in to a weird state. Not sure what error checking is in it or what i could do to log more since i am already on debug for the logging of mysgw.

Next step i guess will be instead of dhcp reservation ill static assign it. See if that changes anything, and see swap network cable. Maybe hard set some things like the speed/duplex on the switch.

Just figured i would throw out my latest finding.

Ok I got it to work. I misunderstood how the interrupts worked. Got it now. The culprit was the if statement detecting if the state changed. Since the state was being maintained while sleep, it wasn't firing when I pushed the button.

Thanks for everyones help!!

@zboblamont good to know! I have 2 florescents in my garage that i swapped for LED. These didn't need to bypass the ballast. Might be worth a test to swap those out for the ones in the bathroom (where i see the most interference)

Guess i know what im going to try when i get home!

So a little new info. Last night i had the lights turn off with the door closed, and no one turned on/off the kitchen/bathroom lights. But what did happen, I turned off a little space heater in my room. When i turned it off, the lights off. Finding this very interesting, i grabbed my phone (in the dark) and check the HA status. The motion detection was triggered... ok... so maybe it's not the PIR/repeater that's the issue...

It's the LIGHT MODULE!! There is a good chance that the power fluctuations aren't messing with the repeater itself, but actually resetting the arduino with my lamp relays. I think this weekend i need to pull that out, check the code to see if i am saving state to eeprom and also throw some capacitors on the incoming power to see if that helps.

Is there anything like this going to be done in the US? I would love to help/attend.

@mfalkvidd roger that

I am finally getting around to trying this out. I was playing with just trying to see if i can get the pulses. First thing i did was take an old compass and put it beside the meter and had someone turn on the water. I could definitely see the compass needle pull a little as the water was flowing. So I assumed that pull was enough to be detectable with my hall effect sensor. I have tried a couple, and just can't seem to get it to pick up.

If i use a magnet, simple code will detect the pulse and the green led on the sensor lights up.

But no matter where I put that sensor near the meter it just doesn't seem to detect it. Not quite sure what's happening.

The meter i have is this one.
https://www.badgermeter.com/resources/add29b88-1ffb-49c9-80ab-bb8697bd6d1a/absolute digital encoder product data sheet ade-ds-00183-en.pdf/

Not sure if anyone has any recommendation on which hall effect sensor would be the best for this but ill take suggestions lol

My sensor I am testing with is
3144E Hall Effect Sensor

Doesn't have a sensitivity dial but the recommended one on this build page didn't either.

I second this. I went the mqtt route as well. Auto discovery is cool, but i wanted some additional control. My openhab 2.5 I don't use the UI at all. I just all flat files. This is a preference for me. I also use the VSCode extension for openhab and it works BEAUTIFULLY!

Do you have any install documentation for it? Any docs for integrating into existing snips setup?

I am going to be checking this out. I have been working with snips on some other stuff, so this could be very interesting.

@zboblamont actually it was more of a "not completed" type of thing. i didn't finish the connection between the bottom part that houses the sensor and the top cap. so it got knocked over and water soaked in. so i will be redoing it and will just complete it this time

I made a sensor like this myself. i took a non-water proof one and drilled holes to match the sensor in some plexiglass. and sealed around it with silicone. This worked until florida tried to drowned me out and flooded my entire sensor housing lol

I ended up setting up some monitoring that if by some chance it does go belly up my monitoring will do a recovery action. But it does still happen from time to time, which is strange.

I recently had alot of issues with my pi gw too. One of the things I found REALLY helped was on my switch I set the speed and duplex to 100mb FULL. In my syslog around the time my GW stopped responding, I was seeing messages about the "carrier lost" on the nic. Not sure what caused that, but it seems like it was taking quite some time to renegotiate. Now that I have it set to 100 FULL my issues have gone from 1-2 a day to only once in 3 weeks.

Also, make sure you have plenty of power for your PI. I have noticed one of the first things that seems to flake out on me when i have a sub par power supply for the PI is the network.

Not sure it my experience will help but figured I would try

So here's the latest.

I checked and the PI was already set to static ip and not dhcp reservation. However, I made 2 changes and have been ok for 3 days now.

1. i changed ports on the switch. Not sure if it mattered, but i have plenty.
2. this is the one I think may have more impact. Since it seemed the carrier was dropping, but coming back, I started wondering if maybe something was triggering an auto renegotiation for nic speed. So I went in to the switch and have it hard set to 100 FULL instead of auto.

I still have the debug running and gonna let this run for quite some time just to make sure im feeling it's ok.

compiled with new (very noisy) options lol

Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17
Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17
Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17
Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17
Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17
Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17
Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17
Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17
Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17
Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17
Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17
Apr 03 13:50:48 DEBUG RF24:RBR:REG=23,VAL=17

No idea what that means, but it seems if i am seeing that, it's working lol.