Archive for the Orange Pi Category

Niggly

Posted in Embedded, MQTT, NodeMCU, OpenSprinklette, Orange Pi on August 16, 2017 by asteriondaedalus

I may have some more design work for the opensprinklette node-red implementation.

The nuance is that the google calendar node will happily trigger on event edges but the triggered response seems to be a dump of the calendar event parameters but not the edge that triggered the node.

It might be as simple as another parameter on the configurator to tell it whether it is for sprinklers on or off

The other might be using the before event.

Have two outputs then to act as start and stop.  Feed the stop into a timed node.

Either lapsed or absolute is another question.

Much of this is trying to think in a dataflow rather than an imperative idiom.

I want to think also about ACK from the WeMOS sectors. That might want a watchdog timer.

The lwt from the WeMOS sector will need a response. Although any sector/zone on, while WeMOS is down, falls on deaf ears.  Stil, it needs to be logged and reported.

Advertisements

Back to work

Posted in ESP8266, Lua, MQTT, node-red, OpenSprinklette, Orange Pi, WEMOS D1 R2 on August 5, 2017 by asteriondaedalus

So, at last, now that the OPiZ setup saga is over (fingers crossed) we begin over.

I built a new nodemcu firmware for the WeMOS to include:

  • bit
  • end user setup
  • file
  • GPIO
  • MQTT
  • net
  • node
  • RTC Time
  • SNTP
  • timer
  • UART
  • Wifi

A few coding snippets later and  the WeMOS can catch the mqtt topic running on the OPiZ feed by the node-red on the OPiZ.

wemos

So, I can now parcel up the OPiZ as the house server and tidy up the sprinkler system.

I did note that the WeMOS did not come up first time I bombed the firmware.  That was sorted (it seemed) by selection the 4MB Flash option on ESP8266Flasher.  The ESP-12E on the WeMOS has a 4MB flash and I noted that there is a branch of the nodemcu frozen in time now for the 512kB chips – so go with the master branch if you have the WeMOS D1 R2.

I did also manage to break a hoodoo now that nodemcu does away with autoconnect for the MQTT.  The timer callback scheme works a treat.  I can reboot the OPiZ and the WeMOS will reconnect once emqttd is up and running again.  Of course, I have a LWT setup so that the emqttd server will tell the node-red if the WeMOS drops off the channel.

This is getting exciting now.

So far so good

Posted in MQTT, node-red, Orange Pi, Python RULES! on August 2, 2017 by asteriondaedalus

OPiZ is still up.  So I have avoided the hiccup of ethernet dropping out somehow.  I am always queasy when the problem just “disappears” but small mercies right?

The only thing that I noted was that, when the system has dropped its ethernet, I have not had a console connected.  So I have shut down the TeraTerm session, that was watching the memory usage, and left the device running now with the node-red and python test harnesses running.

We may be good now.   I hope I have properly documented the steps I went through.

Winter chill.

Posted in Linux, ODROID-C1, Orange Pi on July 30, 2017 by asteriondaedalus

So far so good.

OPiZ has run for 12 odd hours with temp reporting, node-red and emqttd up status running on OPiZ, emqttd up status running on PC and PC pinging OPiZ.

I note that, because this is winter, and we snuggle under a couple of doonas during the night, heating in the house is off.

That meant the temp of the OPiZ dropped to 59degreeC from the 62degreeC it peaked at yesterday.

I note also that the memory watch I ran on the OPiZ via TeraTerm was fine.  The free memory was oscillating around the same value that it was around 12 hours ago.

So, who knows, is it a temperature related thing that causes the ethernet to drop its connection?

Odd that there are complaints on the net about heat problems with the OPiZ, the OPi series in fact, but they don’t bother to 1) provide heatsink with the devices 2) tune the device to run slower out of box since that will drive the operating temperature down and because there is no heatsink provided.

Mind you, I have also found 6x6mm Peltier coolers so who know how silly this could get.

Or, I guess, play with a jar of mineral (baby) oil.

The server needs to provide Mission Critical level functions for running the house.  So it stands to reason that either I get this sorted or drop the OPiZ and go back to ODROID-C1.

So hot!

Posted in Orange Pi on July 30, 2017 by asteriondaedalus

I stuffed the following into a node-red exec node:

cat /sys/devices/virtual/thermal/thermal_zone0/temp

Every minute I will now get a temp reading of my OPiZ to my node-red console.

At the moment the temperature of the OPiZ is running at about 61degreesC.

From chatter on the net this is hot but not a problem – but I will be taking delivery of heat sinks later in the week so that should see the temp drop somewhat.

Fine while the OPiZ stays running but it will keep a record of the temp and the round about time the thing stops.

I have a python based mqtt client listening on my PC for a topic set by node-red on the OPiZ.

I also have another python script on my PC pinging the OPiZ periodically to try to catch the time it drops off the ethernet.

Now even if the ethernet drops out I will still need parse the logs to see if the chip reset due to heat or was turning off devices due to heat.

I am also running the following, to monitor memory usage, on the Tera Term connection (3-pin serial):

sudo watch -n 1 vmstat -s

In any event, I have ample instruments to monitor the system to try to give hints at the behaviour (at least) of the ethernet drop outs that I have been seeing.

In the meantime I started poking around to try to work out how to get control of the CPU clocking as I might need turn down the clock speed to try to keep the OPiZ cooler – if that turns out  to be the problem.

Keeping an open mind in any event until I get some hints.

Thrashing by reboot a success

Posted in Linux, Orange Pi on July 29, 2017 by asteriondaedalus

So, I have left the OPiZ running for 24 hours, node-red and emqttd running, and rebooting every 5 minutes.

All is running.

So why the dropout of the system previously?

Now the experiment will be to remove the 5 minute reboot, just leave it running and either ping from my PC via a python app or set up a pass-through topic on emqttd to test for the OPiZ server being up.

The dropping of ethernet may be related to how long the system has been running.

It could end up a design problem, the OPiZ 2 has dropped ethernet.  I might yet have to relent and go to wifi – though this would be 1) against principle and 2) against the design I have set for my set up.

I do note one mention on internet of heat related problems with OPiZ and the ethernet.  So, in the meantime I am going to order me a gaggle of heatsinks.

Do di do di do di DOH~!

Posted in Linux, Orange Pi on July 29, 2017 by asteriondaedalus

So, yep, sure enough, I came back to the OPiZ and could not connect.

As I have the 3-pin serial connected I snuck a look and yep … route naught.

I rebooted, setup emqttd as a service, re-started the cyclic reboot task in node-red.

I will let that run a few days then I will have to try something else to work out when and why the lan connection is dying.

This is on a new Orange Pi Zero board that hasn’t had an expansion board inserted, and it is running the orangepi.org headless debian server.

I still can’t fathom how the difference between ethernet connection persisting and then being dropped procedurally is the installation of erlang/elixir/emqttd.

Worst case, I guess I can install Mosquitto.

Still, I cannot see the mechanism.