Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 28

Thread: Hi! DIY Home automation system build.

  1. #11
    Automated Home Jr Member
    Join Date
    Jul 2019
    Posts
    26

    Default

    Quote Originally Posted by DerekWilliamsUK View Post
    Please keep your progress/updates coming. This makes great reading. Thanks.
    Thank you. I was hoping it was of interest to at least some one. However it also helps me solidify my thoughts.

    So this morning I noticed the Raspberry PI in the garage was sick It only send data updates for garage, outdoor temp, humidity and air pressure about 4 times through the day from 11am. Inspecting it revealed the spiders seem to enjoy it. I cleaned off the cob webs and power cycled it, but as I didn't have time this morning to test/check it I had to disable the heating by switching it off at the normal 7 day timer. I was worried if the PI has issues after boot up it could potentially send a zero or negative temperature and trigger the heating on all day.

    This coupled with the total loss of an SD card in a Raspberry PI last year leads me to sigh and accept the fact that RPis are not reliable devices. I know they have their fan boys and they are great little devices for various purposes, but having a full OS running churning the SD card and whatnot makes them prone to failures when a much simpler solid state MCU device like an ESP8266 can manage a collection of sensors more reliably. I'm even thinking of moving the "hub" and service components to the main PC based server as I fear another memory card failure is highly likely. I'm not sure how much longer than a year they will last running a noisy syslog 24/7 etc.

  2. #12
    Automated Home Jr Member
    Join Date
    Jun 2018
    Posts
    13

    Default

    Paul
    I have used Raspberry Pi's and they are reliable if you use a RPI3 with USB memory instead of SD card.

    Michael

  3. #13
    Automated Home Jr Member
    Join Date
    Jul 2019
    Posts
    26

    Default

    Quote Originally Posted by GreenGuy View Post
    Paul
    I have used Raspberry Pi's and they are reliable if you use a RPI3 with USB memory instead of SD card.
    Maybe. I just don't think flash memory is great for a full OS as it normally entails a lot of "thrash" and "churn", writing and rewriting constantly. Things may have improved but I vaguely recall the memory sectors only have something like a 1000 overwrite limit before they get marked as expired. Then again modern SSD hard-disks I believe are up to 10,000 writes per sector.

    Anyway, the PI is great, but for the sensor senders I still think a lighter platform like the ESPs are better and use less power.

    Having a full OS is a maintenance burden anyway. Power cuts and accidental power offs, while you often get away with them, they have corrupted hard disks on me many times. With a Microcontroller this doesn't happen due to their architecture and the "program" memory not being writable (with caveats such as the serial bootloader and OTA programming).

    If I come to UIs with colour LCD screens that an ESP can't handle the PI sounds perfect though.

    On the spiders issue I need to put things into cases and smear the inside with some nicotine concentrate (from vaping liquid) that will keep em out. Either that or commercial "spider away" stuff.

    BTW, the PI was fine after power cycling. I suspect the air pressure/humidity sensor being covered in spider web may have upset things. Often the calls out to hardware like that can cause major issues if the hardware is dead, shorted, disconnected etc. Which might have been the case here. Not sure how conductive spider silk is.
    Last edited by paulca; 29th August 2019 at 04:43 PM.

  4. #14
    Automated Home Jr Member
    Join Date
    Jul 2019
    Posts
    26

    Default

    Two options which are viable for the PI to avoid the SD card are:

    1. Move high activity folders to a RAM disk to keep the SD card writes low. Things such as /var and /dev etc. Although you lose your logs and any state on reboot.
    2. Move most of the OS to a network drive.

  5. #15
    Automated Home Jr Member
    Join Date
    Jul 2019
    Posts
    26

    Default

    As a random aside I had an epiphany about "RF". I hate it because it's old-tech, because it's horrible to work with as a casual hobbyiest/maker. Electronics with RF involve horrid mathematics.

    For momentary switches though....

    The thing is, with a micro-controller it has to run constantly waiting on you pressing the button, it has to remain on-enough to stay connected to the Wifi (an on going problem with low energy devices). It constantly consumes 10-50mA. With an RF device, you can literally have it only be "ON" when the switch/button is pressed. The switch just powers an RF transmitter that sends a signal repeatedly while the button is pressed. The rest of the time it's completely off, drawing zero power from the battery. Pressing the button for 1/10th a second would be enough to power up the transmitter and send the signal 100 times.

    Potentially a small 500mAh LIon could last for years.

    So I might consider RF transmitter switches, the theory being you could just 3D print or buy a switch, glue it to the wall and have it work for a few years between battery changes/charges. Stick a USB micro socket at the bottom and provide way to charge it in service.

    Need to research "maker" level RF modules.

    Need 3D printer!


  6. #16
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,577

    Default

    Interesting that you consider RF to be “old tech”.

    What's the more modern replacement then?

  7. #17
    Automated Home Jr Member
    Join Date
    Jul 2019
    Posts
    26

    Default

    Quote Originally Posted by paulockenden View Post
    Interesting that you consider RF to be “old tech”.

    What's the more modern replacement then?
    Wifi, bluethooth, ethernet. But you could argue the first two are RF. So maybe I should have been clearer and specified 433MHz non-digital RF. Like key fobs.

    Still the same old mine field with switches though. Of course they are all designed to work with their own product range and they don't publish the protocol etc. So I will need to research and find some devices people have successfully paired receivers to.

  8. #18
    Automated Home Jr Member
    Join Date
    Jul 2019
    Posts
    26

    Default

    So just a little update on stuff I did over the weekend.

    This started out as just pure geeky fun but I put temp probes on the heating in and out pipes. Producing this graph:



    The first 4 runs of the heating where normal, either scheduled like this mornings runs or playing around like saturday night, but on the 5th (notably lower) I tested what happens if I point a temperature schedule at the heating itself. In this case I set a 40*C minimum on the heating pipes and sure enough it regulated the heating temperature at 40*C. I'm wondering if I should couple this into the normal schedules or move it's functionality to the heating controller. Yes, I know I can sort of do this with the boiler themostat, but I found it less than accurate and only goes down to 60*C.

    I also graphed the presence and heat status flags, here's the heating one, bonus points if you spot the bug.


    ... and for reference the temperatures:


    Due to the distributed, modular and fairly stateless nature of the design it allows a lot of flexibility. For example I was running the new heating loop schedule on a completely different PC, my main office dev PC at the same time as the existing scheduler was running on the Raspberry PI and they shouldn't trample on each other, well unless you deliberately try and put them into competition with each other.

    I also thought I would share some of the high level code with you. This is what I use to actually set the system up, sparing you the detailed code of "how" it works, for that scroll up and find the GitLab link I shared.

    Defining "the weekend" as a set of time conditions:
    Code:
        all_day_start = datetime.time(hour=6, minute=30, second=0)
        all_day_end = datetime.time(hour=23, minute=00, second=0)
        all_day = TimeCondition(all_day_start, all_day_end)
        weekend = DayOfWeekCondition([6, 7])
        weekend_routine_conditions = [("AND", all_day), ("AND",weekend)]
    The "week day" routine schedules are slightly more complex with morning and evening portions:
    Code:
        weekday = DayOfWeekCondition([1,2,3,4,5])
    
        morning_start = datetime.time(hour=6, minute=30, second=0)
        morning_end = datetime.time(hour=8, minute=00, second=0)
        morning = TimeCondition(morning_start,morning_end)
        weekday_morning_routine_conditions = [("AND", weekday), ("AND", morning)]
    
        evening_start = datetime.time(hour=17, minute=00, second=0)
        evening_end = datetime.time(hour=23, minute=00, second=0)
        evening = TimeCondition(evening_start, evening_end)
    
        weekday_evening_routine_conditions = [("AND", weekday), ("AND", evening)]
    Define the target temps. This blob of data, which is hardcoded, is on the list for wrapping in a network service (Probably within the TemperatureManager) to permit updating it from HID/UI devices like my phone or a wall panel touch screen.

    Code:
        target_temps = {
            "default": {"livingRoom":6, "bedroom":6, "garage":1, "office":6},
            "eco": {"livingRoom": 18, "bedroom": 16, "garage": 2, "office": 18},
            "preferred": {"livingRoom": 20, "bedroom": 18, "garage": 2, "office": 20},
            "max": {"livingRoom": 30, "bedroom": 30, "garage": 30, "office": 30}
        }
        temp_manager = TemperatureManager(target_temps)
    With those definitions and condition sets out of the way I can create schedules. My current go-to schedule is the MultiRoomTempSchedule. You give it a reference to the temp manager and which target to aim for and it will raise a heating demand for which ever target temp is not being hit currently, even if that's multiple rooms at once.

    The 24/7 365 minimum or maintence schedule is simple, it has no time conditions and targets "default":
    Code:
        maintenance_schedule = MultiRoomTempSchedule([], "Maintenance Schedule", temp_manager, "default")
    The "routine" schedules are again multi-room temp schedules targeting "eco" temps.
    Code:
        weekend_routine_schedule = MultiRoomTempSchedule( weekend_routine_conditions, "Weekend Routine", temp_manager, "eco" )
    
        weekday_morning_routine_schedule = MultiRoomTempSchedule( weekday_morning_routine_conditions,
                                                                  "Weekday Morning Routine", temp_manager, "eco" )
    
        weekday_evening_routine_schedule = MultiRoomTempSchedule(weekday_evening_routine_conditions,
                                                                 "Weekday Evening Routine", temp_manager, "eco")
    Finally the real smart bit is the presence schedule, which turns out is just a MultiRoomTempSchedule() at heart at present. I created the new sub class anyway as I hope to extend this to be multi-room presence away, so it can target "eco" in rooms I'm not in and "preferred" in rooms I am in.

    Code:
        presence_condition = PresenceCondition("presenceHome")
    
        presence_schedule = PresenceTempSchedule([("AND",all_day),("AND", presence_condition )], 
                                                                          "Presence Schedule", temp_manager, "preferred")
    "presenceHome" by the way is the data which is published stating if I am in the house or not, based on the phone's Wifi MAC being online.

    Finally, I create a list of these schedules and pass them all to a scheduler:
    Code:
        scheduler = Scheduler([weekend_routine_schedule,
                               weekday_morning_routine_schedule,
                               weekday_evening_routine_schedule,
                               presence_schedule,
                               maintenance_schedule])
    The main heartbeat of the scheduler is just this time loop:
    Code:
        while True:
            scheduler.update()
            time.sleep(30)
    I can see I have my work cut out for me to provide interfaces to these things. It would not be too hard to run something like REST in the same process scope as the scheduler and modify the various parameters like the target_temps or the times on the routine schedules, the difficult bit is that they then need to be persisted so if the thing power cycles it doesn't just go back to the coded defaults.

    On "power cycling" the system is fully resilient, or maybe it's more that it doesn't care. You can just shutdown, stat up or restart any component and while you obviously lose that functionality while it's down, nothing really gets upset.

    If for example I shut the scheduler off while the heating is on. The heating demand will expire after 5 minutes and the heating will shut off.

    If you shut the heating_hub component off, all the current working data of temps, presence, demands will disappear, but the rest of the system will just shrug and carry on working. The temp sender probes send their data by UDP so they don't even care that anything received the data as they can't do anything about it anyway.

    If I accidentally knock a temp probe plug out of the wall or one of them malfunctions, the temp conditions are smart enough to detect and ignore stale data. Data that is more than 5 minutes old is ignored. So it won't start firing the heating on all day because the living room temp probe died after sending a temp of 18.6*C and never sent another.

    EDIT: What I probably do need is "out of range" detection or "out of normal" detection. For example if a probe fails and starts sending -127*C it should be smart enough to ignore that. Using a "maximum differential" between two indoor temps would help detect "out of normal" readings, but would go in the right direction towards "open window detection".

    Asides "open window detection" the other feature I would like is prediction for what I call "pre-ramp" and "overshoot" on the heating targets. At the moment my 6:30 in the morning is set that way to give the heating time to warm up before I get up at 7am. It would be nice if the scheduler figured that out on it's own. I have ideas about how to do this by running schedules multiple times giving it dates further in the future to find out if any schedules "will" come active soon. If a schedule will be active in 1 hour and the current temp is low by 1 degree I might not preempt it, but if the current temp is 5 degrees below target I might preempt it.
    Last edited by paulca; 1st September 2019 at 05:45 PM.

  9. #19
    Automated Home Jr Member
    Join Date
    Jul 2019
    Posts
    26

    Default

    So the issue I'm facing currently is less to do with the control system and more about my house. I only bought it in July.

    The living room seems to be the coldest room in the house. It's also got a very weak radiator. I have just accepted a quote to upgrade my heating from oil fired to gas which will include replacing a few dodgy radiators, including the living room. The downstairs of the house is also fairly open, the kitchen has no doors, so openly joins into the hall and the dinning room and while the living room has doors, they are usually left open.

    However at the moment what happens is the living room drops below 20*C and the heating comes on. The radiators in the kitchen, dinning room and hallway support it's weak radiator and heat it up, the heating goes off, but the living room cools again fairly rapidly. Of course all that heat just moves upstairs making the upstairs too warm even though the upstairs (except bathroom) rads are off. I'm fairly sure this just pulls cold air up through the floor from the dead space into the living room.

    In short it is costing me too much heating just to keep the living room warm, even when I'm not in it.

    Today for example I will be working from home, so I will be in the office upstairs. When I worked from home on Monday the heating was on about 40% of the time just to keep the living room warm.

    Without individual room presence detection (yet) I have decided to manually intervene and lower the target temperature for the living room to 19*C, maybe even 18*C. I will then need to manually intervene again to lift it to 20*C when I finish work and want to watch TV on the sofa. However it should save on oil.

    This is all, I hope temporary. When the new radiator in there I can close it's doors to keep it's heat in which should address the issue. However it does raise a type of requirement for "profiles" again. A working from home (or "in the office") profile in place of multi-room present awareness, which is still only a pondering with bluetooth radars in the temperature probes at the minute. Simply selecting a profile with an expiry would allow temporary altering of target temperatures and stop me having to heat the whole house to satisfy rooms I'm not in.

    I also plan to survive one winter here and then fork out for proper loft and wall insulation. I was well aware of the houses energy rating being dire at an F- with no cavity wall insulation and 1970s roof insulation. It will be interesting to see how I do with it over winter and what difference adding proper insulation makes for the next winter. Part of me is not looking forward to this winter though. I can see me huddling in one room with the doors shut trying to keep one space warm rather than run the heating constantly in Jan/Feb.
    Last edited by paulca; 4th September 2019 at 07:52 AM.

  10. #20
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,804

    Default

    Quote Originally Posted by paulca View Post
    Wifi, bluethooth, ethernet. But you could argue the first two are RF. So maybe I should have been clearer and specified 433MHz non-digital RF. Like key fobs.
    433Mhz key fobs (if you mean car key fobs) are all digital. As are most other things that use 433Mhz like weather stations.

    It's been a very long time since any sort of remote control was analogue...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •