[00:00:00.00] - Gordon
Hello.

[00:00:09.20] - Taylor
Hello.

[00:00:10.11] - Gordon
My name's Gordon from Drayson Design.

[00:00:12.06] - Taylor
And I'm Taylor from The Creative Tinker.

[00:00:14.05] - Gordon
And welcome to "This Week With Taylor and Gordon," a weekly podcast and vidcast where we talk about things that have affected our businesses over the last seven days. And welcome to, I think I'm right in saying, episode 222.

[00:00:27.02] - Taylor
It is.

[00:00:27.26] - Gordon
Wow, 222 episodes. I should mention at this point that if anybody has joined us recently, the purpose of this was originally set up during COVID for something for us to do, and for a way to manage a journal, if you like, to figure out what we were doing. And we can look back at things and see what we were doing at particular times and how we overcame several problems and things that happened in our businesses. And that's why this was all set up. We don't have a big listenership, but the information in here is very interesting for us. And hopefully it's interesting for some other people as well. So with that out of the way, let's get straight into our topics. Taylor, would you like to go first or shall I?

[00:01:18.25] - Taylor
You can go first this week.

[00:01:20.01] - Gordon
I would like to talk about Home Assistant. Now, this is something that I've been talking about for a while now. It's something that I started up this year. For those who don't know, Home Assistant is an automation system that allows you to connect lots of different devices into one software, and that software can then do all sorts of different automations. And just recently, I've looked at the automations I've got set up and made a decision that the way that I'm doing it could be better. And that's all down to experience and playing with the system and figuring out what it can do, and then starting over in some respects. I mean, I've got several automations that I know work, and I'm not going to mess with them. But there are other automations that could be done better. Now, one of the things that I wanted to do is to have a system that would allow me to have all of my notifications in one universal hub so that I could just send the information to that hub, and it would then send the information out to my various devices. Now, my devices for notifications are, generally, iPhone and iPad, and also my Alexa devices, and that's how I get my notifications.

[00:02:49.13] - Gordon
But there doesn't seem to be much point hard coding in the notifications to those devices on each and every automation. It makes a lot more sense to send all the notifications to one script and let that script deal with it all. So then if anything stops working, all I need to do is go to that one script and figure out why it's not working anymore, and then all of the notifications will work again. However, it doesn't seem like many people have looked at this because doing some research online, I haven't found a great number of people who have done it in this way. But as far as I'm concerned, it makes a lot of sense. One of the other things that I've decided is that I use ChatGPT a lot to create my automations because it knows about Home Assistant. In fact, there's a specific Home Assistant GPT that's been trained on Home Assistant. Having said that, I think it's an earlier version. I don't think it's up to date, and it needs to be because there are lots of changes that happen all the time with Home Assistant, and it needs to know the latest changes.

[00:04:04.07] - Gordon
But one of the things that it needs to know is all of the different entities that I have. Now, an entity is basically a device that has various capabilities. So if we look at a simple smart light bulb; a smart light bulb can be on or off, it can be a certain colour, and it can be a certain power. So it can be the brightness, for example. That's pretty much all you need with a light. But that's three different entities for that one light bulb, and every light bulb has those three entities, sometimes more, if it has other sensors in it. An entity, there are an awful lot of entities, depending on how many devices you have connected. And ChatGPT needs to know not only what entities you have, but what the entities are called. And so what I decided was to create a little script that would allow me to create a list on the fly of all the entities that I could then give to ChatGPT. It would then know what they're all called, it would know what I have, and therefore, when it creates the automations, it can put the correct entity ID names and numbers in for me, and I wouldn't have to go looking for them myself.

[00:05:25.09] - Gordon
So I've now created that, and I found the best way of doing it, instead of writing to a file, because that's going to change every time, was to allow it to create a notification within Home Assistant that I could then copy and then paste into ChatGPT. And that's worked really well. And I then got it to create me a "clear notifications" option, which would then clear that notification out because this notification can be quite long depending on how many entities you have. And ChatGPT suggested a different notification list that would show me just the triggers and the sensors, and then it could be put into ChatGPT, and ChatGPT could then suggest different automations that I could use, which is a nice idea. So I've got it to do that as well. Now, this all stemmed from originally thinking, "wouldn't it be nice to have all of the different batteries that I've got in all of my different devices let me know by notifying me and alerting me when it gets down to 10% power and again at 5% power, so I know to either go and charge them or replace them." And that led me on to the different entities list and also onto the notification hub.

[00:06:55.04] - Gordon
So I haven't actually done the battery one yet, but I still want to do that, and I want to create it so that it will create a dynamic list of batteries. So if I add a device, it will automatically add that battery into the list and check that one each time as well. That way, I don't have to redo my list of batteries every time. It will just show up automatically.

[00:07:22.18] - Gordon
So that's where I am with that. And only by... Pardon me. Only by doing one thing can you see what else you need. And you need to build your own framework to be something that will work for lots of different automations in the future. And that's where I am at this point. So I've got lots of stand-alone automations, and I might revisit them and bring them into my new framework and start using that. But it's a great system, Home Assistant, and I really like it. But there's so much you can do with it, and there's so many different ways it can be used that you need to decide pretty early on how you're going to do everything, so that you've got a good basis to build on. And that's where I am at this point. I've had it long enough now to know that that is really important. When you first get Home Assistant, you want to play with little automations and scripts and get it to do things so that you can see what it's capable of. And you can see the short term gratification of something working and happening. But it does make a lot more sense to think long term and think, "how can I make this work really well?"

[00:08:43.11] - Gordon
And how can I build this into a system I can continually use into the future? Now, you haven't started on your Home Assistant journey yet, but you will be very shortly when you move into your flat. So all of this experience is going to be really useful to you, I feel, because it'll set you up without having to start over from scratch.

[00:09:08.03] - Taylor
Yeah, I mean, what you're saying leads into what I was going to talk about, which is setting up frameworks and setting up systems in place when you're building things. So specifically whenever I'm building, so for example, the WP Extended plug-in that I was working on, we rebuilt it to be built around a framework. So essentially every single module now uses the same base framework. So if we update a field input, for example. So we had a colour field, and Dan suggested, "why don't we add a reset button so that you can reset it to whatever the default colour was." And we had 40 plus modules. So if all 40 modules use the same colour field, we would have to do that 40 different times. But by using the framework, it means we update it in this main framework, and it means every single module gets the benefit of it. And it's something that when I first started coding, when I didn't really have much programming knowledge, like you said, you just want to get things to work. You don't care how it looks, you don't care how ugly it is, you don't care how resource-intensive it is, you don't care if it's not performant, you just want to get it working.

[00:10:25.16] - Gordon
And you want to see it working. You want to see the result quickly.

[00:10:29.17] - Taylor
And as you get better at coding and programming, and just building systems in general, you're able to think ahead a lot further and think, "Okay, so I've been in a situation like this before. What can I do to at least shed off a bit of time from having to redo it again?" You're never going to get it right first time. You're still, even for me, when I'm building out things, I will still go back and refactor things to make it modular, to make it configurable. The cinema script that I wrote has a bunch of parameters at the top of the page for how long we have to eat and the location for the starting point when we're calculating the driving time. All of these things don't need to be their own variable and don't need to be in a config file, but it means in the future, I don't have to add that in, or if we were to change where we are going from, for example, I can just update it in one place and reference it in the rest of the file and don't have to go looking to update each instance. So you learn over time to put things into variables, to put things into a place that can be easily managed and updated.

[00:11:49.10] - Taylor
And so that's something that I've been trying to do a lot more, is just be a bit more conscious, be a bit more aware of things I'm doing, but I'm still not going to get them right first time. My personal website is a great example. I've rebuilt my personal website four times. And every single time I've thought, "yes, this is the best route." And every single time it's become a nightmare to manage and maintain because I've added new features that I didn't even think about, and I didn't even know existed or were possible. And so every single time, I got to the point where I'm like, "Okay, I've hit the limit. What I'm doing now is not performing, it's going to cause me even more issues in the long term if I continue with the workflow that I'm doing." A site that I'm in the process of building is a new site that uses a new technology stack that I've not used before. I understand a lot of the fundamentals of it, but even still trying to plan that out and how I'm going to set it up so that when we add a new section, or add a new component, we don't get down the line and go, "I wish we did it this way."

[00:12:54.06] - Taylor
And so I'm having to try and figure out what the best way to do it is. And it's a matter of trying, going, "is this the best way? Actually, this doesn't work that well. There's a couple of limitations here." And pivoting and trying something else. And I'm going to have to redo it probably from what I'm doing. But I'm just in the testing phase to work out what the best approach is before I end up spending a lot of time going down that route and actually setting things in stone, and it's harder to move down the line.

[00:13:22.21] - Gordon
And this is all down to experience, really, isn't it? It's only once you've tried and failed, or tried and then decided maybe that wasn't quite the best route, that you actually learn which route you should take. And the flip side to this is putting in lots of things that allow you to make changes in the future when you're not ever going to need to change anything. So you could spend a tonne of time setting it all up to make it nice and flexible for the future, and then not actually ever using it because it's set in stone, and it pretty much never changes ever. So you've spent all that extra time that you didn't need to, you could have spent on something else, building in systems that weren't necessary. And again, that is something that you need to be very aware of, so you're not wasting time on things that aren't needed.

[00:14:16.23] - Taylor
Yeah, I think the phrase I would use is overengineering. I've done it a lot. I still continue to do it. Sometimes it seems like overengineering, but if you come back to a code base, for example, or you come back to scripts a year down the line, you're not going to know where anything is. You're not going to remember how you had something configured and set up. So sometimes, even though I don't need to change a variable ever again, it's nice to know where that's referenced because it's easier to search for variable names that you've reused than to try and search for a string that you've put in, and you may have put in slightly differently. If you missed a comma or whatever, you're not going to find the same matches. And so it allows you to set a baseline of where things are standardised and set. So if you are looking for something that is changed regularly, you know, "Okay, well, I'm going to have to go here, most likely, to find this." And you can back trace your steps from this, "ok, this is where it was defined, so where is it used?"

[00:15:22.21] - Taylor
And then how is it used? So with your scripts that you've written for your automations, having the flexibility to pass in parameters to your script, for example, to slightly alter how it outputs or how many entities are returned, for example. Say you only want a couple of them because you want to show the last five notifications, or you want to show the last five entities used, you can add that as a parameter, and you don't need to add another function, which is either duplicating code or adding a redundant wrapper function, for example.

[00:15:58.10] - Gordon
Yeah, that's very true. I was going to say something else that you were talking about there, and I can't for the life of me remember what it is.

[00:16:09.07] - Taylor
A lot of over engineering and deciding how to set things up comes down to the trade off, especially if it's client work. So sometimes when I'll set classes for things and I'll set up these systems so it's easily configurable in the future, but it never gets updated and the website actually gets taken down before it's ever used. And I've had situations where I've gone through this whole process of setting up, setting to be configurable by clients, and they've never used them. Either they don't want to or they've never needed to. And I've gone through all that effort to set it up. Sometimes it's worth it, especially if you're trying to learn something. So it's like, "okay, cool. I know how to set that up, so for next time, when I do actually need it, I know I can copy the same process in the same code that I've already used," for example. But sometimes it's just not worth it. The extra time that it would take to implement isn't worth the extra time to you or the client.

[00:17:12.26] - Gordon
I've remembered what I was going to say. You can leave yourself notes in the code as well. So if you do come back to it sometime in the future and you forget exactly what a whole section's for, you can leave yourself little notes as a coder in the code and just point yourself into the right direction. Give yourself a little bit of information as to the process that needs to be gone through if you're going to be adding something or changing something. So there's that that you can do as well, which - commenting your own code is quite a good thing to do, but it does make your code slightly bigger. It's not a lot bigger. It's not really going to affect the running of it. But when people are looking to make it as fast as possible, every bite counts, right?

[00:18:05.02] - Taylor
Yeah. If you have a build script, they usually get stripped out anyway. So they're more there for the visual programming than actually what the produced output is. A lot of the time is just remembering to put the comments in because you're like, "Oh, I know what that does because I've been changing this function for the past three hours. I know what this function does." And then coming back and going, "What does that function do again?"

[00:18:31.11] - Gordon
And it also helps with AI as well. If you've got AI helping you code, having comments in there helps the AI to understand what's important, what's not important, what sections do, and it stops mistakes happening in the future.

[00:18:46.08] - Taylor
Yeah, and I think the other thing I like to do is if I am copying code from the internet or wherever, I like to format it in the way that I know how to use it, in the way that I like my code to be formatted. Because even though the code actually produces the same output, it means that when I come back to code, I know, "okay, this is how I set up the code," so I know where to look, so it saves me time. It also means it's more readable and maintainable for me, because if I need to extend it, if I need to add stuff, I know the way that things are formatted. And especially if you've got other people working on the code base, that's especially important because they're also going to be expecting the code to be in a certain way, which is why you have basically formatters that will format the code in the exact same way. So if you had three indents, but the spec says to have two indents, it will automatically save it and put two indents because it means everybody is using the same format and the same way to read code.

[00:19:50.15] - Gordon
Very good. Anything else you have to say today?

[00:19:53.09] - Taylor
I don't think so.

[00:19:54.02] - Gordon
Look at that. We melded our two topics into one there. So yeah, it's funny. We were both thinking on the same wavelength. We don't talk to each other before we do these episodes.

[00:20:08.05] - Taylor
You steal my topics, that's why.

[00:20:09.12] - Gordon
Because someone else will steal the other's topics, and it's normally the other way around. It's normally him stealing mine. So we don't tell each other necessarily what we're going to talk about. So it's funny that our topic's aligned today.

[00:20:22.13] - Taylor
Yeah.

[00:20:23.16] - Gordon
So that's it for today. Thank you so much for joining us. We are on YouTube. Please like, share, and subscribe. Hit that little bell button.

[00:20:31.13] - Taylor
You can always go to our website thisweekwith.co.uk to find all of our past episodes.

[00:20:36.14] - Gordon
And if you would prefer to listen to us, we're on all the major podcast platforms and on your smart speaker. Just do a search for "This Week With Taylor and Gordon." We'll see you next week on Friday at 1pm. Until then, my name is Gordon and I'm from Drayson Design.

[00:20:53.02] - Taylor
And I'm Taylor from The Creative Tinker.

[00:20:55.20] - Gordon
Goodbye.

[00:20:56.05] - Taylor
Bye.

This Week's Topics

Show Notes