I am non technical but I have 8 wirsbo stats in my house. One of them is faulty and the unit is now obsolete. Is it possible to purchase one of these pcbs and use it to replace the one in the faulty stat ?
Thanks
Richard
Hi @berkseo. Thanks for the suggestion, but could you describe in more detail? As for my TODO list, there is already a task to add 485 interface to the gateway. My latest device "xRoom" have this interface.
ps/ Where have you gone?
I have been working on "xRoom" shield. A small announce:
Do you remember the discussion about multinode? So, it will be available soon))
Does this help:
http://forum.mysensors.org/topic/748/manual-assigning-node-id-s-for-network-with-repeaters
I agree with you that the serial messages are not perfectly documented, but realise that this site has been made (as far as I know) by a bunch of people that share their 'love' for home automation.....
boozz
If you are not going to use mysensors look at library example
https://github.com/mcleng/MAX6675-Library/blob/master/examples/read_temp/read_temp.pde
Error:
MAX6875Temp.ino: In function 'void loop()':
MAX6875Temp:24: error: 'class MAX6675' has no member named 'read_temp'
temperature = temp.read_temp();
@NeverDie Thx for appreciating the work done. There will also be an open source part in the future. When and how extensive the open source part will be, remains to be seen. The release of certain information (block diagram, ..., in this post) is related to those open source parts.
There are some OBD solutions, however most of them (in my experience) give back low frequency data put by the car manufacturer on the OBD-bus (CAN, ...). Therefore transients evolving directly from the battery could only be recorded if the manufacturer sends those data accordingly on the bus. Due to the small bandwidth(also because of other car data that have to be sent, ...), such battery data are sent more often once per second or less. Fast battery events (i.e. cranking events, ...) are therefore imperceptible. Unless the manufacturer processes the fast events and then sends them (once per second or less), which is very unlikely if the manufacturer does not market this feature itself. Third parties devices for high frequency sensing costs several hundreds dollars.
In my experience, important battery states (especially the fast ones) are recorded by measuring and processing corresponding data directly on the battery.
I agree with you about the limits related to the communication over Bluetooth. But i think Bluetooth 5.0 will improve a lot. However, WiFi will always remain an important option due to the high data throughput. The combination of both (BLE & WiFi), especially with regard to energy consumption, will gain in importance.
Well I changed the connection type for the sensors due to the above issue.
Tested and again after 2.5 days, it locked out on a sensor com error. So after some thought, I realized, (not sure why I didn't before) the system is not going to be 100% bullet proof, so instead of moving to a hard fault, I recoded the error handling section of the sketch to attempt to handle the occasional hiccups in reading the sensors. Pushed new sketch to Github and am testing now.
It will interesting to see just how many times the readings fail.
I shall see.....
