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.
What could this be used for? You have to be with in range of your RF network right?
I have put my mods on github.
https://github.com/brunkj/MySensorsMiLight/
I have not been able to mess with it since the weekend. Still trying to get some info on the RGB part. If anyone wants to take a shot at it let me know if you make any progress
so my 1 message a second is literally like nothing as far as the mysensors RF protocol is concerned. Shouldn't impact at all?
So right now I have my mysensors gateway(s) setup on 2 raspberry pi's. They are both setup for mqtt gateway which is on a diff server.
I use keepalived to determine which pi should be running the mysgw binary.
This works pretty well. However I am considering changing over to 2 network gateway configurations and use a floating virtual IP.
Does anyone have any pro's/cons for one method over the other?
The pro that I can see is being able to use other programs that can communicate over the network gateways to do OTA updates. As well as being able to use bindings for things like discovery.
@martinhjelmare being a fan of quads.... i like this idea haha
any updates? I have a couple milight bulbs ready to test
Small update. I switched to a radio from different batch and seemed like that fixed it. Saw the smart sleep message in mqtt until I went to bed. But around 4:30am it stopped again. Im going to go pull it again and see what it's outputting. I feel like I need to hook up a bluetooth hc-05 or something so i can just connect over bluetooth at this point to get the serial data lol
@mfalkvidd I will put up a write up on what i did. Including my health check script (which may address some of the other items on how I handle the failures ect)
Keepalived with the check script and health script is what I use to keep tabs and it also moves that virtual IP back and forth allowing for the same ip to stay in use and restart the binary when needed
updated to 1.6.9 and it's there. oh well. probably needed to update anyway
I look forward to seeing this project progress. Go get it!!
I guess you could do it with a dummy color item. Not associate it with a specific. Then have a rule that when the dummy item is updated, then loop through the items in the group, or just send it to the X number you have.
@gohan LOVE THIS IDEA!!! We should have a line of them.
WAF Rating: 1-5
1 = super fun for us
5 = wife doesn't kick us out
I have a the fantastic newbie pcb board from @sundberg84 and I am making a small pool temp sensor with it.
I am running in to some issues though and wondering if anyone has some ideas. So a fully charged 18650 can get up to 4.2v so I need to regulate it. I was looking to put the battery in through the RAW pin that way the VCC would be 3.3v. However, that is only good until the battery drops below 3.3. The 18650's I am using can go to 3.0 pretty easily, datasheet even says 2.8. 3 is kind of where I would like to limit it though. So I have a little 3.3v boost converter. But when it's over 3.3v not sure if it's going to damage the boost converter (guessing yes).
So i am curious if it's possible to be able to use the newbie board, have the battery voltage monitored. Handle a fully charged 18650 and be able to use the boost converter if the battery drops below 3.3v.
Thanks!
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!
@xefil with my errors. I changed the capacitor value to 100u and that fixed ALOT of problems. Some one mentioned to me that 2.0 uses the radio a little more and may need a higher value cap.
The space heater was pretty close in proximity and never noticed it cause... well i live in florida, i only use it like 3 times a year lol.
But, i also know this house (built in the 70s), had someone do the electrical that i have to question many a decision. Some outlets not grounded. There is an outlet in my kitchen that only turns on when the switch for the garbage disposal is running.... i haven't found exactly what device would only be needed when the disposal is running... but it's a mission i am on...
So i think throwing some caps on the input side of things is still worth a shot.
This should be pretty easy. Install your Home Assistant, then follow the pi gateway instructions. Shouldn't have any issues with it conflicting.
Here I am again. I swear this forum is beginning to feel like home lol
So I made a little battery powered temp sensor for my pool. Works great (see graph) hehe
so here is what I have run in to. The node is battery powered. It goes to sleep for 90 minutes at a time, wakes up, checks temp/battery sends changes and goes back to sleep.
So yesterday, first time in like 2 weeks the node reported just before noon and then it didn't respond at all the rest of the day. I got home last last night. Reset it and it was good.
So is there a correct way to do watchdog on a battery node? Any suggestions?
Thanks!
I found that thread late last night. I read through the WHOLE thing before going to bed. I have my evening plans set for tonight. I don't have any sensors really in use now, it's just more for testing. So I am all over this!!
@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
Was wondering if it's possible to have multiple mqtt client gateways. I have 1 configured now that points to my mqtt cluster. Was wondering if it's possible to setup a second one. Have it be part of the "self healing" network. Since both gateways would push to via mqtt to the mqtt server so there wouldn't be anything binding a sensor to the gateway.
thanks!
Alright... you got me... im interested. Have some questions lol.
Not sure if you have looked into the rhasspy project for your smart speakers. I am currently working on that myself. I have my first one built and testing satellites with a main "brain" running on a beefier piece of equipment.
that's where the problem is. the whole sensor is a pro mini. it periodically stops doing it's thing.
I am moving forward with some of my builds. I love the mqtt client gateway. This works great with my existing mqtt setup. There are 2 things I am unsure of.
Thanks guys!
github would be awesome!!
I commented in the other thread too
This is a cool idea. Definitely worth throwing some bigger batteries at it for debugging. I am looking for this bridge stuff now
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?
I am considering making this for that exact purpose.
https://www.openhardware.io/view/532/The-Logger-Machine-Short-and-long-term-serial-logging
Otherwise maybe just hook a laptop up with a putty session configured to just output the entire session to text file.
I swear I did a search. But apparently I searched on one of my other community forums that had nothing to do with arduino or mysensors 
helps when i search the right forum.
Sorry, I spaced on that. It's not sending messages any more. like the process is hung up.
This is version 2.3.1 mqtt pi gateway.
if you want to play with some ws2812 stuff. i HIGHLY recommend looking at the wled project from aircookie. uses a wemos d1 mini. flash the firmware and off you go. integrates into EVERYTHING. tons of built in lighting effects and some crazy extras like supporting e1.31 protocol so you can add your led strips to christmas light shows using stuff like xlights, vixen2 and falcon pi player.
I haven't really tested pico but I would guess there is a way to use it as a drop in just like i have with my current marytts.
As far as the kubernetes, the reason I use that is 2 main reasons.
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
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
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.
