I do alot of various tinkering and post it it to youtube
http://bit.ly/CrankyCoder
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).
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.
@OldSurferDude I use this. https://www.homedepot.com/p/Orbit-Solenoid-for-Battery-Operated-Timer-57861/203151515
Instead of having to hold the valve open, i can just pulse it. I use a simple motor controller to pulse it and when i need to close it, pulse it in "reverse". That way I could use a battery and if it only opens once or twice a day it's only a half a second or so of draw off the battery.
What components are you using for the charge controller and the battery?
For the 3dprinted enclosure, what are you planning to do to keep it water tight?
I had a similar project last year but instead of the soil moisture sensor, I was using it to turn the water on/off to water the garden. That one needed a little more juice to trigger the locking solenoid valve so I had to do a 2s 18650 setup.
I see in your notes in the code that smartsleep didn't work for you?
I actually thought smartsleep with home assistant worked pretty well. What did you run in to?
Not sure if this helps or if anything jumps out, but here is the node and gateway side by side. Node does find parent request, gateway sees it, responds with 0. But node never gets it.
@skywatch unfortunately no. This is for a sprinkler valve that I haven't set up any automations for yet since the questionable reliability at the moment would flood my yard lol
@mfalkvidd said in smart sleep inconsistent?:
Btw, are you using MySensors 2.3 on the node and the gateway?
Correct 2.3 on node and gateway.
Got some more info. Here is some debug log off the gateway. The node in question is node 18
22:02:47.582 -> 28832653 TSF:MSG:SEND,0-0-18-18,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
22:03:51.377 -> 28896448 TSF:MSG:READ,18-18-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
22:03:51.422 -> 28896512 TSF:MSG:BC
22:03:51.422 -> 28896533 TSF:MSG:FPAR REQ,ID=18
22:03:51.468 -> 28896566 TSF:PNG:SEND,TO=0
22:03:51.513 -> 28896594 TSF:CKU:OK
22:03:51.513 -> 28896615 TSF:MSG:GWL OK
22:03:51.967 -> 28897026 TSF:MSG:SEND,0-0-18-18,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
22:05:01.405 -> 28966464 GWT:IMQ:TOPIC=mygateway1-in/10/1/1/0/40, MSG RECEIVED
22:05:01.497 -> 28966569 !TSF:MSG:SEND,0-0-53-10,s=1,c=1,t=40,pt=0,l=6,sg=0,ft=0,st=NACK:FFFFFF
22:07:04.200 -> 29089296 TSF:MSG:READ,18-18-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
22:07:04.246 -> 29089359 TSF:MSG:BC
22:07:04.292 -> 29089380 TSF:MSG:FPAR REQ,ID=18
22:07:04.337 -> 29089414 TSF:PNG:SEND,TO=0
22:07:04.337 -> 29089442 TSF:CKU:OK
22:07:04.382 -> 29089463 TSF:MSG:GWL OK
22:07:05.152 -> 29090214 TSF:MSG:SEND,0-0-18-18,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
22:10:01.430 -> 29266499 GWT:IMQ:TOPIC=mygateway1-in/10/1/1/0/40, MSG RECEIVED
22:10:01.521 -> 29266604 !TSF:MSG:SEND,0-0-53-10,s=1,c=1,t=40,pt=0,l=6,sg=0,ft=0,st=NACK:FFFFFF
22:10:59.660 -> 29324730 TSF:MSG:READ,38-38-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
22:10:59.706 -> 29324794 TSF:MSG:BC
22:10:59.706 -> 29324815 TSF:MSG:FPAR REQ,ID=38
22:10:59.751 -> 29324848 TSF:PNG:SEND,TO=0
22:10:59.797 -> 29324877 TSF:CKU:OK
22:10:59.797 -> 29324897 TSF:MSG:GWL OK
22:11:00.523 -> 29325594 !TSF:MSG:SEND,0-0-38-38,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
Running it through the log parser it would appear the gateway is responding to the find parent request.
BUT. The node it self seems to be failing to find parent periodically. Like it's not getting the message back from the gateway.
22:12:10.465 -> Going to sleep
22:12:10.465 -> 44562 MCO:SLP:MS=30000,SMS=1,I1=255,M1=255,I2=255,M2=255
22:12:10.465 -> 44572 !MCO:SLP:TNR
22:12:20.399 -> 54491 TSM:FAIL:RE-INIT
22:12:20.399 -> 54493 TSM:INIT
22:12:20.399 -> 54499 !TSM:INIT:TSP FAIL
22:12:20.444 -> 54501 TSM:FAIL:CNT=5
22:12:20.444 -> 54503 TSM:FAIL:DIS
22:12:20.444 -> 54505 TSF:TDI:TSL
22:12:20.489 -> 54575 MCO:SLP:MS=19999
22:12:20.489 -> 54577 !TSF:SND:TNR
22:12:21.035 -> 55080 TSF:TDI:TSL
22:12:42.255 -> 55083 MCO:SLP:WUP=-1
22:12:42.301 -> 55085 TSF:TRI:TSB
22:12:42.301 -> 55091 !TSF:SND:TNR
22:12:42.301 -> Awake Now
22:12:42.301 -> 1010
22:12:42.301 -> 3.29
22:12:42.301 -> Battery Voltage: 7.98 V
22:12:42.301 -> Battery percent: 94 %
22:12:42.301 -> sensorValue:1010
22:12:42.301 -> Going to sleep
22:12:42.301 -> 55099 MCO:SLP:MS=30000,SMS=1,I1=255,M1=255,I2=255,M2=255
22:12:42.301 -> 55109 !MCO:SLP:TNR
22:12:51.744 -> 64509 TSM:FAIL:RE-INIT
22:12:51.744 -> 64512 TSM:INIT
22:12:51.744 -> 64518 !TSM:INIT:TSP FAIL
22:12:51.744 -> 64520 TSM:FAIL:CNT=6
22:12:51.744 -> 64522 TSM:FAIL:DIS
22:12:51.744 -> 64524 TSF:TDI:TSL
22:12:52.330 -> 65112 MCO:SLP:MS=19999
22:12:52.330 -> 65114 !TSF:SND:TNR
22:12:52.829 -> 65617 TSF:TDI:TSL
@skywatch said in smart sleep inconsistent?:
#define MY_RF24_PA_LEVEL RF24_PA_HIGH
I have the node and gateway on my desk now for testing, so I am going to reflash with this now! Fingers crossed it helps.
@skywatch said in smart sleep inconsistent?:
Looking at the code, send_status_message only ever sends 1 - is this what you want? It seems to never send anything else (like 0)....
battery is only sent when there is a change in the voltage.
@skywatch said in smart sleep inconsistent?:
Looking at the code, send_status_message only ever sends 1 - is this what you want? It seems to never send anything else (like 0)....
Where do you see that? i get 1 and 0 reported as needed based on the state.
@skywatch said in smart sleep inconsistent?:
Also you are using sleep but have a receive function - what happens to messages when the node is asleep?
That is what smartsleep does. It tells my controller (homeassistant) to queue up the messages. Which works fine, as long as the node wakes up.
@skywatch said in smart sleep inconsistent?:
Have you modified the pro mini as per the battery page on this site? Have you added capacitors to the radio module?
Correct, modified for battery use, and capacitors to the radio module.
@skywatch said in smart sleep inconsistent?:
directionControl seems like it will always turn off both digital pins regardless of the message as //disable are the last statements to be actioned?
This is correct, this is a directional H-bridge controller to pulse a latching solenoid valve, so I do not need them on but very briefly.
Another quick update. I hooked my gateway up to my computer to get some debug logs off it. I am not seeing ANYTHING coming from that node using smartsleep at all. So it does appear the issue is specifically with that node.
Since it's battery powered i am going to see if i can get serial connected up without a reset and see what's it saying but i have a feeling it's going to be what ive seen before and it's having a hard time finding a parent for some reason. Not sure how to fix that.