[<<][thermostat][>>][..]
Thu Jan 11 19:39:42 EST 2018

Embedded systems: thermostat transport

I've been fretting about this a lot.  I will need one uC board per
remote thermostat to implement USB interface, and one to make the
actuator work.

For now however, it is possible to skip the thermostats and do only
the actuator.

How do I construct a secure channel on the uC?

What about doing this without security first?  Just build the damn
relay board.

EDIT: Sat. Tired.

EDIT: Sun. Why is this so difficult?  It is all interconnect and
protocols.  A lot, for such a small task of flipping a switch.

Fundamentally, I cannot accept that communication is so expensive.
Ethernet and USB host pretty much require a Linux host.  While what I
want is something much more low level: a field bus that is easy to
implement on a uC.

Maybe that is the real challenge here?  Anyway, to get it to work, all
the elements are there:

- USB thermometers + temperv14

- Some program running on the host with the USB thermometer, sending
  events over network.

- A bridge from Ethernet -> USB

- A STM32F103 device with USB -> relay board

- Relay board connected by pig tail


Eventually, I want a shared RS485 bus running some multidrop protocol,
probably in master mode with one connection to the ethernet segment.

So let's cut it short:

- Beaglebone black connected to 5V relay board: cut out the middle
  man.  Maybe later, make an RS485 fieldbus.

- Ethernet cable running into BBB

- Erlang on BBB

GPIO?
Ok first problem is 5V/3V.

I believe it is this one, but I have seen two with different polarity.

https://www.sainsmart.com/products/4-channel-5v-relay-module
http://wiki.sunfounder.cc/index.php?title=4_Channel_5V_Relay_Module

Assuming the latter is the circuit, it has two LEDs in parallel on a
1K.  Might be the reason why 3V3 doesn't switch it, because of the
forward voltage.



It seems to work on 3V3.
5V: off
3V3: off
0V: on


It pulls 1.7mA to ground.

It glitches on startup.

https://groups.google.com/forum/#!topic/beagleboard/Kq2ftmVdugk


cd /sys/class/gpio
echo '48' >export
cd gpio48
echo '1' >value
echo 'out' >direction

Then switch with value
'0' = engaged
'1' = open


So I have furnace.sh init/on/off.
Next: glitch-free boot

Boot is not the problem.  It's the power-on.

My guess is that 3V3 comes up just a little later than 5V, which is
enough to cause the glitch.

It might not be a real problem though.  Bridging the LEDs might be
enough to make it possible to drive this thing from 3V3.  Then
separating the VCC from JD-VCC.

Forward voltage 1.25V.  Actually I can measure this.
LED 1.8V
OPto 1.1V



Beagle pins:
https://groups.google.com/forum/#!topic/beaglebone/dosKmEE7xso
source 4-6 mA
sink 8mA

Measured sink at 1mA.


Alright.  Time to hook it up.

So. Needs dedicated 100Mbit.  Port free?  eth1 is not used currently,
so maybe use that one?

Alternatively, string the actuator wire?  Too many degrees of freedom
to work with... Let's just fix some.


But... connecting it to a different power supply changed the bootup
relay current.  Is this a problem?

The real solution is to run one side on 3V3 compleltely.  Take the LED
out of the loop and tie in to the opto directly.


Next:
- find out good activation current
- pick resistor (3.3 - 1.1 = 2.2V) 
- decouple VCC
- solder directly on opto

Calculation is pretty much the same as for 5V + LED (+-1.7V)
1.7mA measured means currently there is (/ 2.2 1.7) around 1k

Optocoupler
https://www.vishay.com/docs/83522/k817p.pdf


temper-poll -f


The rest is software.  Needed:
- temperature logs
- snm

stuck?
Jan 14 23:34:44 60.8


Jan 15 00:00:53 64.3
Jan 15 00:01:53 64.3
Jan 15 00:02:54 63.7
Jan 15 00:03:54 63.4
Jan 15 00:04:55 63.3
Jan 15 00:05:55 62.9
Jan 15 00:06:55 62.6
Jan 15 00:07:56 62.5
Jan 15 00:08:56 62.2
Jan 15 00:09:56 61.9
Jan 15 00:10:57 61.5
Jan 15 00:11:57 60.8
Jan 15 00:12:57 60.8
Jan 15 00:13:58 60.8


Something is wrong here...
Maybe switch to celcius?

No it's just not very accurate. Needs calib.


Calib against reference Honeywell 588227058599663

C=58, T1=62.3  -4 (broom)
C=69, T2=72.1  -3 (zoe)


Some design constraints to make this robust.  Safety first:

- If connection to temperature sensor is lost, shut down the furnace.

- If the system crashes for any reason, shut down the furnace.

This should be possible to manage using Erlang supervisors, by
shutting down the furnace on startup, and crashing whenever any of
these exceptions occur.

The control loop aside from exceptions is very simple.

loop({temp, T},
     #{ relay    := true, 
        setpoint := {_,Max}} = State) ->
    Active = T < Max,
    maps:put(relay, Active, State);

loop({temp, T},
     #{ relay    := false, 
        setpoint := {Min,_}} = State) ->
    Active = T < Min,
    maps:put(relay, Active, State).

In a first iteration, use only a single sensor to drive.  Later,
perform the "wire or" in software.

As for security, some approaches
- HMAC + time stamps
- OpenVPN + Erlang protocol
- SSH to socket

There is no "simple" solution, so let's stick to the one that is easy
to do initially, then straightforward to generalize: distributed
erlang + openvpn.  The VPN host can be the actuator box.

For now, reuse one of the existing VPNs.

Next: get measurment from remote host into actuator host.

It seems simpler to do this by initiating from the actuator host.  A
ssh connection with fixed command would suffice.

root@beaglebone:~/.ssh# ssh -i ./temper broom
20180115-163754 63.6

Ok now everything is there.  For now, run it as root to get it
working.

- Create skeleton rebar app

- Use port tool from erl_tools to get temperature messages



[Reply][About]
[<<][thermostat][>>][..]