 All right. So first off of that, I'd like to welcome Michael Hansen to the team. Hello. Some of you may have encountered him as the creator of RASPY. And so we're very excited to have him on board. Today, one of our major tasks is going to be figuring out, what is he going to do here? Not that there's a shortage of tasks, but we should figure out what's the best thing for him to go work on. So we're going to talk about that. And we should go over the sprint status, see how we're doing, and just check in with everybody. So let's do that. Ken had some very interesting things to say last week. And Chris Bear wasn't here. So let's start with Ken and see what you got up to. Well, I gave Gez the code to capture the debuts statuses so that we would have that during the boot process so we could see what's going on during their AW connect sessions. But from what I hear from Gez, it seems like everything's working fine. The other issue I'm working on is TTS and getting the TTS mimic one to be part of the TTS infrastructure, if you will, and see if I can keep them from stepping on each other. It's interesting because normally what I'd like to do is create sessions at a very high level, or at least a low level, with the audio service that you can make sure you're not going to overwrite somebody else. That's not kind of our architecture. We just A play out there. And it's not clear to me what I want to do about that here because it's almost like mimic one and mimic two should be interleaved, which is kind of a weird situation, but might be desirable. So you're speaking, and mimic two goes out. At least you can pick up with mimic one and continue. So I don't know if that's a goal or not, but that's what I'm working on now. OK, well, it sounds like maybe we should have a quick team chat about what that goal should be and what the intended system behavior is. Exactly. One of those situations where we kind of inherited what was done before. And it's certainly not clear to me what the intended behavior was, but the way it's behaving now is not good. So this was only highlighted in the last week or so when we, the mimic two server was half down. And we had, therefore, some intermittent mimic two problems or delays. And that caused mimic one to get triggered. And so we had Minecraft talking over itself. Sometimes mimic one and mimic two playing at the same time different things, which is just an architecturally untenable situation like it should just never be able to do that unintentionally anyway. So that's what Ken's looking into untangling that there. And it looks like just to give a little more background on it. It looks like it's because mimic one and mimic two are not treated symmetrically. Like mimic one is sort of baked into the system at a low level rather than being treated like a service like mimic two is. That's my layman's view of it. So yeah, that needs to be sorted out. So we can have a discussion about that. Or you guys can have a discussion about that after. So OK, cool. Thanks, Ken. Let's see. Derek. All right, so yeah, basically on the team means about the same stuff, working on the CAD updates for the mechanical changes for the market too. But yeah, since Mike, you didn't need to talk before now. So my role is the designer on the team. And I do the mechanical. I'm getting industrial design background, but so we don't have a mechanical engineer side of doing mechanical CAD as well. But here in these meetings, typically, I try to contribute more on the software side, although lately I've just been really swamped on the mechanical side. So things like user experience and design. On the voice assistant side, that'd be like the voice interaction, the dialogues, and things like that. And then on the graphics side, I do all the GUI mock-ups. We use Figma to do all that. And so yeah, I kind of cover the gamut of design stuff. But the thing that I do want to jump in on when needed is on the Wi-Fi setup. I've been kind of noodling on it a little bit and talked to Gez about some of my thoughts. And I think he was in agreement. It's just that when we lose Wi-Fi connection, what do we do? And I think in the past we've actually, I'm not even sure the state of it right now, but if it's in the middle of night and you just yell out, lost internet connection, set up Wi-Fi again, that's not going to be a great experience. Of course, we don't have internet. We can't do speech to text. So we've got some tricky things there, too. So how do we fire off Wi-Fi setup when we want to in that situation or just quietly let Minecraft continue to try and reconnect to your existing Wi-Fi, assuming it could possibly just be an outage? So there's some tricky things around that that I want to talk about once we get there. Yeah, because I want to avoid yelling at our customers in the middle of the night. Yeah, I love the idea of a robotic voice screaming Wi-Fi out. Yeah, exactly. We don't want that. So yeah, so anyway, that's what I'm up to. OK, yeah, that's actually a really good point. Always seems like there's more to do. Yeah, I mean, if you think about it, we can still do the wakeboard, right? So you could sit there quietly. Minecraft could sit there quietly trying to reconnect, just waiting for the user to interact. Once they interact, then if they say, hey, Minecraft, wake up and wake up the device, then we can present them some options. Of course, I think the problem then being this, selecting options when you really only have, hey, Minecraft as an input could be problematic. But there's ways around it. There's some ideas I've had. You at least have Mimic 1 available to speak back something. And I don't know if you could play. There's that little ding that plays when you say, hey, Minecraft, I don't know if there's a different sound you would play that indicates, I'm awake, but something's wrong. Right, yeah. And we can do lights. We can change the lights to orange or something to show those kind of errors today. And we can throw on the GUI. We've got to touch on some buttons for interaction if we need it. Yeah, and that's why we can do that for sure. But then again, do we want to have a totally touchless voice? I don't care. Remember, we're designing for the Mark II. That's true, OK. Ultimately, yeah, obviously. But in my view, intents are intents, whether they're touch, conveyed via touch, gesture, voice, buttons, whatever. I mean, I view them all as they should all be their own first class citizens. Obviously, we start off as a voice assistant, but I think that we treat these things generically. We're going to have a much more robust system. Well, I mean, on the Mark I, we had the button. And the Mark II, we have the action button. That's one thing I thought about. Just give a prompt that says, if you'd like to start Wi-Fi setup for a new Wi-Fi, press the button. If not, I will continue to try and connect to your existing Wi-Fi. Something like that. But anyway, yeah, we can get into the details on that. Yeah, well, because it's also a mild security issue, if you've got this open access point that is on when you're not even there to use the device. And someone else can sit outside your home and connect your micro device to their own network. Unlikely, but it is it. Right. Yeah, sure. Yeah, you may actually want a touch screen prompt. I mean, you have to press the touch screen button to finish the Wi-Fi setup just because of that issue. Then they'd have to break into your house as well. Right. So yeah, just saying we're encouraging people to break into other people's houses. Got it. So yeah, whenever we get there. What if I'm being held hostage? Hey, Minecraft, call 9-1-1. I don't know. Oh, OK. I tell Brian. Well, we can train a safe wake word eventually, right? That's true. Exactly. Yeah, we've talked about that. All right. OK, yeah. Thanks, Derek. Let's see. Who's next? Ken talked. He does talk. Derek, Chris? Chris, do you have any? Yeah, so I guess the biggest thing I need right now is to understand where we stand with. When I was talking to Mike earlier today about the startup sequence, I was like, OK, we get all the things started up. And then we have this blob of things I don't know that gets us from or initialized to do we have an internet connection or not. There's some logic in there that I'm not entirely sure how that's supposed to work or if Ken has gotten it to work. And then we have Wi-Fi set up stuff that's supposed to communicate, be more smart than it is now. I don't know where that is. And then after that, we have pairing. So there's a gap there that I think, as far as I remember, has been in Ken's court. I just don't know where that sits and where I need to pick up what we left. OK, yeah, we were talking about this last week. And Ken bent my ear for a little extra time afterwards. And it, yeah, I think we need to keep the MVP goal in mind while we're doing all of this, because we're definitely trying to fix concrete problems right now with the boot sequence. But we should be trying to do the minimal necessary to fix those problems. You know, if and only if the only way to fix those problems is to re-architect a thing or reimplement it from scratch or just tear it out and replace it with something better, should we do that, right? Because the system is very close to working. On the other hand, the flip side of that is that it might just be that we've changed things down to the point where we fixed all the easy stuff and all the slept is the hard stuff. So I don't actually know where we are. You guys are going to have to figure that out. But yeah, I think that you and Ken and Michael should sit down and sync up on that afterwards and try to figure out what the game plan is. Because yeah, the whole boot up sequence with respect to Wi-Fi, whether or not an internet connection is needed or we have an internet connection and then what skill runs after that and all that kind of stuff. There's definitely, there's what's there now and then there's what I think would be the right thing. And I just don't know whether we need to fix what we have now or completely write a clean definition of what we want it to be. So you guys sit down and go through our boot sequence document and see if there's a simple way to just get from here to there. We had some goals that were outlined in that document. I don't recall them off the top of my head. But yeah, see how many of those things that we can take off without having to redo everything. But if we do need to redo anything, we should do it right. We should do it properly, I think. That's my inclination anyway, which means that rather than just going out and doing something that's different than what we have now and then coming back and saying, here's the thing we did. I think the right thing to do is have some discussions about, OK, what are our objectives? What does the system architecture need to be? Open it up to the community, get their input, make sure we have a clean spec that we all understand, and then go implement it. And so that whole process is a lot bigger than just fixing some bugs. So I don't know. Again, I'll just let you guys tell me what you think is necessary. So I'm not sure I understand how much rolling back of what we talked about, why are we doing here? Because are we not concerned about the internet being up? No, no, no, I'm not talking about changing the objective. I'm just talking about just keeping an eye on the scope of the changes that we're making. That's all. And what have I done so far that's? Oh, I'm sorry, Chris. I mean, I wasn't specifically talking to just you. I'm just talking in general. But no, I don't know that you specifically done anything out of scope or that you shouldn't have done at this point. I wasn't commenting on your actual work, because frankly, I don't know what you've done. So but yeah. Well, I mean, what's in the document is what I've proposed to doing and kind of started doing. And I didn't know if this, I guess I'm not sure what the impetus of this, of what you're saying is, like, you know, if Ken bent your ear and suddenly if I have this kind of whoa, kind of feeling to what you just said, where that's coming from. Got you. I can interject very quickly. All I told Michael is I believe we're very close to being complete with the first release of the mark two. And that if we focus on that, then we can get there before years end. But if we go back and restructure everything, looking at the startup sequence to skill interactions, then we probably can't get there by January 1st. Well, but Ken, to be clear, the startup sequence is a necessary function of getting the mark two to MVP, right? Yeah. Yeah. So I think what Ken's saying is that, let's keep the focus to making sure that the mark two works rather than designing a completely clean architecture that is more generalizable, if that makes any sense. So for example, let me go for instance, one thing that is bothering me is, and I think this will be near to Michael Hansen's heart, is the idea that not every system is gonna require the internet, right? But the mark two definitely does require the internet. So let's fix the problem for the mark two, not think about what happens if you've got a completely offline system, right? We don't have to just figure out what the logic for that is, what the boot path is for that, because we're trying to get the mark two to work, right? And so that's a way where we can simplify the task at hand to just making sure the mark two works. The boot logic should work for checking for the internet working because that's the thing that we need for the mark two. We don't need to figure out what the boot path is if no internet is required. Like so there's a simplifying assumption that we can make. That kind of thing. That's all I'm getting. Yeah, and then looking at the whole bring up and connect and access point stuff, the question is, does Derek and Gez, do they think that this is good in working or do they think it needs to be restructured or are we good to move forward on that? I mean, what I produced last week was really just data that or a script that could during bring up say, okay, I have a SSID and I'm connected to a Wi-Fi network or not. And it could insert that additional message on the message bus. And then we can react to that downstream in any way we want. But it's not clear to me that Derek and Gez are saying that the whole thing has to be restructured. And it's not clear that we have to do anything if TanaCore fixes their bugs. So I think we need to look at that sequence from that perspective, but I don't know. I mean, that's really a Gez, Derek call I would think. Yeah. And so again, Chris, this wasn't, I think you're taking this as being directed at you, but it's not. I mean, in fact, I think Ken's comments were as much aimed at me and my inclination to, throw up my hands and say, oh my God, this thing's a mess. Let's just start over, you know. So anyway, just want to make that clear. Your response was in my question about what they've done over the last week. So. Well, yeah. I mean, you weren't here. So that was, you know, that it came up and you weren't able to be part of that discussion. But I mean, with the Wi-Fi stuff, I mean, to me, it's a total black hole right now. That's bothering. Okay. That's great. I mean, it's between initialization and when pairing scale can start. Yeah. So Chris, all I did last week was write the debuff code that on bring up, or at any point in time, monitors the status of the Wi-Fi connection and determines whether it's active or inactive or if it's going through a configuration period. So that's it. That's all I did last week. And I gave that to Gez to put into a build because as Gez had mentioned, it's kind of information gathering at this point because I know what it looks like when the Mark II is running, but what I don't know what it looks like is when a Mark II is first coming out of the box. And so I need to see, you know, when I burn a new build with this kind of a chicken egg, I needed to have this script in there to be able to get that logging so I could see what I could detect while we were going through the AW connect process, if that makes sense. Okay. So that's what we're doing between process and oscillation and knowing whether or not we have an internet connection. Yeah. In other words, are you saying that we don't have any control over the process or are you saying we don't have any insight into the process? I'm saying we don't know how we're going to change. It's broken now. We don't know how we're going to fix it yet. Well, we know, no. Well, we know that Panicor has a bug in their container that they have to fix. What is that for? What specifically is that bug? Well, yeah, you can speak to that now. I thought that was about the reconnect issue, not about a boot time issue. Well, so, you know, it's interesting because I reported that it wasn't reconnecting. They said they had a bug and they acknowledged that. They said it must be more than 10 months old. And then Gary said he's not seeing that bug when he tests. So that's where it is from my perspective. Okay. Well, the bug that I know they do have is that a very, very small number of people don't get an access point created when they boot dead twice. No, that's different. That's the only one that I know about. So I don't know what the other bug is. Yeah, if you go back here, I can read you the Panicor response if you'd like. I thought you were following the channel. So Panicor said, way back when we reported this. Yeah. OK, I understand. We can take that. Why don't you take that offline? Anyway, yeah. It's not relevant to the process because it's about using a Wi-Fi signal and reconnecting. So that's not the process related. So let's just leave that for now. Yeah, and I was going to say, even the stuff that Derek was just talking about before, like I feel like that's not MVP. That's, you know, if your Wi-Fi connection goes down at the middle of the night and Minecraft doesn't know about it, like I don't feel like that's the most critical issue, like compared to. OK, so here's what you're going to Wi-Fi up in the first place. Yeah, this is what you're missing. So this is Julian Hartman's response from the Panicor dev channel to my report. AW Connect does not restart the cap. So it says AW Connect does not restart the captive portal after entering wrong credentials. To bug in AW Connect, I'll look into it. So then he was responding to your stuff, whereas he might have gotten confused. A little bit later, he says, we have identified a regression and editable connect, which stops the captive portal from starting up. We are investigating when and what triggered the regression, because that connect container hasn't been touched for 10 months. We're rolling back the AW Connect to a previous state, which I've been testing today while we are investigating. This should get rid of the bug where the captive portal does not spawns. You get the update on my latest daily Minecraft early build. Ken Smith, the code you're working on should still hold on. Nope. See, I wonder if they're actually relighting. They're going to roll back the AP coming up. And so under normal circumstances, the AP comes up for the vast majority of people, and they can connect fine. At least for me, if I enter the wrong credentials, the access point comes back up after it tries to connect. It fails to connect, and the access point comes up. Currently, we can't detect that. We're not detecting that, and then presenting to the user that that's happened. But quietly in the background, if you go and look, then the access point should be back up there. So I wonder if it's the same bug that is sometimes preventing that access portal from coming up in the first place may also prevent that access portal from coming up on a subsequent attempt. May. So they sent you a new AW Connect build, right? So we're using the 10-month-old version at this point, right, in our builds? Yes, that's my idea. OK, so were you able to verify that that adjusts the problem to the one user who reported it, or two users maybe? No, not yet. OK. OK. Because Julian was nice to share as well, so it was kind of why he began to validate that it was actually working in production. OK. So I think the higher-order issue is, and you kind of sloughed over it a little bit. So yes, if you mis-type your password during bring-up, it will not connect. It won't tell you anything. It won't change screens. And it's left to the user's devices to figure out that that's indeed what's happened, and he should return to the access point and try it again. So if you and Derek are fine with that process. No, no, no, I wasn't saying I'm fine with that process. But I thought that was the whole point of the information gathering was that we would then, I thought you were trying to determine what all those different status messages were so that we can detect that and say, hey, the authentication failed. Try and enter your password again. But the thing that I was saying that we shouldn't get to I've successfully connected my device to the internet. And five days later, the power in my house goes out. And my Wi-Fi router takes a few minutes to boot up. And it's slower than my Microsoft device. And so then Microsoft loads and can't find the internet. And what are we doing that to circumstance? I feel like that's a separate issue. Well, that's indeed a different problem. And let's discuss that real quickly so everybody's clear on that. So we have a race condition. If you have a power outage, or if you powered everything up at the same time, we have a race condition. And that's the mark two will not, in some cases, in many cases, find your real access point, your real wireless router to connect to. And again, the only way out of that is you personally detecting that circumstance and unplugging your mark two and plugging it back in again. So the only issue here from a higher order perspective was can we do better than that, right? On both cases. Yeah, I totally agree. It's still an issue. I just feel like it's that we can break it down into first boot experience and subsequent Wi-Fi issues. And to me, the first boot experience is a more important piece of the puzzle than... Well, I don't have a horse in the race. But my point is all of this ties into probably where Chris V is kind of hung up right now on what should he be doing next? Are we good? Should we restructure something? Do we have an issue? Where are we at? OK, well, the boot sequence is more than just the Wi-Fi, right? There was a whole bunch of problems with the boot sequence. Yeah, all I'm saying is in my document that I have written or that I've been working on, there is a hole between all of the processes that are initialized, pairings. I have to check whether or not the device is paired. There's a gap in there about internet connectivity. And I don't know what we're doing about that. And what our what our path forward is, what should we put in the document about that? And I don't know, it sounds like we don't even know yet. So that's fine. But that's where we're at. I'm just trying to figure out where we are because I've been gone for a week. OK, yeah, here's where we're at from my perspective. I can I have a script. I don't know that it's the final version of it. There's a script now in the bill that is monitoring the Wi-Fi status. And it runs pretty quickly. So I suspect it fires off pretty early in the process. It kicks off right after the guy that checks preparing every second, which is also kind of insane. But the point is, I can tell you pretty early in the process when we have an internet connection. In other words, I can fire off a message on the message bus that says, well, let me take that back. I can fire off a message on the message bus early on that says, I believe we have acquired Wi-Fi. We have a Wi-Fi connection. I can fire that message off and I can get that off pretty early in the process. If that solves our problems, we're good to go. If not, then let's talk about it. That sounds part of it. To be clear, we need this is this is part of the document I believe that Chris is talking about. We need to make a distinction between, I am connected to a Wi-Fi network and I am connected to the internet. And that's what the Wi-Fi skill does now. The Wi-Fi skill now, if you look at it, really just tries to ping the Google name server and then it tries to fetch a page from an HTTPS website. And if it's successful, it says, I am connected to the internet. Okay, I mean, that's fine. There's a few more steps to it. I'll document what I think should be happening about that and you can tell me if that's the list. That sounds great. Okay. I thought we've gone through this in pretty painstaking detail already, but... Yeah, I mean, I was talking to Michael earlier, like questions are so swirling in my mind, like how long do we, after all the services are initialized, if we don't have internet connection at that point, is that too early? Do we have to wait another couple of cycles to see if we really don't have one? I'm gonna... Yeah, so that's, and that's in the code I gave Giz as well after like six minutes of no Wi-Fi it automatically reboots the mark too. Now, I don't know if we wanna keep that. I think that's what Giz was speaking to earlier. Okay, well, let's go back to the very, okay, yeah, we're not gonna solve, first of all, we're not gonna architect a new system in a discussion like this. So, let's not try that. No, no, I mean... Let's go back to make sure that when we're, just go back to the tickets, like we created a series of tickets that each address a very specific problem. Let's make sure we're addressing those problems without introducing new ones, and we should be making the progress we wanna make. So, if we don't have things outlined in tickets clearly enough, then let's have a discussion around that and fix that issue. Well, let me put it in a different way. I put in what I think is potentially needed to get that documents process flowing, right? We said we wanted an indicator of whether or not we had connected to a Wi-Fi network as part of that process. And so I wrote the code to do that. Now, the question is, do you want me to take it further and have it connect to the message button, send a message? Do you want me to have it right to the file system somewhere? Do you wanna keep in the reboot, the automatic reboot logic it has or pull it out or whatever? But at that point, at this point in time, I guess my feedback would be I've done what I think is kind of where we're at until somebody tells me specifically what they want me to do more. Like that would involve timing and response to that knowledge. Yeah, I think so. What Chris is working on was related to waiting for that message, right? We put in the document, okay, we want this message so that we can do this thing with it, right? So then, I guess Ken's asking, okay, well, where do we, where do you want this message to live? I've got a little script I can run. We can put it in in different places. It doesn't belong on the wifi scale, it doesn't belong on the how. It should be part of core. Should we... You want me to fire up a message on the message above? Yeah, well, we already specced that we want a message on the message bus. So definitely we need to do that. The question is, where does that code live? Yeah, right now it gets executed pretty early on. It's in the startup.fh script, which runs early. It's literally... But yeah, but if you bring it into the system, then you have the issue that when does the place you brought it in get fired up, right? Well, in startup, it says it doesn't have a message bus connection, right? So there's nothing... There's no way in there to actually send a bus message that says what happened. Well, I can certainly build some code to connect to the message bus and wait until it comes available. I don't know that that's what we want to do. That's kind of what I'm saying. In other words, I think the debug stuff which said, here's the messages we can get. I'll be able to, once I burn a build and do a run, further determine if that's it or if there's more. And then I can do whatever you want me to do with that information. Well, if I recall correctly, we had said that that logic should live in the hell. So... Which is now right now the enclosure. Which is the enclosure now, yeah. Because we're not building it out. But yeah. Right, so... Yeah, it's literally a non-existent hell. So I'll put it in the enclosure and that's fine. And right now I've been putting most things in the more to enclosure too, just so as not to upset other enclosures. Yeah, yeah, and that's great. But again, there's the whole of the semantics, right? Like if I send that message out, who's listening for it and what's the structure, you know, and how long, you know, that kind of stuff. That's what I think is missing from what I read in the stack the last time was, okay, so a message should be sent on the message box. Well, okay, you know. Okay, let me document and write some more stuff around that because that's what Michael on Monday was, I think we need a little bit more detail and document about how that process works so that we're all clear on it. Yeah, I mean, it could be a directed message, it could be a broadcast message, right? It could be to a specific place or not. You know, it could contain other information. I don't know what you want, yeah. Yeah, well, okay, so we'd also defined a new Mycroft is Ready signal to be sent out, right? And so we need to define what that means and all of these services, since they're all loosely coupled, need to boot up into a state where they're, and this can be a very straightforward, you know, simple two or three state state machine where they go from boot sequence to waiting for Mycroft to be ready to going into the next logical state that they should be in, whether it's just doing their thing or waiting for another signal from a different service or whatever, you know? So, and that's I think at the crux of what, you know, Chris was doing is that there was a whole bunch of mess around, for example, the skill startup, right? And so that's why he went into the skills and that was the skills we're checking for whether or not we had an internet connection or if we just didn't make any sense. And so that's what, you know, that's what Chris was doing, just some little light reorganizing there in terms of making sure that the skill boot up process was just literally just that and nothing else. It was just the skills loading and that's it, right? And then it can have a little state machine that says, okay, skills are loaded. There can be some something, I don't know where it lives. We don't, it doesn't, someone has mentioned like the reviving of the supervisor idea, but we don't need that for this. Something in core just says, oh, okay, well this service is ready and the service is ready and that one's ready and you know, all four or five core services are ready, then mycroft is ready. Okay, mycroft is ready. Now you can start to look for, oh, is the internet ready? Because and whoever's emitting the internet is ready signal shouldn't even try to emit that until it knows that mycroft is ready as the mycroft core system is ready because until that signal is emitted, no one's listening to anything, right? So there can be no real traffic on the bus that's not associated with a bring up of core until mycroft says, I'm ready, right? And then after that, we can start listening for like the internet's ready and stuff like that. So I think that's where we need to get to. And I think I've got a branch of code that's basically, like I've got all that initialization of stuff up to mycroft ready. And that's where I'm at that, now I'm at a point where I'm like, okay, now I have to start asking that question. I don't get it. I've got all that. And what does mycroft is ready mean? That means that it can listen. Now the system is ready. So that all services are initialized. No, no, no, no, no, no, no, no, no, no, no. So let me ask it. You can now emit the internet is connected message and someone will listen to it. That's what it means. I think we need to find that as mycroft started message because it's not as ready for use. Yeah, no, no, you're right. Started, yes. Let me ask the question a different way. So the concept of mycroft being ready is predicated on reception of a certain minimum set of signals, right? Yes, but those signals are defined sort of internal to core, right? They shouldn't rely on anything that is outside of the little box that's running on your desk. Yeah, that's fine. So my question is, Chris V, I take it you've built something that's collecting those signals and you've gotten to a point where you're ready to launch and you haven't gotten any of the signals that you're waiting on. Is that kind of what you're saying? Cause I think no, that's where we lost the last time. The signals come over the bus. The bus doesn't require an internet connection. I've got every process starts, gets through its initialization phase and I get all of them together. Okay, everything has been initialized and now I'm emitting this mycroft started event. Now what? Right, now, okay. Now we need to trigger, right. So the question is, how does the system currently go from whatever it's doing to the point where we trigger the wifi setup skill and the pairing skill, right? Like what is kicking those off? Those were clearly somehow kicked off probably somewhere in the skills manager or something, so we need to replace that logic with something very simple that just does the exact same thing, right? And that's what I was gonna do. I think that's what Chris B said he has done, right? Yeah, I think he removed the stuff from the skills manager that didn't in the skill loading process that didn't belong there, but it doesn't got put back into a more sensible place yet. So what I'm hearing. Yeah, hold on. Chris B, I think what you're saying is you're ready to launch the skills and move forward from Mycroft-Ready's perspective. You're just not getting what you need to make a determination that Mycroft is indeed ready. Is that correct? Because I thought that's what we wanted to do. And one of those things was connectivity. No. Yeah, and what I can do right now is just reuse whatever connectivity logic we have, but the question then becomes, okay, that's what we have now. Is that gonna give us a good boot up sequence or not? Yeah, and that's why I deferred to Derek and Jez on that, right? Okay. But I thought you were waiting for what I did, which was as one of the many signals that your central point is gathering, one of them was, do I have a Wi-Fi connection or not? Internet connection, yes, to be clear. Well, okay, internet connection is above what I did and below you. And that's in the Wi-Fi skill. So it sounds like you're at the point where you could just launch the Wi-Fi skill. Is that right? In theory, yes, I could launch the Wi-Fi skill directly after Mycroft started, it gets emitted. Question is, is that what we want to do? I mean, I sort of can do that. That's what it works today. I'm not sure the Wi-Fi skill is the best place to be checking for any active activity. Yeah, okay, well, you and I are in sync. Okay. Yeah. I mean, I don't know the answer to your question. I'm just saying I understand where you're at. And that's where, you know, the whole, how much, how far do we go, question coming up. Do we just go ahead and launch the Wi-Fi skill and see if that, you know, does what we need it to do and then, or do we? Yeah, so Chris needs somebody to answer his question. I'll make sure the questions are delineated in the document and then we'll answer them later. Okay, great, great. Okay, so yeah, from my point of view, what I just heard is that we're at an interesting point because Chris has cleaned up the boot sequence to the point where we've gotten rid of, you know, these things that were sort of just stuck in at various places, but now we need to take those things that were happening and put them in a more logical place. And because we have a set of loosely coupled services that are comprised, you know, the core experience, there isn't really a logical place for fire off this skill and then fire off that skill. They really basically need a boot sequencer, almost a boot sequencer skill maybe, right? Or maybe it belongs in the hell. Actually- Well, I think what we need is- I think what we need is logic somewhere that's gathering these signals and making a determination that the minimum number of signals required has been met to fire off the systems ready. And my question to Chris, he would be, other than the Wi-Fi connected signal and other than the internet connected signal, I guess all you need at this point is the internet connected signal. And that is going to be a combination of whether the Wi-Fi is connected, whether you've got a valid clock set. And then you, so at your point now, you're kind of in the position, if I'm not mistaken where you're at, is you should fire up the Wi-Fi skill and wait for it to tell you it's connected to the internet. That's where I think you're at. Yeah, there's no, okay. I think Chris, what you're looking for is the Mark II skill. I think the stuff belongs in there. No, it's taken its head. No, I agree with him. Some people think it belongs in the enclosure, but you know. Yeah, I was going to put it in the enclosure, but then it belongs in the Howl long-term. I think so too, because I think it will differ, like it might differ depending on the hardware you're using, for example. Well, the Mark II and the Howl, that's why I, yeah. The Mark II skill and the Howl are both dependent on the Mark II, right? So. They are, yes. It doesn't matter to me whether it's in the Howl. But I would like to, my personal, like the thing that one of the things that we've talked about over the last, however many months, is the desire to keep the skills to actual user interaction stuff. And so the idea is that we should be pulling more and more things out of the Mark II skill, which was kind of used as a dumping ground of, let's put things in here that should go in the Mark II, because it was a nice, easy place to stick things. Yeah. Okay, I'll buy that. Okay, I'll write what we've talked about up in a document so everyone's clear. If I have questions still, I will make sure they are noted in the document. Okay. And we'll move on. All right. So just so I understand, basically what you've done is refactored some stuff. So when you actually push this out for us to all test, we shouldn't actually notice the difference, really. A noticeable difference. It's my assumption, right? There's no functionality, right? All the functions are the same, they're just in different places. Right. Now maybe it'll be a little bit more reliable in some sense, but... Another difference will be that, like I've gone through the skills manager thing and I'm trying to get rid of every place where it needs the internet, up until the point where we wanted to need the internet. Right. There are a couple of places I had to touch for that, that actually tries to hit the internet three or four times. And initially some process. I thought it was one, but it's more than one. Yeah. Okay. So guys, I got to run, but I did want to interject real quick. We do still need some feedback, I think, and you know, Ken's mentioned that. So prompts to let the user know that the wifi is restarting, that they've failed, something failed, they put in their wifi credentials wrong or something that let's try again. We do actually have some prerecorded messages around that. I just don't know if that's broken or if that's not working or whatever, but we need that back. And then I, you know, Chris, Chris, you and I talked about this, this idea of maybe just putting a spinner or a loading bar between when you've entered your credentials and the success connect success check mark. There's just a long time that could take a while and we, you know, just some indication that it's working. It's trying, they're like, you know, just saying trying to connect and then showing some progress there. Yeah. We documented that as a need in Hawaii and there was another screen as well that we documented. Okay. If you guys got that somewhere, if that's in your doc, Chris, okay, cool. I'll take a look. But I think that's all we really need. Of course, more testing will, might uncover some other things missing, but. By this time tomorrow, I'll have a new version of that document that we can talk about. Okay. All right. Cool. All right, see you guys. Around that circle like six times, but okay. Thanks, Derek. And maybe, maybe Michael can help me finish that. Go through to the next version of that document. So you can understand. Sure. I like the idea of the pair programming just to, you know, get them up to speed and throw them in the event. Pair documenting. Yeah. Ken, do you have a, did you document the diva signals you mentioned anywhere? Is it just that script? Or is it? It's just in that script. It's just in that script. And they're, they're pulled out of the WLAN zero device. Okay. Is that in the Mark II branch of core right now? It's up to guess. It should be in the latest build. Can I ask for it to get dropped directly into slash up slash microp. So at the moment it's in the get lab as a filing clue. Well, I assume we can, we can access the D-Bus through Python directly too, right? So if we could put this into your scale. Yeah, yeah, yeah. It's a, it's a startup, a shell script that launches a Python script. Oh, okay. Is that in the 1125 build or do I need to wait for a build to happen the night to see it? I live in, I need to double check the date. But if you just L-S slash L-S slash microp there'll be like a net check dot shell script or something. I'll look for it. Yeah. But just to be clear, the Mark II stable link in dev team, if I burn an image from that, we'll have this script in it and it'll run at boot, correct? No, no, you need the Mark II latest, not Mark II stable. That's in the team channel. Where is Mark II, where is the link to Mark II latest? In the team channel. Oh, send it to you directly. Oh, okay. Okay. All right, so if I burn that, that'll be in there. Yeah. Okay. Yeah, yeah. And if anybody wants to see the code, I mean besides in the build, just ask me or get email, email your Jazzy. I can email you the script. It's not that big. Yeah. Okay, great. All right. I unfortunately have to go pick up my kids at school. So, but I think it would be useful to do a quick recap of the sprint status. And it seems like Ken's kind of at a stopping point. Do you know what you're working on next, Ken? Fixing a TTS problem. All right, okay. So you got stuff to do. Well, then you can hold off on redoing the sprint stuff until tomorrow. Okay. Unless there's, I guess the one thing I will say is just double check that no one's waiting on a PR review from you. So we can get any code pushed out that's been done. Sounds like I have one or two to do for Gazz and I'll do that. Okay. Cool. All right. Well, welcome to the team, Mr. Hansen. Thank you. And yeah. They know all this long, I promise. Yeah. There was a lot of sausage grinding here. So that's good. All right. Well, I will leave you guys alone tomorrow so you can get some more work done. See you later. Thank you guys. All right. See you.