Bet against my view on "Make America Great Again".

And have about a million and a half to put on the table in support of your belief.

For what?

HomeDaemon-MCP.

So let's say you spent the $1.5m and acquire everything.

Here's a hypothetical way of looking at the opportunity.

There are roughly 80 million single-family, detached homes in the US. (I'll ignore condos, mobile homes and townhouses, although some of the first and last are potential customers as well.)

We'll also assume you can appeal to just 0.1% of those single-family homes.  That's a tiny penetration.

But it would amount to 80,000 installations.

The hardware cost to install is under $100 for a minimal install (that's the power that comes from running on a $35 hardware base!) and under $500 for a typical install including sensors and control points (e.g. switches, etc.)

We'll assume you sell the base hardware and software alone for a one-time price of $350, and 50% of your installs go that way (homeowner does the rest on his or her own.)  That's $10m in gross profit.

The real money is in the annuity stream and installed systems.  We'll assume those have a minimum install of $1,500 billed out, of which $500 is your fixed cost.  That fixed cost includes $100 for the controller and $400 for a mix of motion sensors and controlled points.  Install time is 3 hours @ $60 each for skilled labor, or $180.  That's $820 across 40,000 installs, or $32.8 million.  We're now to $42.8 million in gross profit.

Now assume you use the certificate system built into the software and slightly extend it (yes, I can do that on a contract basis, or you can if you have a competent programmer on staff, since the framework is already in the code) to add an annuity-style revenue stream for maintenance, updates and offer an option to the customer for same.  We'll assume you charge $20/month for this and half your 40,000 install-it-for-me customers go for it.

That's another $4.8 million a year in revenue and the effort to issue the certs is about 1 minute each per year.  You can automate that, of course, but there will be expense in doing so.  Of course the actual time spent servicing said customer is variable (and you'd have to take a guess on that), but over 3 years that gets you to $57.2 million.

We haven't yet included what you can make off the "higher end" installations (the million dollar+ homes and condos) where the owner wants not 10 control points but 30, and is willing to pay for it.  He gets convenience, security (e.g. access to his IP cameras and triggering points from them), no cloud required so Google, Amazon and others do not have access to the inside of his home, ever, and you get to sell that -- it's private, it's his or hers, and it's accessible and controllable from anywhere in the world via said secure infrastructure that has no access for anyone other than him -- including you!

Let's assume that of the 40,000 "you install" locations 10% of them are truly high-end homes (remember, we started with 0.1% penetration into the market and now we're at 10% of 50% of those) are not $1,500 installations, they're $3,000+ installations and your gross margin on those is 50% -- which is easily achievable.  That's another $6 million in gross profit; we are now at $63.2 million.

Is this a reasonable projection over three years time?  It's in the game.  No, it's not "riskless" by any means, but on an adjusted risk:reward basis it looks pretty damn good.  In fact, it's not all that far off what I accomplished with MCSNet in terms of return-on-invested capital.  The real return is always on sweat equity as that gives you much more control for the risk you take, but you have to have something that affords you enough operating margin to make it worth it.

Of course there's SG&A to be accounted for.  How good of a businessperson are you?  Cost control is a big part of the game in any business but any line of work is a hell of a lot easier to succeed at when you start with a nice fat margin on the goods and services you sell up front.

This is a 40%+ gross margin business, in short, as I analyze it, and in areas where you have existing people I bet you can sell to vastly more than 0.1% of the households.  Certainly in many metro areas far more than 0.1% are in the $300,000+ price category where a system like this is a tiny percentage of the home's price yet the value delivered in convenience, energy saving and security dramatically outweigh the tiny uptick in cost generated by including or adding it.

So if you're "MAGA" or just believe my view on monopolists, the rule of law and such is horribly pessimistic and wrong, and in addition have the cash to put on the table to back your position with a big fat check then come do so.  Show me that my pessimism is unwarranted the best way anyone ever can -- by making a bunch of money that I am intentionally leaving on the table, handing to me just one fortieth of what I could have had.  We'll drink a beer together when you prove my view on the business environment in the US to be unreasonably pessimistic and you'll laugh as you motor away from the pier on your new yacht.

Of course the above is all "back-of-the-envelope" speculation but that's how a decent functional business plan starts being developed.  It's how MCSNet was developed originally, but before it was actually executed on I fleshed it out and actually wrote a full five-year business plan with pro-forma financials.

The difference between doing something like this and the Ponzi scheme nonsense peddled by many on Wall Street such as belief in 30% growth figures into the indefinite future when you already have half the nation on your service (cough-amazon-netflix-facesucker-cough-cough!) this sort of back-of-the-envelope pencil-out assumes 0.1% penetration into potential buyers.

What happens if you can get 2% penetration?  You make well north of a billion, and then you really laugh at me.

So if you're both "accredited" (you almost-certainly are if you have the capital) and this makes you salivate look right, click and email me.  We'll talk.

When I started MCSNet my view on business changed. I don't consider a 10% gross margin to be attractive at all.  IMHO if you can't get into the 30s it's not worth it on a risk-adjusted basis, and the target is 40%.  IMHO this, while certainly not "buy it and sit" like speculating in something like Bitfraud, fits that category -- but since success is of course directly related to both your analysis (rather than mine) and how you execute (rather than how I execute) this is all hypothetical, but if that 0.1% penetration can be turned into 0.5%, well...... you do the math.

There's no reason Elon Musk shouldn't be under indictment right now.

Let's look at the latest monstrosity claim from him: His "truck".

The truck can drive 500 miles on a single charge, which was higher than some analysts had expected. That may mean that, in terms of range, the vehicle could meet the needs of long haul truck drivers.

....

Tesla will also build a network of Tesla "Megachargers" that will charge the trucks' batteries to a 400 mile range in 30 minutes.

Ok, let's talk about this.

There apparently were eight charging ports, and with a 100kw battery behind each that would be 800Kw.  To deliver 90% of capacity in 30 minutes you'd have to deliver approximately 1.5 Megawatts plus losses; batteries are 80-85% charge efficient during the bulk phase until they reach about 80% of capacity (at which point their efficiency goes down materially) and the electronics to control the charge have loss too -- probably in the neighborhood of 10%.  So we have a 76%, more or less, efficiency on the charge rate which means we must deliver almost exactly 2 Megawatts to the truck for that 30 minutes.

I note that 500 kilowatts has to be dissipated somewhere for that entire period in the truck or the batteries, controller equipment or both catch on fire.  This is a serious problem all on its own that I am not convinced Musk can solve.

Then there is the economic issue.  Musk claims he's going to "guarantee" a 7c/kwh price for all that power.  How he thinks he can do this in a commercial environment where demand meters are used by law is beyond me; the first time a trucker needs to be charged at 4:00 PM on a 95 degree day there will be a very large surprise delivered in the form of the bill.  Never mind that the trucker (or company) will be paying for the 25% losses too; you get to pay for the entire megawatt-hour even though you only keep 75% of it; the rest heats the air.  Apparently Musk thinks that he can simply build "battery packs" to store energy and thus charge them when the power is cheaper.  Ok, that's fine and well, except (1) now you have another 25% loss, stacked (you take one when you charge the pack when "cheaper" and then when the truck is charged) and for each truck's worth of capacity in said battery bank he gets to buy another battery that would otherwise go in the truck, plus another 25% to cover the losses when the truck is charged, plus the electronics to charge, discharge and control that "banked" pack.  Somehow this all is going to "work out" to 7 cents/kwh.

Let me make this clear: No it won't.  If Tesla guarantees that rate to the buyer then Tesla will absorb billions in losses and the more trucks are on the road and the more miles they drive the more money the company loses.

But it pales beside what Musk claims to be able to do when it comes to charging these trucks in the first place.  The average house in the United States consumes about 12 megawatt/hours of energy over the entire year, or about a megawatt-hour per month.  Musk intends to suck twice as much energy from the electrical grid as your house consumes in a month in 30 minutes.

To put some perspective on this that means that one such truck charging will place approximately the same load on the grid as 1,400 houses.  One truck.

What happens when 20 of them show up at the truck stop?  You know they do that today -- they fill their diesel tanks and they're on their way, although they typically only fill said tanks half as often as these batteries will require charging.

So it won't be 20 of them it will be 40 since their range-before-refueling is about half of common OTR trucks now.  Now we're talking about the load of roughly 57,000 additional houses that will be instantly presented to the grid and which the grid must be able to support -- per truck stop or terminal!

Who's going to pay to build all that out and with what will they do so?

It won't be Elon Musk.

I don't believe Musk can deliver this thing at all, nor do I believe he can deliver the Roadster either as the double-size battery pack required to do so (against today's Model S and X) won't fit in the chassis.  So that problem exists too, and it's not an easy one to solve.

Finally, when it comes to the truck there are some other interesting issues related to efficiency.  See, this thing is supposed to be able to couple to any existing trailer.  Ok, fine, but existing trailers are flat-backed and thus have fairly nasty aerodynamics.  You've seen the "trailer tail" things on some of them, I'm sure -- a flip-out contraption that cuts -- somewhat -- the aerodynamic drag generated by the turbulence at the rear of the vehicle. I'm not at all confident the sort of highway range Musk is talking about can be achieved without material improvement in the aerodynamics at the rear and bottom of the vehicle, which means "no standard trailers for you sir!"

That leads to a very large problem; you see flat-back trailers are that way so they can be backed into a loading dock and both loaded and unloaded.  It also makes intermodal (container) shipping possible since a container can be dropped onto a skeleton trailer that locks into the corners of the rectangular container box.  How do you do that if you apply real and effective aerodynamics to the rear and bottom/sides of the trailer?  You don't.  While there are answers to this problem they likely involve a complete renovation of how loading docks are designed and work today, never mind container ships, and that design is literally everywhere from the corner grocery store to the large manufacturing center.  Good luck with shoving that change down every receiving and shipping dock in the nation's budget, never mind the expected gross increase in size such changes would require (e.g. for "side loading" or similar.)  Oh, and since there are length limits on combination vehicles (tractor/trailers, etc) as well you either get to forfeit quite a bit of usable cargo volume or the laws have to be changed to accommodate the materially-longer aerodynamic section of said trailer!

All of the foregoing assumes you believe 800kw of battery is enough.  I'm not so sure.  The math doesn't pencil today on that and I don't see how Tesla can overcome the deficit under any plausible scenario.  Today's diesel truck gets ~8.5mpg, roughly, fully loaded @ 80,000lbs gross (maximum 50-state legal limit.)  Diesel contains ~136,000 btu/gal, so if we take 500 miles (maximum range of said EV truck) we would need ~60 gallons of fuel containing ~8.2 million BTUs if that was a conventional diesel-powered tractor. A modern diesel (with all of its computer controls and transmission) can achieve very close to 40% thermal efficiency in steady-state on-road operation (assuming ~5% gearbox and parasitic loss), which means 3.264 million BTUs have come out the business (driveshaft) end of the engine and transmission when it finishes burning that 60 gallons of fuel.

Musk's 800kw battery only has 2.7 million BTUs of energy in it.  That's 18% short, roughly, but in fact it's worse than that because neither his motors or the PWM controllers for them are lossless, and remember, we've accounted for the diesel's engine and transmission/accessory inefficiency.  If we assume Tesla's electric motors are 90% efficient (possible but unlikely; 85% is more-likely but I'll give him the other 5) and the controller is also 90% efficient (possible) the stacked loss there is 19% so now he only delivers 648kw over that same period of time to the driveshaft(s).

In other words he's not short 18% on energy content he's short a whopping 32%!

I call immediately on him being able to improve the total loss budget by 32% ex engine and transmission -- which basically means through aerodynamics since his truck still needs to roll on tires and the trailers are identical -- so he can't get much if anything on rolling resistance.  That leaves aero and to obtain that sort of gain even on the freeway, say much less in combined-cycle use, would be enormous.

Oh, and the batteries?  They come off the useful load of the truck as well, so on a dollars per pound-mile moved for cargo the electric truck has a further deficiency to overcome.  In short his claimed range and parity level for power is a big stretch right up front!

In the end what we have here is Musk promising to deliver what he can't today, and he's counting on two things to bail him out:

• Wall Street will continue to give him money on the come in the hope that the technology in batteries advances fast enough for him to be able to actually build the packs and fit them in the vehicles, along with solving the heat dissipation problem during charging that would otherwise cause the vehicle to catch on fire and be destroyed.  Given the relatively short timeline he has set for himself I rate the odds of this happening as perhaps one in a thousand since none of this can be done today.
  
  AND (not or)
  
  
• The Government will force you to pay for his charging systems by having a gun shoved up your nose and the money extracted from you both for the additional generating capacity necessary and infrastructure upgrades to get that generating and power-delivery capacity to the truck stops and terminals effectively none of which currently have anywhere near that sort of capacity available to them.   Oh by the way many of these terminals are a long way away from existing generating capacity and high-voltage transmission equipment so the build-out cost will be even worse -- by a lot -- than it first appears.  As a conservative guess this is likely to put a 15-30% increase on your home electric bill should any material percentage of the OTR fleet convert.  There are roughly 1.9 million heavy and tractor-trailer drivers employed today; consider what would happen if 500,000 trucks were to attempt to convert to electric drive each of which would require a 2 Megawatt charge for 30 minutes every six operating hours.  There is no possible way to support any material percentage of the current OTR trucks converting to electric power on the existing grid and this build-out will not be paid for by Tesla or the trucking companies if it is attempted -- it will be paid for by you.

Theft as a business model is a crime.  Promising that which you can only deliver via speculative advances in technology and by stealing a large part of your operating cost from others who do not use it ought to land your ass in prison and reduce your company to a smoldering pile of ash.

Then again Hastings did exactly that to America with Netflix and Net Neutrality and Amazon's Bezos does it daily with cross-subsidizing product sales with AWS, including to the Federal Government (which means he steals from every taxpayer to do so), so why shouldn't Musk rob everyone of tens of thousands of dollars in his plan to "build" these trucks right up front, since you didn't lynch Hastings or Bezos when they did it and in fact rewarded both with billions.

This shit has to stop, the firms doing it must be destroyed and their executives imprisoned.

For a bit of background see this article, or check out the page at http://homedaemon.net

The software now has had added to it a quite-complete Amcrest IP camera interface.  It is capable of triggering events on any of:

• Motion
• Audio (either "any" or "above threshold")
• SD card removed (if you have one in the unit)
• Dry contact (these cameras have a user-selectable normally closed or open input on the back; quite useful for things like a door or window switch, for example.
• Attempted hacking (e.g. repeated authentication failures)

These capabilities should be functional against any "modern" Amcrest IP camera with reasonably-recent firmware.

In addition at any time (not just on the triggering of these events, but any event HomeDaemon recognizes) each camera can be instructed to take a snapshot with optional motion to a pre-set point occurring first.  The snapshot can be taken as a "regular" (subject to roll-off) or "protected" (in a folder not subject to roll-off) image.  The software has configurable limits for the maximum number of snapshots to keep and the minimum file space that must be available on whatever device is used for same, and it will manage space as required to remain within those limits.

The snapshot and "grab" functions are all implemented over "https" (and require it) since the provision of a username and password to the camera is required and while the cameras supports "digest" authentication (better than "Basic", which Amcrest recently removed -- thank God!) MD5 digests are not particularly secure.  It is strongly recommended that the storage volume for retrieved snapshots not be on the system boot device (e.g. a plugged-in USB stick is appropriate) to prevent the possibility of trouble with that device causing problems for the running system.  Once stored having a timed job or listener transfer images as you wish to an offsite location is a matter of trivial implementation since there is a full FreeBSD operating system running under the HomeDaemon-MCP code and the files stored are standard .JPGs with names based on the camera name, date and time.

Finally, all of this, like the rest of HomeDaemon MCP's operational capabilities, takes place under a high-performance multi-threaded implementation so as to be able to transact against multiple cameras at once.

Since the system includes certificate-based authentication already building in rights management (either on a subscription or purchase basis) would be quite easy to suit whatever business model you may have in mind.

Come check out the description and more info -- this code is for sale, all-rights and in source (written entirely in "C"), should you be looking to either establish to expand a home control firm with a security-related focus.  Click on the contact links on the right sidebar to get ahold of me -- and thanks!

HomeDaemon-MCP has now had added to it's bag of tricks an interface to Amcrest IP cameras.

It can now "sense" motion or other events (as defined on the camera) and trigger events on HomeDaemon.  Among other things Amcrest is nice enough to expose a simple HTTP-based API that allows you to move the camera to a given preset and take pictures.

This makes trivial interfacing and extending HomeDaemon's existing capabilities in providing an "alarm" service to include taking of pictures, using the camera's motion sense capabilities as a "trip" and, of course, securely copying them to your private file storage on or off your local network.

This functionality should work with all Amcrest camera devices on the market of reasonably-recent vintage and firmware. I have verified that it is fully functional with both the 1080p (one revision back) and 2k (current) models.

There is no longer a need to trust anyone else with said images other than yourself, ever.  It is trivial to, for example, have the system take images on a timed basis and upload them somewhere, whether that "basis" is predicated on an event (e.g. motion detected somewhere, not necessarily in the immediate area of the camera), to take a picture once a day of your pool water level and email it to you (nice if you are worried about evaporation being a problem so you can ask the neighbor to come turn the hose on for a couple of hours, etc) and more.

See here for more information.

I've talked about HomeDaemon-MCP before.

It's still here, of course, but has continued to be refined and developed.

The current version is 3.0.0 and runs the place.  What's distinct about it compared against other choices?

First and foremost, it has no "central site" requirement at all.

In other words nobody but the owner has access to it and what it controls and monitors.  It uses SSL certificates both to secure your login (via a simple https interface) and to control slave connections between units (of which it can support an effective infinite number of.)  It will talk seamlessly to Zwave devices (including secure ones using AES encryption) and, for those who insist or have legacy devices, X10.

The certificate-based security model means it's trivial to set it up either a "buy it once, get a certificate good for what amounts to lifetime service" or a "buy a certificate good for a year" sort of model (e.g. subscriptions) on the retail side.

In the present political environment I have no interest in retailing it or developing the business structure to either put forward a distribution model or a retail sales model.

But you might.

Oh, and there's a provisional patent related to it that I will file (obviously before I tell anyone what that is or how it works) and it will go with the code, if someone buys it from me.

Yes, this is a "one check" sort of deal, but as you can imagine it might be a fairly large check.

If there's interest use the links on the right to email me and I'll get back to you promptly.

This is what the "monitor" page looks like on my cellphone:

And this is what's running all of that except for the pool gear (it'll run on essentially any system that can run FreeBSD; the Pi happens to be nice and cheap!)

The pool gear has another Pi with a handful of inexpensive ADC (commodity "adafruit" modules for analog sense and relay) ports to switch the valves, pump VFD and spa heater, enclosed in an inexpensive outdoor-gasketed sprinkler-controller enclosure.  It connects over a machine-certificate secured SSL link via WiFi, appearing as a seamless part of the whole.

No more spying, no Alexa, and if you're wondering how stable it is here's your answer -- the last downtime was due to me voluntarily turning the power off to do some work on the rack underneath it..

HD-MCP Controller
Private System; unauthorized access is punishable by law.

$ uptime
2:57PM up 144 days, 17:16, 1 users, load averages: 0.19, 0.18, 0.13