MikeSharp01 Posted January 27 Share Posted January 27 3 hours ago, joth said: Like, predicting someone is about to run a bath and two showers and empty the UVC at an unusual time of day - it's actually a tough problem Perhaps all you need is enough data from the variety of sources and maybe some sort AI could do it although the variety of sources might need to be quite diverse. IE what history and confluence of circumstances last caused the UVC to empty? 1 Link to comment Share on other sites More sharing options...
MikeSharp01 Posted January 27 Share Posted January 27 PS you might be able spot the UVC running down fast and get behind it with both immersion heaters and bring the ASHP up to support the heaters when it's warmed up. In our place I think I only need a 5kW ASHP so two immersion would better it. Link to comment Share on other sites More sharing options...
TerryE Posted January 27 Author Share Posted January 27 (edited) I think that it is quite different in scale of impact. In the peak winter months you might need say 40 kWh of heat input into the house at a CoP of somewhere between 3 and 5 so ~10 kWh electricity. The Octopus Agile tariff price today varies from 7.5p to 33p / kWh. That's an over 4× range. You know this 24 hrs in advance and want to be able to schedule the ASHP input across the day to make good use of this, but if you can -- as I can with my current Willis implementation then I see significant cost savings. I currently only have 1 working SunAmp and I just top this up to full at the cheapest rate I can buy. If I think that I am going to run out, I just click a button on my phone and dump another 3 kWh into the SunAmp. OK this might be at a bad time and cost me 50p or so than doing it at the cheapest rate, but who cares? Jan or I only do this maybe half a dozen times a year. Edited January 27 by TerryE 1 Link to comment Share on other sites More sharing options...
Mike Posted January 27 Share Posted January 27 (edited) 4 hours ago, TerryE said: the Shelly Pro 4PM is a really interesting product but I have real concerns about it's closed-source firmware. That's why I currently prefer the Sonoff equivalent which another ESP32-based device but is Tasmota firmware compatible. The Shelly Pro is also ESP32-based and, as recently reported here, can be flashed with Tasmota too. As per that thread, for the screen a separate UI required, and someone's built a basic one here. Edited January 27 by Mike Link to comment Share on other sites More sharing options...
TerryE Posted January 27 Author Share Posted January 27 @Mike, thanks I was already aware of this and am monitoring it with interest. I think that Sonoff and Shelley have a somewhat different attitude to OS projects like Tasmota, ESPHome and ESPEasy. Sonoff are fairly open and publish circuits etc., and even application notes such as this on using OS firmware on their products, seeing this as an opportunity to extend their target audience. Shelley are a little more hostile and don't share info and state that using non-Shelley firmware will void their warranty. 1 Link to comment Share on other sites More sharing options...
TerryE Posted January 29 Author Share Posted January 29 (edited) @Mike, a Q for you: have you looked at Shelley script yet? As far as I read it the ESP32-based devices such as the 4PRO PM run a firmware build that include a cut-down JS runtime that allows you to do on-device JS scripting (Tutorial) a bit like the ESP32 Lua system that I used to help develop. The main advantage of this as far as I am concerned is that you can add a level of basic on-device safety rules such use "relay X will auto-open X minutes after the last close command". As you say, the form-factor is great and Shelley is manufactured by a Slovenian company so it's CE certification will be solid. These advantages probably outway the lack of OS firmware. My head hurts. 😨 PS. The 4PRO is an ESP8266 device. The latest 4PRO PM model is ESP32 based and runs the Gen2 firmware. I don't need the PM features since all I am doing is switching power relays, but for me the ext £40 is would worth the feature set of the Gen2 firmware. What I am not sure about is switching to 240V control switching Edited January 29 by TerryE Link to comment Share on other sites More sharing options...
TerryE Posted January 29 Author Share Posted January 29 I was getting hassled to move this forward and cocked up on the pros and cons of 24 VDC vs 240 VAC. Most relay products totally isolate the coil switch circuit from the line being switched, a.k.a. dry contact or zero-volt contact. The switch itself will have a maximum DC and/or AC switched voltage and current. In the case of AC the load type is also critical as well as the maximum duration of the load. T The issue with devices such as this Shelley and any other power monitoring devices is that the coil circuitry and the switched circuitry are not isolated and share things like a common common so are definitely not dry contact. 😢 Link to comment Share on other sites More sharing options...
dnb Posted January 29 Share Posted January 29 4 hours ago, TerryE said: As far as I read it the ESP32-based devices such as the 4PRO PM run a firmware build that include a cut-down JS runtime that allows you to do on-device JS scripting Not @Mike but I have implemented a very simple script on my Shelly 3 Pro to sequentially power the pump and heater in my temporary Willis UFH based on receiving a "heat demand" signal from the house controller over Ethernet. It works well enough but it's only a toy example. I haven't yet had time to see if I can send it temperature data from an external source so it can manage the heating all by itself. For what it's worth I'm in the "avoid single source" camp, and strongly prefer open standards with more than one vendor support. (And can't yet see the benefit of paying extra for many of the "smart" applicance currently available) My current plan is to aim for a complete UK/EU based COTS hardware solution where I trust the UKCA/CE marking and write the necessary software to manage interfaces and provide a few algorithms should I need to, avoiding any language that can't count properly and can't make up its mind how it works from version to version. So far I've got DMX for lights working pretty well using tablets and phones as switches, RS485 based Modbus pulling data from the solar inverter and a very odd RS232 link to control the MVHR - it seems Vent Axia didn't implement any meaningful software beneath their "BMS port", so I have used the (well documented on GitHub) option of getting a computer to pretend to be a remote control. Next is to look at Modbus controls for my preferred Samsung heat pump. The rest should be temperature and pressure monitoring and there are plenty of ways to do this. It would appear that for the basic functions I want to end up with there is no particular need to control discrete relays - data based comms is doing the work so I am relatively free to use whatever automation software is around or write my own. I may change my mind as to the requirement for controlling discrete relays when I look again at how to reconcile the excessive hot water demands vs small space heating requirements... But right now I am calling it a win to have most of the need to switch hardware directly designed out. 1 Link to comment Share on other sites More sharing options...
joth Posted January 30 Share Posted January 30 13 hours ago, dnb said: For what it's worth I'm in the "avoid single source" camp, and strongly prefer open standards with more than one vendor support. A reasonable compromise my current project has struct is all wiring infrastructure and "peripheral' devices (lights, switches, sensors, relays, HVAC & PV interfaces) are using open standards: KNX, DALI and a bit of modbus. So the only single-vendor bit (Loxone miniserver) is confined to a single wiring enclosure. In theory if Loxone go up in flames, it's not too invasive a job to drop in a Gira or LogicMachines server in place. It'd be hella lot of re-programming and the user experience would noticeably change, but no need to rip any walls open. Link to comment Share on other sites More sharing options...
TerryE Posted January 30 Author Share Posted January 30 (edited) Relays, bloody relays. The Sonoff 4CH PRO R3 unit uses dry contact relays internally, but these are Golden GH-1C-5L relays that are an AC-only design, and so are not rated to drive 24 VDC control logic. ☹️ Edited January 30 by TerryE 1 1 Link to comment Share on other sites More sharing options...
dpmiller Posted January 30 Share Posted January 30 what "rating" do they need to have? Link to comment Share on other sites More sharing options...
Mike Posted January 31 Share Posted January 31 (edited) On 29/01/2024 at 16:24, TerryE said: @Mike, a Q for you: have you looked at Shelley script yet? ... The main advantage of this as far as I am concerned is that you can add a level of basic on-device safety rules such use "relay X will auto-open X minutes after the last close command". Sadly not - I know it exists, but no time to play as I still have a few months of the renovation to go. But that does look like an interesting use. On 29/01/2024 at 22:00, dnb said: I have implemented a very simple script on my Shelly 3 Pro to sequentially power the pump and heater in my temporary Willis UFH based on receiving a "heat demand" signal from the house controller over Ethernet ...and an useful proof of concept. On 29/01/2024 at 16:24, TerryE said: As you say, the form-factor is great and Shelley is manufactured by a Slovenian company so it's CE certification will be solid. These advantages probably outway the lack of OS firmware. My head hurts. 😨 I know the feeling. Before choosing to go this way, and before launching the renovation, I spent a good deal of time looking at various possibilities, product reviews and documentation for all the various components (including the Crydom SSRs you mention), until I decided that, after various iterations, this was the optimum solution for me. On the Shelly, the CE certification and being a European product is indeed a big plus, and should avoid awkward questions from the French installation inspectorate. At the moment I don't see any need to change the firmware - it's capabilities seem pretty comprehensive and are, so far as I can tell, well implemented. But knowing that at least a few people have installed Tasmota does provide a fall-back. I also like that the Shelly provides those different means of control. So, if the Pi fails while I'm on the other side of the world, it's easy for someone else to use the regular web-based interface - or even just the buttons - to ensure that there is adequate heating & hot water. Similarly, if / when I eventually sell the place, it's not essential that the buyer has a deep level of knowledge to operate the system safely and effectively, if not at optimum efficiency. 230 -v- 24V was an issue for me too and 24V AC did keep cropping up, rather than DC. I eventually decided that it was just going to be simpler to stick with regular kit that an electrician can readily understand and replace, so it was then easy to settle on 230V throughout. And, of course, that also works well with a standard consumer unit. But there are pros and cons for everything... Edited January 31 by Mike 1 Link to comment Share on other sites More sharing options...
TerryE Posted January 31 Author Share Posted January 31 (edited) 5 hours ago, dpmiller said: what "rating" do they need to have? An AC load crosses 0V a 100 times per sec. If there is any arcing then the arc will get extinguished after 5 mSec on average, so AC is a lot easier on the contacts that's why relays which support both AC and DC loads will have a max DC load that is typically 10× smaller than the max AC load, so for example the Songle 5VDC coil relays so often found in budget relay boards have a max of 30 VDC vs 250 VAC. Also needing to break DC needs some subtle changes to the contact materials and coil design to minimise risk of cumulative arcing welding the relay contacts closed. Bad news. So the Golden GH-1C-5L relays used in the Sonoff don't have a DC rating and the Sonoff Datasheet therefore specifies AC load only. They would probably work fine given that the switched current is only 50 mA or so, but you would be using then out of manufacturers spec. Not a wise move IMO. The Finder relays that I mentioned an earlier post here draw 50mA coil current at 24 VDC to operate, so using relays to do this is a bit like overkill. Even a basic Darlington diode IC such as the ULN2003A / ULN2803A can drive 7 / 8 channels resp. ( @MikeSharp01 discussed these on an earlier topic linked in my OP), and MOSFETs or reed relays would also switch this fine, but this would involve me going back to my own custom board or some specialist industrial board that would cost a lot more than a basic 4 relay module. Still if anyone has other recommendations then please post. I would appreciate this. BTW the AC Utilisation Categories (AC1 etc.) are a completely different issue and for more on this see the Wikipedia article linked here. Edited January 31 by TerryE Link to comment Share on other sites More sharing options...
jack Posted January 31 Share Posted January 31 On 26/01/2024 at 21:36, TerryE said: A full IoT HA installation. Here I am talking about a Loxone-type system, the sort of installation that @jack has and where you want a soup-to-nuts home automation. This sort of system needs professional installation and certification, so you are probably talking about maybe £5K+ for the kit and another £5K for professional services, so quite an expensive option. You're probably not far off on the kit cost (especially if you want a lot of centrally controlled dimming), but we didn't have any professional services costs. I did the design with the electrician (who admittedly has an electronics engineering background), he did the installation, and I handled the programming. The programming really isn't difficult if you're of a reasonable technical bent. There's lots of support on Google groups and various forums, too. I'm not sure whether I'd use Loxone again. The upside is that the system is extremely easy to program, and it can be used with a wide range of other protocols. It also virtually self-documents itself as you program it. The downside is that it's very expensive if you want to use their proprietary modules like dimmers. I'd be tempted to just use the miniserver (the Loxone core controller) and have it coordinate everything else via DMX, KNX, and IP based protocols. Also, while it would be a hassle to swap in a different solution if Loxone went bust, it's still just inputs and outputs at the end of the day. I'm sure a lot of what's there could be replaced with equivalents from a different system. 1 Link to comment Share on other sites More sharing options...
MikeSharp01 Posted January 31 Share Posted January 31 8 hours ago, TerryE said: Still if anyone has other recommendations then please post. I would appreciate this. I have a couple of these I intend to use to control 24v which will then use WAGO 24V relays to control the bigger loads. https://thepihut.com/products/industrial-8-channel-relay-module-for-raspberry-pi-pico?variant=40605655367875¤cy=GBP&utm_medium=product_sync&utm_source=google&utm_content=sag_organic&utm_campaign=sag_organic&gad_source=1&gclid=Cj0KCQiA2eKtBhDcARIsAEGTG40_R-cXtRgFbkA_bCKbAX7r1NvSWOReNEeHk8qOv5Sf7LZeswKMf6gaAiS6EALw_wcB As it takes a PICO directly, which you can of course bridge out on the Gpio pins, you have a smart relay board to boot. 1 Link to comment Share on other sites More sharing options...
TerryE Posted January 31 Author Share Posted January 31 Thanks Mike and Jack. For @dpmiller, I note that the board that Mike references uses HLS8L-DC5V-S-C relays which are rated to 10A at up to 30 VDC. Perhaps the main difference between the Pico and ESP32-based boards is that on the ESP-based boards you have a range of options such as Tasmota, ESPEasy (as well full Arduino Runtime and JS, Python and Lua runtimes for higher level scripting) on the Pico for are pretty much constrained to doing your own custom MicroPython firmware development. So for the Pico you have to do firmware development whereas on the ESP you can avoid the need for custom firmware development entirely by using standard OS firmware such as Tasmota which offers and MQTT interface to these type of I/O boards, (as well as having a wider choice of languages/frameworks if you want to go down the custom route). I am comfortable with using custom firmware (I helped develop the Lua runtime for the ESPs, after all) but doing to means that I need to think about long term support options whereas both my son and son-in-law already use Tasmota devices in their own Home Assistant implementations. Here is one example of an equivalent ESP-based 4 channel board that I am considering, and you are spoilt for choice in this space. 1 Link to comment Share on other sites More sharing options...
MikeSharp01 Posted January 31 Share Posted January 31 I have a slightly alternative view of the PICO / ESP issue and that is down to my feeling that I want to support RPi Ltd in developing leading products in the UK rather than buying into a stream of technology from elsewhere, I have nothing against the ESP and was teaching with it until last this year, I am not a 'little Englander' I just want to bring my approach closer to home. I appreciate that I have given up a decent RTOS that I was using on the ESP but on the PICO I can work in VS code environment point it at either C++ or MicroPython which is, I feel, OK for HA work and I can talk to ZigBee, Z-Wave and most other proprietary protocols if I need to. I also wonder, although I appreciate the work involved, how long it will be before you can flash Tasmota onto the PICO! Link to comment Share on other sites More sharing options...
TerryE Posted January 31 Author Share Posted January 31 @MikeSharp01, I am also minded by this wonderful post by @Cooeyswell and to which Jan often refers: "Who the **** is going to fix this **** after your demise?". This is why I now try to avoid doing my own H/W design or firmware development these days. 🤥 1 Link to comment Share on other sites More sharing options...
MikeSharp01 Posted January 31 Share Posted January 31 24 minutes ago, TerryE said: @MikeSharp01, I am also minded by this wonderful post by @Cooeyswell and to which Jan often refers: "Who the **** is going to fix this **** after your demise?". This is why I now try to avoid doing my own H/W design or firmware development these days. 🤥 Yes - I agree, I even advocated not doing this here I think, I won't be developing the hardware I will use COTS components everywhere I can, which I will double up on so I have spare of everything as I don't know how long even established brands will keep on keeping stuff available in a fast moving tech market, and document copiously both the system and the code if I need to develop any. I have wired the house traditionally and in places it will be used as such otherwise the switches just send momentary pulses, at 240V - so if needed be the momentary switches can be replaced by traditional rockers and the HA bridged out to control the lights, to the de-bounced inputs of the relevant PICO - its all node-red, local RPi install of mosquito and MYSQL for data logging - actually getting that stable has been one of the biggest challenges so far. DMX control of the lights via Whitewing will be the way forward although I have not purchased them yet as I don't actually know how many of the lights need dimming! I have struggled to keep it below 16 so I only need one unit but even then I will buy two with one as a spare! So I guess I would argue I have thought this through but I admit the risk you highlight but you must admit that any technology has a life (a carrying capacity) and so there are no guarantees anywhere here, only balances of risk. 3 Link to comment Share on other sites More sharing options...
dnb Posted January 31 Share Posted January 31 4 hours ago, TerryE said: This is why I now try to avoid doing my own H/W design or firmware development these days. 🤥 Agreed. And I do enough of this at work to last me a lifetime. (And I have to train the next generation of engineers to look after it too - the design lifetime extends long after my retirement and the customer doesn't like budgeting for spares...). I'll stick to writing a few bits of software to glue things together. It's about all I get time for these days. 3 hours ago, MikeSharp01 said: DMX control of the lights via Whitewing will be the way forward although I have not purchased them yet If you want a demo, let me know. I have a few of them running linked as a bank now. They are proving to be very good pieces of equipment so far. 6 hours ago, MikeSharp01 said: MicroPython If I can avoid it I will. It is one of two lanuages I have tried that I just don't like. I find many aspects of the language to be absurd, and my experience is that it is a terrible thing for teaching people to code. I am finding that the Pico code I write in C/C++ works reliably but the Micropython code suffers from marginal timing issues and general low level unreliability. Not a problem until I want something to run for weeks at a time. Aside from that, I agree that the Pico is an excellent microcontroller for general use, but it's a shame that theres no acceptable Javascript option yet, although the internet says it is being worked on - there's some merit in everything being in the same language because it makes my head hurt less. (Matlab, Ada and Perl in the office, JS and python at home if I'm not careful. I'm amazed anything works at all some days.) 1 Link to comment Share on other sites More sharing options...
MikeSharp01 Posted February 1 Share Posted February 1 10 hours ago, dnb said: there's some merit in everything being in the same language because it makes my head hurt less. (Matlab, Ada and Perl in the office, JS and python at home if I'm not careful. I'm amazed anything works at all some days.) Yes that is a pain. I have a similar stretch although a different combination and I have tried teaching coding to undergrads in perhaps 8 languages across my career, which goes back to the early 80s, and they all have their challenges (Never Ada though - respect) - started with Assembler, moved through Fortran, BASIC, C (I can see my copy of Kernighan and Ritchie from here - literally), C++, Java (Hated that), C#, PHP, Javascript and now Python mainly because of its breadth - Data Science and Embedded although not mobile and its position on the TIOBE index, with a host of spin outs along the way EG ASP, VB & SQL. I would prefer full Python on the PICO and an RTOS but I appreciate why these are not imminent possibilities although you only have to swap to the RPi Nano and you can do all the languages, not the RTOS, and run under UNIX as well! If I really wanted true, hard, real time (Sommerville's rules as I think of them!) system I would not use Micropython but I think we can get away with a somewhat softer real time system so as long as we can achieve the softer timings it should be a workable solution. Yes I have found the timing issues with Micropython, usually dealing with MQTT publish / subscribe operations, a problem. Seem to spend a lot of time dealing with them - my current strategy is just to keep the main loop handing flagged operations from callbacks rather than extending the callback to actually do the handling. Link to comment Share on other sites More sharing options...
dnb Posted February 1 Share Posted February 1 10 hours ago, MikeSharp01 said: Yes I have found the timing issues with Micropython..., Thanks for confirming I'm not going insane there (let's leave all the other evidence aside). But as you say, if there were a real need for impeccable timing then there are other optons - I'd return to my digital electronics roots and use VHDL and an FPGA. It works well enough in my case to disable interrupts when certain operations are about to occur, and as you did made the interrupt code as simple and short as possible. Link to comment Share on other sites More sharing options...
TerryE Posted February 1 Author Share Posted February 1 @dnb as I mentioned above I was one of the main contributors to the ESP-based NodeMCU-Firmware project which is a Lua based runtime environment that parallels MicroPython. I eventually did a JSH (long-time forum members will get the joke) and stopped contributing because I had an ME/CFS relapse at the time and the project commitments were just taking up too much time and effort that I didn't have the energy for. Anyway back to the point of this. Like Node.js, and NodeMCU Lua, the MicroPython runtime is single-threaded and event-driven in nature. Individual functions run single threaded to completion, so MicroPython makes poor use of the ESP32 multicores and the rich features set of the ESP32 RTOS. For Lua, a lot of the time critical driver code is interrupt driven at a H/W level. I suspect the MicroPython does more inside the Python runtime and hence has more jitters. Incidentally like Mike I've used dozens of high and low level languages in my time (I was even a contributor PHP for a bit, mainly working on Opcache); intellectually Python should be on the preferred ones, but there's something about it that I just don't get on with (I can lump C++ in there too). I like the simplicity and power of Lua, but it just doesn't have the programmer base. All my firmware and driver stuff is done in C still. I like Perl for QnD "hacking", and Javascript / node.js / Node-RED is my preferred platform for IoT and Home Automation. 1 Link to comment Share on other sites More sharing options...
MikeSharp01 Posted February 2 Share Posted February 2 23 hours ago, MikeSharp01 said: I would prefer full Python on the PICO and an RTOS Actually, last evening I managed to get Free RTOS working on a PICO board working, in C++ that is, which I had not tried and it does what it says on the tin so I think I will, once I have completed the terms teaching with Python, I will look at moving my personal system of systems over to that - I still have all the stuff I did with the esp blocks in prototype so lets see how I get on. 1 Link to comment Share on other sites More sharing options...
SteamyTea Posted February 2 Share Posted February 2 2 hours ago, MikeSharp01 said: I have completed the terms teaching with Python Do they want a little project as I have just about given up getting my Python scripts to read my MLX90614s. (can post the kits if needed) Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now