Talk about Big Brother!

No not that crass one, the ominous one.

Figure 1

So in Figure 1 there’s a pile of old Android phones I have collected. Including my trusty Galaxy SII that was used to provide vision to my robot hacks.

I found a not bad IP camera front end called motionEye. Popped the docker container for motionEye onto the Raspingdoodlebury Pi 3 my house is running on.

Phones are running different versions of IP Webcam app. Different since the oldest phones are running Android … what for it … 2.2! So I am using latest drop of 2016 versions for those older phones. They may run 2017? Don’t care at the moment, as it was a laborious trial and error downloaded and trying to find a version that would install.

The motionEye front end has quirks. Firstly, I think it expects a camera once set up is, well, up. If you turn the phone off, or leave the screen lock on (an you haven’t told the IP Camera app to run in the background), motionEye doesn’t seem to want to keep the camera up on the screen. Most times you can just refresh the browser you’re watching on. BUT, and there’s always a but, there’s a fair to middling chance that you have to delete the camera from motionEye and then re-add it?!?!?!

Also have an S8 that I bought when my A8 charging connection started to play up. I ended up sorting (really tolerating) a dodgy connection that seems to evolve, because of the crap design. So I am still using my A8. I have ordered a sim card for the S8 to set the S8 up as another IP Camera, but also to host a REST based SMS gateway, so I can send messages from the house server to my phone, and hopefully also from the phone then to the house server, when I am away from the house.

I am hacking up a simple app, to work on my A8, to tell the house server I am on the LAN so please don’t send me pesty SMS messages etc. That might actually also be possible by using the presence of the HA app on my phone to work that magic. I need to poke around with the available flag I of the associated entity I supposed. So, a few fun weeks of HA configuration, again.

The downside, is the Home Assistant integration for motionEye, happily leads to camera entities automatically being recognised BUT the fracking things are always UNAVAILABLE! Not a lot of help sorting that, it seems you have to jump into ADVANCED mode to setup a simple MJPEG IP Camera?!?!?!?

UPDATE

Solved. When setting up the camera in MotionEYE, if you use the Network Camera and not the simple MJPEG option, then HA can “see” the camera. A bit dopey, since the difference is explained as “if you dunna want motion detection”, that read as “if’n yawl only wants to use the video stream”. Odd then that you don’t get the video stream if’n yawl only wants to use the video stream.

Note, if you’re using MotionEYE on the same host as HA, and you’ve crafted up a docker-compose file to run up the server, you can certainly set up the MotionEYE integration with ” http://motioneye:8765 “, if you set your MotionEYE container to … err … “motioneye” that is.

It also work backwards. That is, your webhooks, from MotionEYE back to HA, can be ” http://home-assistant:8123/api/webhook/etc ” for example.

I also worked out also that, if you are using the webhooks in MotionEYE, to call automations on HA, if not using the container name, you’ll need the real IP address of your HA host in the URL. That is “x.x.x.x” and not “black-pearl.local”, as MotionEYE appears not smart enough to use that idiom.

Gotta love docker right?!

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.

Oh the pain

Trying to get Clicksend integrated with Home Assistant appeared to be easier, once you find all the goss, but its finding the goss.

The clicksend config is at Home Assistant site. Straight forward enough.

To set up an action the trick turned out to be use a “Call Service” with:

alias: ''
data:
message: Zone 1 turned on
service: notify.clicksend

Now the hint was at the Clicksend integration page for Home Assistant. That it, it was a service call.

That pieced together something for me that didn’t stand out from the mess of help at Home Assistant. That is:

notify:
   - platform: clicksend
     name: ClickSend
     username: CLICKSEND_USERNAME
     api_key: CLICKSEND_API_KEY
     recipient: PHONE_NO 

Leads to a service call, in the actions and likely scripts, of:

notify.clicksend

Makes eminent sense.