What did you build today (Pictures) ?
-
@nagelc Its al from jung. Series AS500. Its hard for me to search for sellers in the US.. Google forces me to search in the Netherlands.
My understanding that the standard inwall boxes in North America are pretty different than in Europe /Netherlands . The types I use always look like this
But I'll share my kicad files on openhardware.io, only thing you have to do is change the backplate.
This sensor : link
Also made a repeater, but this one is fairly unsafe( I got zapped installing it 😁). I just got the PCB's for a safer version I hope I can post pictures when everything works.
-
A relatively basic board, based on a cheap CDEByte module, some leftover iTead power supplies (with not so-well aligned footprint) and a PCA9555 to drive the SSRs directly. I have suspended ceiling with many light spots so I want to be able to control them either one by one (in small rooms with less than 8 spots) or by groups/area in bigger rooms. This will be hidden in the ceiling in an electric box so I have no size constraint and it was easy to respect the creepage/clearance distance and include slots.
Resistors are the pullups for the I2C bus that I stupidely forgot :blush: (and yes I fixed that ugly solder point for the middle SSR)Result in Things Gateway:
-
A relatively basic board, based on a cheap CDEByte module, some leftover iTead power supplies (with not so-well aligned footprint) and a PCA9555 to drive the SSRs directly. I have suspended ceiling with many light spots so I want to be able to control them either one by one (in small rooms with less than 8 spots) or by groups/area in bigger rooms. This will be hidden in the ceiling in an electric box so I have no size constraint and it was easy to respect the creepage/clearance distance and include slots.
Resistors are the pullups for the I2C bus that I stupidely forgot :blush: (and yes I fixed that ugly solder point for the middle SSR)Result in Things Gateway:
-
@Nca78 Looked at another way, once installed and sealed up it will also be a sort of time capsule. :+1:
@NeverDie said in What did you build today (Pictures) ?:
@Nca78 Looked at another way, once installed and sealed up it will also be a sort of time capsule. :+1:
I said hidden and not sealed. Unless you have worked really hard on the FOTA for nrf52 ? :p
-
Not so much a build as a case study in deploying Mysensors with Domoticz to solve a puzzle simply with heating.
Having retrofitted insulation 2 years ago to my relatively modern house (2013), seeing gas consumption plummet to 55% of previously was a joy. The unknown thermostatic valves and heads were replaced with Heimeier Eclipse and Halo devices a year ago and an undersized Lounge radiator replaced (all paid for out of the first year's savings). The original intent of electronic zone control was abandoned when prices rocketed since the original goal was it being self-funded by first year savings, so a Honeywell multi$ was nowhere on the cards in any instance.
As Honeywell and other modern valve manufacturers have manufactured for thermostatic control, the Eclipse is essentially a dual flow control valve, one part replicating the return or lockshield valve (which is left fully open), the other the thermostatic control. On paper the Eclipse offered the secondary advantage of being pressure agnostic per kW panel, you set the flow and it stays that way.Delighted though I was to break 50% savings over the original thereafter with rooms remaining within a 1.1c band, there were some rooms colder than were set which made me realise there was some imbalance which I didn't realise then was the transit time from boiler to radiator (or miscalibrated valves).
First step was smart in but stupid out, monitoring the boiler by attaching DS18B20s to the connection nuts. Outgoing measured temperature being 10c below the boiler setpoint should have given a clue, but a week of running round like a lunatic with a laser thermometer and a notebook proved I was none the wiser other than the radiator was hotter than the boiler sensor.
Hence deployed this, a temporary hookup of two DS18B20s on perfboard connected with Cat 5e and phone cable and held with hot glue, two G clamps and some cardboard to ensure they stayed put, and a roving Node...
![20200119_182618[1].jpg](/assets/uploads/files/1579454832610-20200119_182618-1-resized.jpg)
Not elegant but dysfunctional (hot glue struggled under heat and pressure including having to be levered off the radiator) but it enabled the problem to be identified, transit time... Being able to monitor both the top and bottom panel temperature in relation to the main rads helped nudge the time to get incoming temp close to that taken to hit the main rads +/- 1 minute within a cycle time of 18 minutes...
Not elegant, and Domoticz is useless being built around 5 minute intervals, but it still enables readings to be taken with a notebook and pen in one hand with a glass of Rioja in the other ;) Creeping up on it.. The improvements are felt before they are observed.
My point is, a temporary Node can serve a lot of useful purposes leading up to or supplementing the permanent structure.
The screenshot is two different targets being tweaked...
-
Not so much a build as a case study in deploying Mysensors with Domoticz to solve a puzzle simply with heating.
Having retrofitted insulation 2 years ago to my relatively modern house (2013), seeing gas consumption plummet to 55% of previously was a joy. The unknown thermostatic valves and heads were replaced with Heimeier Eclipse and Halo devices a year ago and an undersized Lounge radiator replaced (all paid for out of the first year's savings). The original intent of electronic zone control was abandoned when prices rocketed since the original goal was it being self-funded by first year savings, so a Honeywell multi$ was nowhere on the cards in any instance.
As Honeywell and other modern valve manufacturers have manufactured for thermostatic control, the Eclipse is essentially a dual flow control valve, one part replicating the return or lockshield valve (which is left fully open), the other the thermostatic control. On paper the Eclipse offered the secondary advantage of being pressure agnostic per kW panel, you set the flow and it stays that way.Delighted though I was to break 50% savings over the original thereafter with rooms remaining within a 1.1c band, there were some rooms colder than were set which made me realise there was some imbalance which I didn't realise then was the transit time from boiler to radiator (or miscalibrated valves).
First step was smart in but stupid out, monitoring the boiler by attaching DS18B20s to the connection nuts. Outgoing measured temperature being 10c below the boiler setpoint should have given a clue, but a week of running round like a lunatic with a laser thermometer and a notebook proved I was none the wiser other than the radiator was hotter than the boiler sensor.
Hence deployed this, a temporary hookup of two DS18B20s on perfboard connected with Cat 5e and phone cable and held with hot glue, two G clamps and some cardboard to ensure they stayed put, and a roving Node...
Not elegant but dysfunctional (hot glue struggled under heat and pressure including having to be levered off the radiator) but it enabled the problem to be identified, transit time... Being able to monitor both the top and bottom panel temperature in relation to the main rads helped nudge the time to get incoming temp close to that taken to hit the main rads +/- 1 minute within a cycle time of 18 minutes...
Not elegant, and Domoticz is useless being built around 5 minute intervals, but it still enables readings to be taken with a notebook and pen in one hand with a glass of Rioja in the other ;) Creeping up on it.. The improvements are felt before they are observed.
My point is, a temporary Node can serve a lot of useful purposes leading up to or supplementing the permanent structure.
The screenshot is two different targets being tweaked...
@zboblamont Ah, you got bit by my main reason for not liking Domoticz: Domoticz would be so much more useful without that 5 minute minimum between recorded datapoints. It's a wonder they've never fixed that.
-
@NeverDie said in What did you build today (Pictures) ?:
@Nca78 Looked at another way, once installed and sealed up it will also be a sort of time capsule. :+1:
I said hidden and not sealed. Unless you have worked really hard on the FOTA for nrf52 ? :p
@Nca78 Just FYI, I looked into attempting a FOTA on the nRF52 but at the time I didn't feel as though I had enough easy-to-follow information to do it within the limited spare time available. I think adafruit may have some kind of FOTA for the nRF52 with their circuitPython project, but that language's runtime is awfully slow compared to C or FORTH.
-
@zboblamont Ah, you got bit by my main reason for not liking Domoticz: Domoticz would be so much more useful without that 5 minute minimum between recorded datapoints. It's a wonder they've never fixed that.
@NeverDie I don't mind it so much as an overview, it's getting sense of the overview which is the problem as the detail is absent from the graphing.
Simple enough for my purposes though, sitting in a kitchen with a glass of Rioja recording details is remarkably simpler than spilling a perfectly good wine dashing back and forth balancing a notebook, pen, laser thermometer and a clock..
We work with the tools we have, which on balance are a lot more advanced than when I was your age when flints, candles and acetylene were all the rage... -
@Nca78 Just FYI, I looked into attempting a FOTA on the nRF52 but at the time I didn't feel as though I had enough easy-to-follow information to do it within the limited spare time available. I think adafruit may have some kind of FOTA for the nRF52 with their circuitPython project, but that language's runtime is awfully slow compared to C or FORTH.
-
@monte I think it may run into the same barrier I encountered with both uPython and FORTH and uLISP. I got them all to do FOTA with nRF52, which is easier because they are interpreted, but in none of the cases could I easily leverage the wonderfully extensive arduino sensor libraries because those are written in C. Apparently there do exist ways to do it with linkers and such, but I wouldn't classify it as easily done. More like "easier said than done." uLISP would have been the easiest to adapt C-libraries, but it's a slow inefficient implementation of LISP, so that was a downside. Although practically anything can be made to work given enough time and effort, there's something to be said for staying within the Arduino framework so as to minimize time and effort.
That said, maybe your idea is different. Sometimes it's hard to really know until you explore it a bit.
-
@monte I think it may run into the same barrier I encountered with both uPython and FORTH and uLISP. I got them all to do FOTA with nRF52, which is easier because they are interpreted, but in none of the cases could I easily leverage the wonderfully extensive arduino sensor libraries because those are written in C. Apparently there do exist ways to do it with linkers and such, but I wouldn't classify it as easily done. More like "easier said than done." uLISP would have been the easiest to adapt C-libraries, but it's a slow inefficient implementation of LISP, so that was a downside. Although practically anything can be made to work given enough time and effort, there's something to be said for staying within the Arduino framework so as to minimize time and effort.
That said, maybe your idea is different. Sometimes it's hard to really know until you explore it a bit.
@NeverDie I mean, what exactly use scenario for FOTA update of a remote working node? What can you possibly want to change remotely without changing any hardware? I guess it can be some logic, or parameters that may require adjustment that can be made remotely, and that's how I think JSON can be used to specify those. I well may be overlooking the big part of a problem, so I ask to better understand it.
-
@NeverDie I mean, what exactly use scenario for FOTA update of a remote working node? What can you possibly want to change remotely without changing any hardware? I guess it can be some logic, or parameters that may require adjustment that can be made remotely, and that's how I think JSON can be used to specify those. I well may be overlooking the big part of a problem, so I ask to better understand it.
@monte said in What did you build today (Pictures) ?:
@NeverDie I mean, what exactly use scenario for FOTA update of a remote working node? What can you possibly want to change remotely without changing any hardware?
for example arduino core used for the firmware (sdk..), libraries updates (MySensors, sensors), etc
-
@monte said in What did you build today (Pictures) ?:
@NeverDie I mean, what exactly use scenario for FOTA update of a remote working node? What can you possibly want to change remotely without changing any hardware?
for example arduino core used for the firmware (sdk..), libraries updates (MySensors, sensors), etc
-
@scalz but why do you need this on an already working node? Mysensors has backward compatibility so far. Do you expect any improvements from updated sensor libraries for a working node? In this case, you of course would need proper FOTA.
@monte said in What did you build today (Pictures) ?:
@scalz but why do you need this on an already working node? Mysensors has backward compatibility so far. Do you expect any improvements from updated sensor libraries for a working node? In this case, you of course would need proper FOTA.
I don't think that a major fw release (MySensors in this case) always guarantees full backward compatibility.
Perhaps not for a sensor lib (but who knows), still, if not for any core updates, do you expect any improvements from updated MySensors lib for a working node/network? If no, then you don't need fota ;)
app settings != app/fw update[edit]
Examples when you may need to flash your fw (wirelessly or with a programming tool):- it was not possible to have backward compatibility between old and new rfm69 drivers (new driver brought lot of improvements for green rf like adaptive TX power, power consumption etc).
So it required updating network (gw and all nodes). This can happen eventually for a major release (v2->v3 or v3->v4..), a major release could allow "controlled" breaking change if no other way. - bugs fixes in MySensors files (core, transport, security..)
- new features updates if needed (in MySensors, or your own sketch), easy to imagine, so many things to improve
- etc
- it was not possible to have backward compatibility between old and new rfm69 drivers (new driver brought lot of improvements for green rf like adaptive TX power, power consumption etc).
-
@monte said in What did you build today (Pictures) ?:
@scalz but why do you need this on an already working node? Mysensors has backward compatibility so far. Do you expect any improvements from updated sensor libraries for a working node? In this case, you of course would need proper FOTA.
I don't think that a major fw release (MySensors in this case) always guarantees full backward compatibility.
Perhaps not for a sensor lib (but who knows), still, if not for any core updates, do you expect any improvements from updated MySensors lib for a working node/network? If no, then you don't need fota ;)
app settings != app/fw update[edit]
Examples when you may need to flash your fw (wirelessly or with a programming tool):- it was not possible to have backward compatibility between old and new rfm69 drivers (new driver brought lot of improvements for green rf like adaptive TX power, power consumption etc).
So it required updating network (gw and all nodes). This can happen eventually for a major release (v2->v3 or v3->v4..), a major release could allow "controlled" breaking change if no other way. - bugs fixes in MySensors files (core, transport, security..)
- new features updates if needed (in MySensors, or your own sketch), easy to imagine, so many things to improve
- etc
@scalz as time goes I'm becoming more "Ain't broke, don't fix it" guy. Let's say, you've installed relay node somewhere outdoors, that has been working for a couple years. What exactly would you want to improve by reflashing it with updated library? Or maybe not a relay, but any other node, you have in mind, that could benefit from this action.
Once again, I don't want to argue, just clearing things out for myself.
Thanks :) - it was not possible to have backward compatibility between old and new rfm69 drivers (new driver brought lot of improvements for green rf like adaptive TX power, power consumption etc).
-
@monte I get it. I think this is off topic here, maybe open a new thread if you need to ask people why/when they need to update their systems, reflash their devices etc
( I have edited my previous reply with a few more examples in case it would be more clear) -
@monte I get it. I think this is off topic here, maybe open a new thread if you need to ask people why/when they need to update their systems, reflash their devices etc
( I have edited my previous reply with a few more examples in case it would be more clear)@scalz I agree that this conversation is off topic, and I indeed started a separate thread before I posted replies here. Fell free to express your thoughts here, if you want: https://forum.mysensors.org/topic/10895/modular-sketch-to-be-configured-with-json-idea/
-
@NeverDie said in What did you build today (Pictures) ?:
@Nca78 Looked at another way, once installed and sealed up it will also be a sort of time capsule. :+1:
I said hidden and not sealed. Unless you have worked really hard on the FOTA for nrf52 ? :p
-
@xmonika Nice work! I really like how you very artfully leveraged pre-made boards into such a compact assemblage. Is the backplane something that you self etched or CNC'd?
@NeverDie a big thank you as I was inspired by many of your post and this was my first Nrf5 project. The backplate is designed in KiCAD and then outsourced for etching to one local semi-hobby service. Modules are then connected via precision header pins (concept inspired by Ardumower)
image url)