Time awareness and scheduling events
-
I've ordered a couple of RTC modules that could be a optional accessory for a node. Distributing server time is still needed.
@hek I ordered a few of these -> http://www.ebay.com/itm/191276972230 hoping they can serve the same purpose.
-
The only disadvantage I see with these modules is that their libraries eat a lot of memory.
I wanted to use them in combination with an lcd but at this point it is either one or the other but not both...
I hope that flash memory will bring some relief...
-
As started here.
Looking at the TimeAwareSensor example essentially everything is there for time synchronization. Once the callback is set with the initial call to requestTime, any subsequent time packets received from the gateway would be used to update/adjust the internal time accordingly.
The only adjustments needed to get to a real time synchronization would be to let the gateway (or rather the controller) broadcast the time every x minutes and ensure that the sensor listens to the time packets even if they are not addressed to the nodeID but broadcasted (today only TIME packets addressed to the specific node are handled).I've done these changes here and will do some testing.
To schedule events the question is how to store the schedule with a minimum footprint in EEPROM. Keeping hour:minute should be sufficient. Storing these in a byte each is a waste of space (only 5 bits for 0-23h and 6 bits for 0-59m needed or 11 bits for 0-1439m). Looking at usual scenarios you need a bitmap for the weekdays (schedule for Mo/We/Fr only) which takes another 7 bit. With that three bytes are minimum and leave 6 bist for additional purposes.
For home automation you would usually want to have a way to tell if the event should be executed on a public holiday (1 bit) and you want to have a way to tell if it should be executed when you are on vacation (1 bit) - I'll explain in a later post how public holiday and vacation could be determined.Each event should probably include some kind of payload (what to do). To keep this simple I'd propose a single byte payload and let the callback function in the main sketch decide what to do with it.
This is a request for ideas before I start coding any of this!!!
-
@ToSa maybe I'm missing something but if I understand you right you require scheduling at the sensor, right?
@Yveaux Right - I mentioned the garden watering in another post - I want the sensor to be aware of the schedule to reduce the single points of failure to a minimum - and avoid bad surprises getting back home after vacation :) That means the sensor is able to execute even if the controller is broken or the gateway is broken or the network connectivity is broken due to a relaying node in the middle etc.
-
The trend in HA now moves towards pushing some of the "intelligence" to the nodes. This creates autonomous units that can actually work for a while without contacting and relying on the "mothership".
@hek I also want to be able to switch on my lights when my gateway is down, but when we want to move intelligence to the nodes (eg make them programmable using rules as seen in another discussion) we have to think upfront what the implications are and how to implement this. I should not rush some kind of schedule rules now, without thinking over the whole concept first.
http://yveaux.blogspot.nl
-
@hek I also want to be able to switch on my lights when my gateway is down, but when we want to move intelligence to the nodes (eg make them programmable using rules as seen in another discussion) we have to think upfront what the implications are and how to implement this. I should not rush some kind of schedule rules now, without thinking over the whole concept first.
-
@hek I also want to be able to switch on my lights when my gateway is down, but when we want to move intelligence to the nodes (eg make them programmable using rules as seen in another discussion) we have to think upfront what the implications are and how to implement this. I should not rush some kind of schedule rules now, without thinking over the whole concept first.
This is a request for ideas before I start coding any of this!!!
:)
time awareness was straight forward based on existing functionality (even if I would still argue that it should be an integral part of the sensor code and not require separate code in the custom sketch).The rules engine requires much more prep work and smart ideas.In an earlier project I ended up with the following (not saying that this is the best approach - just to start the discussion):
- simple memory manager assigning memory addresses so that you can remotely request or set a variable in memory the same way you do today with sensors (think about a memory address having its own sensor-id on the node)
- rules to set variables on the same node or on remote nodes (or on the gateway/controller)
- rules triggered by schedule or triggered by events (button clicked / temperature changed / ...)
- no need to trigger rules remotely - you can get that by setting a variable remotely and have a rule listening on changes to that variable (node A with the light switch telling node B with the relay to turn on the light)
- gateway is always made aware of what's going on but usually not required for the execution
The problem is that the "setup" of the network and the specific nodes gets way more complex - easy to do for software developers but hard to do for a "normal" user.
-
@hek any plans to setup a "dev_1.5" branch or something similar? If we continue adding major functionality changes to 1.4 it will never get "ready" :)
-
@hek I ordered a few of these -> http://www.ebay.com/itm/191276972230 hoping they can serve the same purpose.
@korttoma said:
@hek I ordered a few of these -> http://www.ebay.com/itm/191276972230 hoping they can serve the same purpose.
I have now been playing with one of these for a few hour and I really like it. Running an LCD and TinyRTC on the same I2C bus and it is working fine.
Need some more time on the sketch before I mount everything in a box. The goal is a scene controller
/ clock / info display by the bed.
I was thinking of adding the knock sensor as a "clapper" device but I don't think I can pull of the code so that it would keep updating the clock as often as I would like.- Tomas
-
@korttoma said:
@hek I ordered a few of these -> http://www.ebay.com/itm/191276972230 hoping they can serve the same purpose.
I have now been playing with one of these for a few hour and I really like it. Running an LCD and TinyRTC on the same I2C bus and it is working fine.
Need some more time on the sketch before I mount everything in a box. The goal is a scene controller
/ clock / info display by the bed.
I was thinking of adding the knock sensor as a "clapper" device but I don't think I can pull of the code so that it would keep updating the clock as often as I would like. -
Probably not something you need guys, but something i did the other day - a sketch to request the time from Vera and set an RTC.
My requirement is to keep the RTC synced when daylight saving changes, so sync would be at 2:01 Sundays.
-
Probably not something you need guys, but something i did the other day - a sketch to request the time from Vera and set an RTC.
My requirement is to keep the RTC synced when daylight saving changes, so sync would be at 2:01 Sundays.
-
No prob... you can remove the bugs ive added ;-)
-
I would suggest to sync times a little bit more because if i remember correct the 1307 is quite sensitive for drifting because of temperature, if it would drift 3 seconds a day would be around 16 minutes a year, the DS3231 compansates this with the build in temp sensor.
But i could be incorrect, but, update your rtc more often anyway ;)
-
Just tried the DS3232RTC library from the examples provided by @hek and it seems like the RTC I2C DS1307 AT24C32 (link to device in earlier post) I have is working happily with this library also. I guess all the features of the library does not work but since the features on my device are working I will stick with this lib since it is provided by MySensors.
Maybe you should try it out to @gregl
BTW!, the RTC I have seems to drift quite allot (~1s/h) so I would not recommend it to someone that needs accuracy.
