Dev Journal: December 12th 2018 - Docker and RabbitMQ
Well, after my Linux fiasco I'm up and running. And yes, MOST of my problems are driven by using Linux in Virtual Box rather and dual booting. But, then, I'm using an NVidia GPU, so I would have SOME issues anyway, and some of my issues were distro-hell related.
But, this post isn't to rant.
I've started making headway on my project. Progress is slow. I'm much more confident and comfortable in Visual Studio than Visual Studio Core for C# development. And .Net Core on Linux is a whole new experience as well.
But, all of these technologies I'm hitting are great to learn (except Linux, but that isn't really new to me). They are trendy new technologies, which can't really hurt in hedging bets. And every technology is something we're investing in at work. .Net Core isn't really *new* either. I mean, it is technically new to me, but it is just C# and generally, at this stage in the game, the stuff I need is just there.
So thoughts? Things are coming together (at this stage of the game) better than I expected. By a LONG shot. In fact, everything is working out as planned and synergizing quite well. An early botched fight with Docker lead to an eventual successful install which allowed me to run RabbitMQ in a container, which means I'm not even running RabbitMQ installed. Which fits perfectly with my dev ethos. And, after a bit of thoughts and review... even fits with how I would plan RabbitMQ to fit in the final product. I don't need persistence on the MQ side.
So, what do I have? Well, I have Docker installed, working and integrated with VS Code. I have a RabbitMQ container setup which I can quickly compose and use. I have a project with a REST service. And I have sample code which can publish and subscribe to messages in RabbitMQ and it is all working. Oh, and SQLite wired and tested with that REST service.
In short, while I have NOTHING specific to my app completed. I have actually proved out pretty much all of the technologies already. And, since they are all new to me, and they all seem like they will work as expected... AWESOME.
What I expect this to look like it still high level. There will be a service (the evolution of my REST service in the above example). It will store settings and plugins and be able to process calls which will publish and receive back data from the MQ. Probably through some fairly primitive dispatching methods.
There will also be a UI service which will serve up HTML to a client. It will get setup and plug-in metadata from the REST service, and it will also be able to talk directly to the MQ. It will have a much more robust access to the MQ, including direct pub/sub capabilities to the Queues. In fact, the REST service may not even expose anything beyond perhaps publish calls, not sure yet. Most chatter over the MQ will happen either within the service itself between different plugins and/or actions and the UI components.
I don't want to get too deep. But as the frameworks fall in place, the ideas start solidifying.
The takeaway is, I'm enjoying this. December is a month where I take a lot of time off work. 2 years ago I started Japanese. I think I want to make these staycations, times where I start taking on new learning projects. Last year was "wasted" a bit. We hadn't been in the house that long yet. I don't even remember last December to be honest.
Like I felt with Japanese, I'm slowly feeling an urge to learn and follow through with something new in the programming realm. I can't say the past year was horrid that way. I did, by and large get my Japanese lyric translation app completed. Limitations from Spotify mean it will never get published and headaches with Android dev on my specific hardware mean I won't likely finish that port either. But, I did accomplish a lot. I proved I'm actually quite capable of producing what I wanted. So, I'll say that was last years project.
So yeah, RabbitMQ is going to be the vehicle through which the UI and server and plug-ins communicate with each other. This is crucial for me. The two things that I feel like the Smart Home is missing are Multi-User, Multi-Room hub software and "Smarts" which leverage basic functionality of Smart Home to create MUCH more intelligent experiences.
The first is simple; I own the house, but I want a cheap browser capable screen/tablet in my daughter's room. I don't want her to be able turn my light on and off, but she should have a "portal" into the devices she is allowed to control in her room. But, at the same time, I want a view in, say, my office which prioritizes the office. But, it is MY office, and I'm the home owner. So, I should also be able to access a secondary view which allows me to turn off my daughter's lights.
This hub concept is something we're SLOWLY moving towards. Google Home devices, including the Hub are aware of the room they are in, and default to some degree to that slice of the smart home. But, do nothing to control access or tailor experiences. And a home hub is a lot more expensive than something like a small Fire tablet or a budget smart phone. It isn't REALLY extensible or practical. And yet, the solution is pretty simple. Make something like openHab and layer more control over top of it.
I may even build a set of openHab based plug-ins, as it might be easier to lean on their REST services in the short run while I'm building out my own.
But, that isn't where RabbitMQ comes in. That is the next piece. Making Smart devices smarter. The only company that ever did anything like this kind of gave up. And that was Nest. Nest Protect can turn off a furnace in the event of a fire. Link with Hue lights to and co-ordinate with other Nest Protect devices. The Home/Away function of the Thermostat also has some integrations. But, it is very light weight and nothing has really been done in a long time there and it isn't developer extensible that I'm aware of.
That is where RabbitMQ comes in. When a plug-in does something like read a temperature. It passes that data to the Queue. Anyone can subscribe to it. In the simplest scenarios, the UI components might take the data and update the UI. Another listener might log the data to a DB to help model temperature trends. A listener for plug-in for a smart vent might take the data and realize that the upstairs isn't heating up as quickly as the downstairs and close some vents.
Then, a plug-in for the weather pushes out a message indicating that the weather has gotten warmer. A listener which knows how to read data related to the thermostats and weather and how to control the thermostat and smart windows subscribes and gets that data. It decides, we're in heating mode, it is warmer outside than in, and the humidity outside either won't affect or will improve the target humidity rate in the house. So, it turns off the thermostat and opens some windows to save energy.
Voila! It is like IFTTT. On steroids. And, on the local network. Suddenly, there is a lot more potential to buying multiple smart home products. And they can even span brands as long as there are SDKs/APIs available. There are far fewer limitations.
IFTTT is weak because of it's strength. It isn't aimed at insanely technical users. Mine, kind of is. It is like MagicMirror in that, people with the skills will need to write the plug-ins. But, in theory, if they were published somewhere centralized, it might be possible to automate, or at least instruct less technical users on how to get them and configure them.
In theory... mine is the kind of software you could also build a trades industry around. People could offer skills to install hardware and configure installations for bespoke smart homes.
But, right now? I just want to solve my own problems.
But, this post isn't to rant.
I've started making headway on my project. Progress is slow. I'm much more confident and comfortable in Visual Studio than Visual Studio Core for C# development. And .Net Core on Linux is a whole new experience as well.
But, all of these technologies I'm hitting are great to learn (except Linux, but that isn't really new to me). They are trendy new technologies, which can't really hurt in hedging bets. And every technology is something we're investing in at work. .Net Core isn't really *new* either. I mean, it is technically new to me, but it is just C# and generally, at this stage in the game, the stuff I need is just there.
So thoughts? Things are coming together (at this stage of the game) better than I expected. By a LONG shot. In fact, everything is working out as planned and synergizing quite well. An early botched fight with Docker lead to an eventual successful install which allowed me to run RabbitMQ in a container, which means I'm not even running RabbitMQ installed. Which fits perfectly with my dev ethos. And, after a bit of thoughts and review... even fits with how I would plan RabbitMQ to fit in the final product. I don't need persistence on the MQ side.
So, what do I have? Well, I have Docker installed, working and integrated with VS Code. I have a RabbitMQ container setup which I can quickly compose and use. I have a project with a REST service. And I have sample code which can publish and subscribe to messages in RabbitMQ and it is all working. Oh, and SQLite wired and tested with that REST service.
In short, while I have NOTHING specific to my app completed. I have actually proved out pretty much all of the technologies already. And, since they are all new to me, and they all seem like they will work as expected... AWESOME.
What I expect this to look like it still high level. There will be a service (the evolution of my REST service in the above example). It will store settings and plugins and be able to process calls which will publish and receive back data from the MQ. Probably through some fairly primitive dispatching methods.
There will also be a UI service which will serve up HTML to a client. It will get setup and plug-in metadata from the REST service, and it will also be able to talk directly to the MQ. It will have a much more robust access to the MQ, including direct pub/sub capabilities to the Queues. In fact, the REST service may not even expose anything beyond perhaps publish calls, not sure yet. Most chatter over the MQ will happen either within the service itself between different plugins and/or actions and the UI components.
I don't want to get too deep. But as the frameworks fall in place, the ideas start solidifying.
The takeaway is, I'm enjoying this. December is a month where I take a lot of time off work. 2 years ago I started Japanese. I think I want to make these staycations, times where I start taking on new learning projects. Last year was "wasted" a bit. We hadn't been in the house that long yet. I don't even remember last December to be honest.
Like I felt with Japanese, I'm slowly feeling an urge to learn and follow through with something new in the programming realm. I can't say the past year was horrid that way. I did, by and large get my Japanese lyric translation app completed. Limitations from Spotify mean it will never get published and headaches with Android dev on my specific hardware mean I won't likely finish that port either. But, I did accomplish a lot. I proved I'm actually quite capable of producing what I wanted. So, I'll say that was last years project.
So yeah, RabbitMQ is going to be the vehicle through which the UI and server and plug-ins communicate with each other. This is crucial for me. The two things that I feel like the Smart Home is missing are Multi-User, Multi-Room hub software and "Smarts" which leverage basic functionality of Smart Home to create MUCH more intelligent experiences.
The first is simple; I own the house, but I want a cheap browser capable screen/tablet in my daughter's room. I don't want her to be able turn my light on and off, but she should have a "portal" into the devices she is allowed to control in her room. But, at the same time, I want a view in, say, my office which prioritizes the office. But, it is MY office, and I'm the home owner. So, I should also be able to access a secondary view which allows me to turn off my daughter's lights.
This hub concept is something we're SLOWLY moving towards. Google Home devices, including the Hub are aware of the room they are in, and default to some degree to that slice of the smart home. But, do nothing to control access or tailor experiences. And a home hub is a lot more expensive than something like a small Fire tablet or a budget smart phone. It isn't REALLY extensible or practical. And yet, the solution is pretty simple. Make something like openHab and layer more control over top of it.
I may even build a set of openHab based plug-ins, as it might be easier to lean on their REST services in the short run while I'm building out my own.
But, that isn't where RabbitMQ comes in. That is the next piece. Making Smart devices smarter. The only company that ever did anything like this kind of gave up. And that was Nest. Nest Protect can turn off a furnace in the event of a fire. Link with Hue lights to and co-ordinate with other Nest Protect devices. The Home/Away function of the Thermostat also has some integrations. But, it is very light weight and nothing has really been done in a long time there and it isn't developer extensible that I'm aware of.
That is where RabbitMQ comes in. When a plug-in does something like read a temperature. It passes that data to the Queue. Anyone can subscribe to it. In the simplest scenarios, the UI components might take the data and update the UI. Another listener might log the data to a DB to help model temperature trends. A listener for plug-in for a smart vent might take the data and realize that the upstairs isn't heating up as quickly as the downstairs and close some vents.
Then, a plug-in for the weather pushes out a message indicating that the weather has gotten warmer. A listener which knows how to read data related to the thermostats and weather and how to control the thermostat and smart windows subscribes and gets that data. It decides, we're in heating mode, it is warmer outside than in, and the humidity outside either won't affect or will improve the target humidity rate in the house. So, it turns off the thermostat and opens some windows to save energy.
Voila! It is like IFTTT. On steroids. And, on the local network. Suddenly, there is a lot more potential to buying multiple smart home products. And they can even span brands as long as there are SDKs/APIs available. There are far fewer limitations.
IFTTT is weak because of it's strength. It isn't aimed at insanely technical users. Mine, kind of is. It is like MagicMirror in that, people with the skills will need to write the plug-ins. But, in theory, if they were published somewhere centralized, it might be possible to automate, or at least instruct less technical users on how to get them and configure them.
In theory... mine is the kind of software you could also build a trades industry around. People could offer skills to install hardware and configure installations for bespoke smart homes.
But, right now? I just want to solve my own problems.
Comments
Post a Comment