Oh well.

Where I am with the IP camera for the manual PnP machine(s) is dire.

I found the best IP camera streaming hack to run on the XIAO ESP32S3 Sense setup was here. That code seemed to come up and run, without drop-outs I had seen with code from other sources.

I have now run that code against the OV2640 that came with. I have now also vetted the code against both the 160^o 850nm “night vision” camera for my fruit rat hunting experiment, and the long ribboned 66^o camera I was planning to use on the PnP machine(s).

A problem arose, however, since I need to set the 66^o permanently in place, and that may limit the locations I can do that. I got the long ribbon to allow me to mount the camers essentially vertically, over the location the PnP picker will work. The issue, with a fixed focal length, you need to adjust the camera distance from the mount board to focus.

It occurred, therefore, I should have grabbed an autofocus camera. Hence, an OV5640 50MM Auto Focus FOV 65^o is now on its way.

Also wik. I can get the ESP32S3 serving MJPEG to:

• my Chrome browser on me HP Spectre,
• an instance of motioneye running on me home server, from me HP Spectre and
• in the Firefox browser running on my ACER Aspire ONE, which is running Debian 8 etc.

But, I did give up trying to connect VisualPlace to the IP camera from both my HP Scectre and me ACER Aspire ONE, since VisualPlace would not connect at all to the camera served by the ESP32S3 on either hosts. Of note, VisualPlace would also not connect to an IP Camera app running on my android phone.

I’ve also bought a VGA to RCA converter to see if I can use an old portable DVD player as my second screan for the ACER Aspire ONE. If not, I appear to be able to get a 7″ LCD with VGA input from Aliexpress for UAS$70. But, the preference is the get use out of the old DVD player. I may event rip the DVD out of it an see if I can build a lipo into to it, since it still needs a power pack.

Bearly assembled

So far so good

Still waiting on my power supply. But I’ve burnt Klipper firmware for the BTT SKR MINI E3 2.0, and OctoPrint running on the Raspingdoodleberry Pi 2W.

But wouldn’t you know it. At least one report of fragging of BTT SKR MINI E3 V2.0 with this setup.

So poking around I find you can draw up to 600mA with the RPi Zero 2W.

So what current can the “serial” port of the BTT SKR MINI E3 V2.0 deliver?

Who knows.

But, the solution might be an additonal power adapter for LED strips (apparently). Looks like you add that and switch a jumper “Neo-PWR1”, so as to drive the “PWR” line with the “NPWR” output of the additional power module, rather than the on board “+5V” line. That’s the loan red jumper in the photo by the way. Pins are conveniently labelled on the underside of the board.

Maybe. Can’t confirm the current this might draw, but it would otherwise not frag the internal +5V circuit of the BTT SKR MINI E3 V2.0, since it runs entirely via the daughter board.

The daughterboard seems to replicate the on board power supply, same chip – being MK1584EN.

Disposable daughterboards, bought 2 – just in case.

UPDATE

LOL, turns out the person who reported the fragged BTT SKR MINI E3 V2.0 may have shorted it out, rather than it being a overloading due to the RPi Zero 2 W piggyback on the “PWR” line.

ESPHome no-go on TTGO T-Camera

What a pain.

This is the pinnacle of the downside of opensource and the upside at the same time.

ESPHome community, especially, with rules of what you need go through before you’re allowed to “ask” and issues “closed” but not promulgated into ESPHome baselines.

Let’s recap. Two LilyGo TTGO T-Camera v1.6.2 boards. Same ESPHome yaml file, save for device name and IP.

Problems with, lets’ call them board A and board B.

• Both board A and B came with a preinstalled app (probably this one), which runs on power up. You are supposedly to say “Hi LeXin” to it and it then starts a webservice to display the camera stream. No amount of yelling at the boards incites a response. Obviously something is running as OLED screen scrolls. No biggy, I was wanting to use ESPHome examples I had found, so I could hook the cameras into Home Assistant via ESPHome integration.
• Craft an ESPHome yaml based upon examples on the Net.
• Bombed board A, with its own version of the file. No problems apparently, initially – but don’t get cocky.
• Bombed board B, with its own version of the file. Would not start however. Would get into boot loop with the board B yaml file so bombed.
• Cut code for board B back to find if I removed the camera code, then the board fired up and “worked” – but with no camera. So, was the camera on board B fragged? Don’t rush in with an answer.
• Tried bombing board B with board A yaml file. Board B still sat in boot loop unless camera code removed, so no pesky hidden characters or problems with indenting.
• Now I told you not to get cocky. With no code changes or re-bombing, board A now, occasionally, won’t start without multiple bangs on hard reset button. Once up, seems okay. Even fires up again, after unplugging it from powered USB hub then plugging it back in (and then maybe some banging on hard reset), but don’t get cocky.
• Tried banging reset button of board B, because the log messages are eerily the same as those on board A when it struggles starting. 5 minutes of banging the reset on board B fails to get it to start.
• I had backed up the original binary running on the boards, so re-bombed them with original code. They came up again.
• Re-bombed both with ESPHome. Now I wasn’t sure which board was board A and which was board B. Both flaky. Marked up one board as board A to distinguish. Finally, after re-bombing board A a number of times, including clean, it got back to the point it would start with a number of bangs on the hardware reset.
• Gave up. Assumed as long as I could get it started, board A would do as a video door bell, with IR trigger to tell us when someone was there and maybe not inclined to press the button on the gate. So put the project aside until I found the hour or so to run into Jaycar to get a case.
• Come back a week or so later and FRACK! The OLED board on board A not working. Were it software? Were it hardware? I really only placed it into a box of parts for safe keeping. It seemed to connect to HA. The PIR, button, status and wifi signal all working. Opted to go with it and just not bother with the OLED display. But it bugged me.
• To add insult to injury I had found a bunch of resources, including what appeared code for the t-camera series but not HA ready. Regardless, I bombed board B with the native t-camera code and voila! The pesky board ran, with camera streaming, confirming the camera was not fragged. But, FRACK! The OLED on board A did not come up. So, looks like a hardware not software frag on board A somehow?
• I opted to then drop the ESPHome code and use the t-camera code, since it was standard mjpeg stream, with control options mind you, with:

• Another problem popped up, the example code for an mjpeg camera in Home Assistant, when stashed in configuration.yaml, did not create either a camera entity nor device to use. There was definitely a stream, as you could hook it into a chrome web page and therefore a picture entity. There were no errors reported when HA was started, so no evidence why a camera was not created.
• Yet another problem, the t-camera example was for a single streaming client and I wanted the cameras to come up wherever the HA HMI was brought up. Solution, I found code that provided up to 10 streaming clients, goodnuff for my needs, thanks arkhipenko! Just needed to mod the pins descriptions to include the LilyGO cameras (based on the t-camera pin definitions by lewisxhe).
• Note, while the allframes option sounds great, there is a substantial lag in the displays because of the spooling. So, great for a dvr set up, but not intuitive for a video door bell. Also wik, note the code defaults to max resolution for the camera, which again causes lag. I opted to set for VGA and used esp32-cam-rtos instead of esp32-cam-rtos-allframes. Might be fixed with a task per client, noting the software only creates a single task to handle all clients. I am going to poke at that in the background, since all the hard work has been done otherwise.
• Notice there are quite a number of boards arkhipenko had included, now with my T-Camera mods (only tested for my v1.6.2 mind you). I am looking at at least adding the OLED for the t-camera and, of course, MQTT and PIR etc.
• Oh yeah, the code from arkhipenko works on both board A and board B. So, it is definitely ESPHome that is struggling either on the t-camera or on ESP32 boards generally.

Now if all that ain’t bad enough. The boards, when loaded with ESPHome, seemed to be happiest when plugged into a powered USB hub. When plugged into a WEMOS single 18650 battery shield, they would not work or at least would not start – no matter how many times I banged on the hard reset. That is, neither of the boards would run off battery. So, I thought this was either an amperage or a noise thing. It was strange as I tested with multimeter and seemed fine. Sniffed with my DSO but noise was not an apparent problem.

The final insult then was, when loaded with original app or either the t-camera or rtos apps, both boards (A and B) ran no problem off the WEMOS battery shield. They just refused to start up or connect to wifi while running ESPHome unless they were hung off the powered USB hub. It’s inexplicable but was it worth my time to track down.

Ultimately, it turns out I mis-read the issue at ESPHome issues being “closed” meaning the fix had been incorporated into the baseline. It isn’t! You still need to dig out this nugget and manually hack your main.cpp code, avoiding the autogenerated sections. Now for whatever reason, not setting pins x=12..15 at start, with pinMode(x, INPUT_PULLUP) leads to both problems with boot loops, often aggravated if the camera code is included AND, it appears, the problem with t-camera not running or booting on battery (for whatever dang blasted reason). With pullups on those pins even board B now comes up with camera and runs off battery, despite having the ESPHome code running. There is thus a question around EMI in the design of the t-camera v1.6.2 that, luckily, can be fixed with pulling a few pins up.

Make sure then that somewhere in your autogenerate main.cpp code reads (safe to hack, lost when you clean):

void setup() {
    pinMode(12, INPUT_PULLUP);
    pinMode(13, INPUT_PULLUP);
    pinMode(14, INPUT_PULLUP);
    pinMode(15, INPUT_PULLUP);
    // ===== DO NOT EDIT ANYTHING BELOW THIS LINE =====
    // ========== AUTO GENERATED CODE BEGIN ===========

From accounts I can put together, this problem is with a few ESP32 CAM boards and was dealt with in the code by lewisxhe, which is actually where the hack for ESPHome comes from. The hack probably needs to go into ESPHome, so there is a bug report to open the problem again to have it closed in the ESPHome baseline.

Re-bombed to ESPHome, with the hack in both devices main.cpp. Fingers crossed.

So, here is the test setup running.

LilyGO TTG T-Camera no-go

So, unhappy to report no go as yet for t-cameras v1.6.2 I bought.

I am trying to set them up to use as handsfree camera doorbells, as they have a PIR sensor.

I opted, though I suspect that is some of the reason for my pain, to use ESPHome since there are already people who have configurations for these boards.

Two problems.

The first is what appears to be a bug in ESPHome. It appears hit and miss as to whether your t-camera will start if you include camera code. Not useful if you have a camera and therefore why bother with a camera. The hit and miss aspect shows up as I have two t-camera boards. One starts and one does not start, if the camera code is included. The one that starts is not perfect. To start it, for some reason, occasionally you have to keep pressing the hard reset n times (no rhyme or reason how many times) to get the flaky thing to start. Irritatingly, even when I thought it was fine once started, the board that I finally got running has now decided not to talk to the OLED. With verbose logging on, it appears to connect to the OLED but just but simply does not write to it.

I seem to be able to use one device then, as long as I don’t care about using the camera. The second device seems to work as long as I don’t care about using the OLED.

https://github.com/esphome/issues/issues/1890

Now, deploying the “working” device, ignoring the absent OLED, seemed as simple as plugging in a 18650 single battery shield, very often advertised for use with ESP32. The problem, with the t-camera running off a powered USB hub all is good (mostly). But the same t-camera refuses to start, or at least fails to connect to wifi, when powered by the 18650 shield. I checked an power appears at the pins expected at the voltages expected. So this is either an amperage thing or a noise thing. I have a DSO so I will have a poke at that, but I do know there are various versions of the 18650 shields around, so I am suspicious I have an early version that might not drive a ESP32 board.

https://github.com/lewisxhe/esp32-camera-series/issues/25

Gawd Awful!~

So, a little while ago I had ordered 5 boards based upon the ESP32 WiFi Robot design.

I actually just uploaded the Eagle Schematics to my Osh Park account.

Now I was interested in buying the parts. Apparently the BOM was in the Eagle files.

Not having Eagle, I opted to suck the files into KiCad and then use the BOM generation from there.

Don’t bother. The BOM generation tool was generating error reports across a range of BOM scripts I tried, including the file suggest by DigiKey’s Mr Smug.

In fact I was able to hang KiCad a couple to three times while trying to generate BOM from the imported file.

May have been a problem with the imported file? Maybe. Who knows?

So the $64,000 question, why did I not use Eagle to generate the BOM?

I would love to! Except …

I downloaded Eagle and tried to register. The Eagle server never did and has never actually EVER sent me a confirmation email needed to finalise a registration. What? Yes I did look in junk emails etc. Nothing. Nada. Nicht. Not a sausage.

So, I tried KiBOM download. Go figure, the change in PIP is blowing up the install. First I had come across this October 2020 fuck-up. Good one Python weeners. That’s up there with the dopey decision not to release JRE past Java 8 and then put the burden on users to build JRE to run code, given the dopey developers don’t bother providing a JRE nor a dependencies list. Yes you have tools to find out but who wants to spend every waking moment on our building JRE, to meet the range of dependencies across the multiple java apps you’ll want to run. I mean, eventually you might as well have the standard JRE, if you’ve enough java apps you’ll likely pull in a fair collection of the all likely dependencies. Eh? Yeah, I put 2 and 2 together to work out KiBOM is/was the problem in KiCAD.

So, again, no such thing as Users no more. I feel pressganged every time I want to use a open source piece of junk into getting into the internals of the tools instead of just using them.

Came across KiCost. Great, if you have a BOM from KiCAD (insert emoji for “irony” if ever someone feels compelled to craft an emoji for irony, I suspect the substitute is Mr Happy Poo).

Tried downloading KiCost from Github. Don’t bother, too many errors when installing using python setup.py install. Some were redeemable by installing missing dependencies (that should have been in the requirements.txt but were not). One did not resolve as I did install the supposed missing dependency but KiCost install kept reporting it missing. Use PyPi instead to get to documents. I might have said my bad but why have a dopey faulty github “main” version?

Just a bad smell

So, whether the procurement ages of ago of a logicsniffer was a good idea is up in the air. Looks like the version I purchased has been left behind in the firmware upgrade stakes.

Noting also, others have long reported the problems with firmware updates and there has been no fixes offered.

But I also note some of the traffic on the “help” groups is stale, old. So, may not be able to recommend the gadget, that being moot since its now a dead project.

It also looks like there is a problem with noise. You only catch it occasionally, but if you look for it it’s there.

Now this happens with the thing running, not connected to anything so leads unattached. Given its an open board, with no shielding on connectors, you might expect some noise … I suppose.

It may be dangerous to play with the prototypes of others.

HA+ESPHome no good for critical systems

Ah, actually, I think I have to go away from using ESPHome and homeassistant combination for OpenSprinklette in any event. 

No longer then interested chasing down a bug I was chasing in the HA REST API and using CURL to turn sprinklers on with a POST to switch services. I was planning to use that to be able to write a Kotlin app for an old Android tablet, since 1) I can’t get HA to open on the old version of Chrome on the tablet and 2) the HA app for Android won’t install on my old Android tablet. The bug I found sits cleanly in the REST API of HA since I am only using the examples and the POST does not work for switches or at least switches implemented using ESPHome.

The problem leading me to drop the bug in the REST API is not associated with the REST API but is because my raspingdoodleburry pi has crashed.  But, I found the ESPHome based sprinkler system has 3 of 4 relays on with the Pi crashed and not online. Even worse, as bringing the Pi and therefore HA back online does not automatically reset ESPHome device. Sure, you could set up something on HA start/restart but that does nothing for the span of time the Pi/HA is down and relays on ESPHome device on. Way too fiddly to sort all likely mishap cases. Especially, if the actual cause of the Pi/HA crash and the breakdown of HA/ESPHome communication causing the relays to come on, is unknown. So, even if the Pi/HA came back up by itself (some time after it crashed), there’d still likely be $K dollar water bills in the mail.

Having had a $3k water bill some time back, due to sprinkler system leak, I gauge it makes no sense keeping this combination of HA and ESPHome for a “mission critical” application, since I am not sure when the p p p p p Pi went d d d d down.

The evidence of a HA/ESPHome interaction problem is the relays in this HA/ESPHome version are set up in automations, to come on and turn off in sequence, with a gap in time between off and on, to avoid having to deal with sharing the water pressure. This works fine with HA up and running. So, having 3 of 4 on will be an artefact of Pi+HA crashing and likely some interaction between HA and ESPHome. That is, there are no automations in HA that would set 3 of 4 relays on at the same time and so no two relays should be on at the same based on the design of the automations. The automations have been running on a test rig and come on sunrise and sunset without a problem and the logs did, till the crash of Pi, reflect that expected behaviour.

That likely means the usual ping ponging between two user groups blaming the “other” software and, frankly, not my bag. I want to water my gardens and not solve a problem with use cases not being tested.

Not a problem, I have previously hand written code to run on the WEMOS UNO format board for the sprinkler system. That code is MQTT driven and was designed from scratch for a sprinkler system with ample safe guards. For example it wont turn on water for less than 5 mins, won’t accept more that a 15 minute request and will turn off a sprinkler after 20 minutes. It will allow a new time setting over top the old so if you want a hour of watering you just ping it with 4×15 minute requests every 15 minutes. I have a node-red setup that also will send an sms if a sprinkler node (either a 4x or 1x wemos setup) raises an LWT. I’ve even designed my own boards to support the 24VAC to WEMOS voltage conversion.

I also have a peg based parser to all setting of sprinkler times, across multiple single and quad sprinklers, via titles of google calendar events. Though, I want to decouple from google and try the same over a local mechanism for both principled and practical reasons.

So, I am also looking at how to hook my parser code into other calendar widgets. I am still to look at HA calendar widgetry, if it exists, since automations are fine but the natural thing is to just want to use even just a weekly calendar and not a full year calendar, or so I imagine I think I want to believe. Although, then node-red calendar widgetry or HA calendar widgetry? It will depend upon ease of integration.

In the end, I actually suspected my hand coded sprinkler option was likely the better approach for exactly what the crashing doodle woodle pi and the interaction between HA and ESPHome has revealed. I would even suspect the ESPHome web site, and the HA one to, have caveats and warnings about not using either for mission critical applications. Especially, if its the emergent properties of the integrations that will get you and no one is really going to arbitrate that except for the end users.

Lucky I found this problem on the test bench.

UPDATE

I poked around a bit with this, the problem is a little more insidious.

I thought the server had crashed as I could not log in with MobaXTerm. In fact, I have my server with Ethernet wire connection to a wifi extender and it turned out that the wifi extender has been dropping connection with the ASDL router. A real pain since I bought a new wifi extender BECAUSE I had the same problem with the older wifi extender AND BECAUSE the “help” on the Net suggested there was problems with the older wifi extender.

So, I found that re-connecting the wifi extender to the ASDL router saw an interesting picture. The ESPHome device must have reconnected to the HA server since the switches on the HA HMI, representing the relays in the ESPHome device, had the same state as the device. 1, 2 and 4 on, 3 off.

Not a problem you say. Well, it is since the way the system is set up is that you turn the switch on at HA HMI, and then an automation runs and turns the switch off after 15 minutes.

On top of that, that behaviour was also required when driving the relays by sunrise/sunset since a delayed trigger to turn the switch on, on sunrise/sunset, was used and the trigger to turn the switch off after 15 mins was expected then to trigger on the switch being turned on. Worked a treat while connection between HA and ESPHome device stayed up.

The problem still remained that three relays on ESPHome device were on (1,2,4) and one was off (3). Three switches on HA HMI were on (1,2,4) and one was off (3). HA log reported all switches off. So, there was a disconnect between states internally to HA somewhere.

The automations for all four switches are all triggered on sunrise/sunset. They have delays that set the individual switches on 20 minutes apart. The second set of automations, triggered by individual switches going on, turns the triggered switch off after 15 mins. So, the system works:

• sunrise->all four switches triggered with delay x mins.
• 0 mins->switch 1 on trigger switch 1 off automation
• 15 mins->switch 1 off by switch 1 off automation
• 20 mins->switch 2 on trigger switch 2 off automation
• 35 mins->switch 2 off by switch 2 off automation
• 40 mins->switch 3 on trigger switch 3 off automation
• 55 mins->switch 3 off by switch 3 off automation
• 60 mins->switch 4 on trigger switch 3 off automation
• 75 mins->switch 4 off by switch 4 off automation

Nothing really then to account for why 3 of 4 relays on, why HMI reflected ESPHome device state and then why if relays are on in ESPHome device the associated switch on in HA did not result in a switch off after 15 mins. That is, I have had the ESPHome device powered up and 3 of 4 relays have been on for two days, where they should have off after 15 mins if triggered on by HA. If I manually switch the switches at HA HMI to off today, they are then off at device. I haven’t rebooted device because I want to see if the states coherence is re-established. I assume that states will be coherent again if the automations run tonight and the relays behave properly again. Noting that that won’t redeem the setup for use in a critical applications, since it would take too much energy to understand the interplay and the problem it is actually a state coherency problem in either or both the design of HA or ESPHome or both.

So, no real way to account for 3 off, for example, since all four switches run with exactly the same automation descriptions. You would expect all four on or all four off, not a mixture.

And here we go again …

Just bracing myself for a torrent of UNHELP on homeassistant user group.

The problem, well there is a couple of problems.

Problem 1. I found the charger for my old Acer A500 android tablet so that is being set up in kitchen as web search, YouTube and Netflix gadget for cooking assistance. That means, apparently, I cannot use it for homeassistant client since a) Chrome version on A500 is too old and b) the homeassistant android app is not compatible with the version of Android running on the A500 and therefore c) see Problem 2.

Problem 2. I need to ask questions on the homeassistant user group.

Problem 3. I need to sort why the rest API works fine in all examples provided on homeassistant web site EXCEPT! for the POST that is to set the sprinklers on. When I use the POST it complains their is a non-JSON problem with the data despite the token, IP address, device id all work fine with other API calls and so that means see Problem 2.

I was able to play with the API by installing curl onto my widoze 10 laptop and then GETing and POSTing to my raspingdoodleburry pi home server running homeassistant under hypriot/docker.

Why all the bother? I will likely write a Kotlin app, for my old A500, with n buttons and POST calls to sprinkler zones to the ESP Home device via HA since HA has been set up with default sprinkler times (so you just turn the sprinkler on).

I can go to a fallback and send MQTT messages if I must, but at the moment the preference is to try to use the API. Generating a POST message in Kotlin is straight forward. The fun bit might be reading back states to make sure the sprinklers are up (so ghosting or not the buttons) and changing button colour or toggling the button on Android device by following the switch state, so as to provide an indication of ACK from device.

Putting that raspingdoodleberry Pi to good use

So, used Etcher to burn an SD with HypriotOS at:

• Version 1.11.4
• hypriotos-rpi-v1.11.4.img
• Docker 19.03.4
• kernel 4.19.75
• Dated 04.11.2019

Booted the RPI 3B+ and added docker-compose via:

• sudo apt-get update
• sudo apt-get install -y apt-transport-https
• echo "deb https://packagecloud.io/Hypriot/Schatzkiste/debian/ jessie main" | sudo tee /etc/apt/sources.list.d/hypriot.list
• sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 37BBEE3F7AD95B3F
• sudo apt-get update
• sudo apt-get install docker-compose

Grabbed my favorite MQTT setup, all grown up now, emqx with:

docker pull emqx/emqx:v3.2.7

Thence onto node-red with:

docker pull nodered/node-red

The fiddly bit seems to be to get the MQTT nodes in the node-red to connect to the emqx broker. None of the standard tricks seem to work, such as the default use of –LINK from the node-red guide on using it under docker. Hence, the downloading of docker-compose as I want to see if starting emqx and node-red via compose sorts the problem.

The problem is eclipse-mosquitto nor two or three other MQTT brokers, including emqx never see a connection from the node-red container. I tried openning up ports etc. I opted for emqx since it comes with an admin console so it is the most straight forward way to 1) see that the MQTT broker is up and 2) you have visibility of client connections if/when they are made.

Otherwise I am likely to recommend the MobaXterm as it allows me multiple sessions and session types. I can ssh into the hypriotOS or VNC onto my debian server at the same time.

I also opted for MS Visual Studio Code, since I use is for my PlatformIO dabblings. The remote explorer allows me to edit files on the RPI/OPI/BBB/C.H.I.P/ODRIOD W/ODRIOD C1/Parallella/NVIDIA Jetson Nano.

What a wanK!

So, to date. Things that don’t seem to work out of box on Raspberry Pi 3B+ hass(le)io (either 32 or 64 bit) are:

• cloud9 ide
• node-red
• portainer
• a few others that I can’t be bothered listing

Now the problem might be mine. It seems though that the setting up of the config files is trickier than it should be. This is aided and abetted by “help” files that don’t.

Idiomatically, a templated warning on many “help” files is “Don’t use this config file, write your own”. The example config in the “help” file acting, as it were, as taunt.

The problem turns out, if you cut and paste the example config files, from the “help”, many of them cause errors! They don’t, therefore, act as a example of a straight forward, no bells’n’whistles, get you started type of example.

What seems to be missing, in peoples puny attempts at “help”, is:

1. Help should not assume users have full architect status in the project, and understand not everyone has the priori knowledge of an architect OR even the plug-in developer.
2. See point 1.

Certainly, when some of the error logs are reporting potentially missing files, nested deep in the Docker image, then the fact that the Docker image is not ready for production, and shouldn’t be on the streets, is laid bare.

Some of this is the open source, the user is the tester. Or worse, the user is a developer. I know that there is a derogatory name, in the open source community, for users who don’t contribute. I admit I am one. What I marvel at is the pressure to contribute is a counter argument to the utility of open source, since if I can’t use the software due to useability, installability, understandability, portability or other software quality problems then I am not likely to be much help because of the inherent problems, generally, with open source in the areas of useability, installability, understandability, portability.

That is, if using the software is my goal, getting involved in all the open source code bases I might opt to use for my projects is not an aspiration, BECAUSE I am officially bored with the quality of open source software in terms of useability, installability, understandability, portability.

You should be too. Especially now that open source projects are whining over “pay me for my time”. YOU FREAKS! You were the types that set up the free software rort. You would have been passing floppies of stolen software around, putting companies out of business. SUCK IT UP YOU PRINCESSES!

Pardon my grumpy pants. I will actually buy a beer, if the option is there, if the software meets my expectations on useability, installability, understandability, portability. Not, however, if in the first hour I am having to debug what should be straight forward, or clearly explained.

I did managed to get the Aircast running, no changes to config needed other than, it seems, turning SSL flag to false. That was a punt I took, as the default (SSL=true) raise a error when you tried the web UI link. That “fix”, applied to the other apps above, did not fix them.

Aircast is great, since I have a C.H.I.P. running shairpoint-sync under the television. So, as chrome-cast is attached to television, I can free up a airplay speaker.

The other app that seems to run fine is motioneye, which is a CCTV monitoring thing. Same thing, came up after setting SSL=false. CCTV around the place was my next project for the home, so sweet.

The configurator works, so at least I can play with the scripting.

Otherwise, I am running the hass(le)io based RPI3B+ side by side my OPiZ.

The OPiZ is running Mosquito and node-red just fine, except for the system going down about once a month.