Vim and T.B. in Home automation

Hi all,
My current interest is around home automation using node-red and Arm soc based media centers running open source platforms.

Has anyone used khadas products in those areas ?
Please share your experience.
Tks.

1 Like

Can you explain in detail the whole plan for home automation and media center?

Yes, the plan is to have a low consumption and low heat device running node-red 24/7 (reboot once a week maybe) that monitors my sensors and runs my home automation routines on actuators ( screen , speakers, lights, etc…) and can possibly also double as a media player as well as act as an in house media server

2 Likes

Hi,
about 2 years ago have launched production of a professional automation controller called UFK080808 using Khadas VIM1 running Ubuntu as the brain. Hundreds of them in use today, mostly in Estonia. Reliability is decent, uptimes more than a year are well possible. Having previously struggled with low reliability of RPI-type of devices, I’m very happy with Khadas.

What differentiates this controller from the rest of industrial Linux-controllers, is the bias on Modbus. Not only the RS485- or LAN-extensions, but also the internal IO (8AI, 8DI, 8DO, onewire) is Modbus-based, avoiding sensitive and sometimes tricky GPIO.

IO is on a separate PCB, connected with Khadas via UART. The same PCB ensures 5V power to Khadas. All IO channels and bus interfaces are well protected, IEEE tests for home&office and industrial environment passed. Both PCBs fit into standard DIN-rail mountable box from Camdenboss. Thanks to this modular approach, just the IO-card in the same box is the IO-extension.

The software is written in Python3, using tornado and pymodbus. Sqlite3 for configuration (ModbusTCP, ModbusRTU, Mbus and WMbus channels are covered in the basic channel configuration).
Have had thoughts about using Node-Red to generate configuration and program flow for Python (to utilize the loads of work already done), but no real results in this area - copy and modify has been easier so far.

6 Likes

Hello, Very nice and professional looking unit. Impressive.

I ve found this


Let me look at the details…
We have the correct photo there but the text is mentioning Olinuxino iMX233 probably an ancestor…
Please provide some updated datasheet.

And how would you do it differently, in 2021, if you have to ?

1 Like

Yes, Olinuxino was the ancestor, not powerful and reliable enough (low memory, the Broadcom chip to share USB and Ethernet and SD-card were the main limiting factors). See the actual data (skipping Khadas parameters) below:

I/O-channels
• 8 channels of sourcing discrete outputs (DO)

  • voltage rating up to 45VDC;
  • load current up to 700 mA per channel
  • configurable power-on output level;
  • single pulse output, pulse length from 0.25ms to 65 s;
  • periodic pulse output, period from 1 ms to 65 s, in 1, 2 or 4 phases (phase settable per output channel).
    • 8 channels of discrete inputs (DI)
  • individually settable to active high or low;
  • 4 inputs usable for up to two Wiegand (26 bit max) readers;
  • 32 bit counter on every input,
  • maximum allowed input voltage 27V.
    • 8 universal channels (AI/DI), individually settable to
  • 12-bit analogue input 0…2V/0…4V/0…5V/0…10V or 0…20mA,
    with comparators with 2 bit output and 3 (shared for all AI channels) threshold levels;
  • discrete input low or high active;
    Maximum allowed input voltage is 27V.

Dimensions
• 106 x 91 x 59 mm (width 6 modules)
• DIN rail mountable case

Power supply
• Supply voltage 1 (to power internal circuits, load depends on voltage, about 200mA@12V): 7…27V DC
• Supply voltage input 2 (to power digital outputs, max 700mA load per channel, protected): 12…45V DC
• 5V 500 mA protected output to power external devices (this load increases the supply 1 current consumption)

Communication Interfaces
• RJ45 Ethernet 10/100BaseT interface;
• RS485 interface with ModbusRTU support (with speeds from 9600 to 115200 bps, no or even parity);
• OneWire interface for up to nine DS18B20 temperature sensors, with optional address fixation;
• Wiegand protocol support for 2 readers (on 4 DI channels)

The IO-board, with its first version from 2013, has a PIC18F46K80 microcontroller. If I would start develop a new IO-board today, I would probably use a PSoC 5LP chip, still keeping the ModbusRTU UART channel to Khadas and RS485 to other Modbus slaves.

From the other properties - Wiegand interface seems a bit less important today, could be skipped perhaps. And the number of supported onewire temperature sensors could be higher - 50 would be nice. Btw, the optional address fixation mentioned in the data above means that I can freeze the sensor addresses into Modbus registers after successful autodiscovery. This way the loss/failure of a single sensor does not mess up the order (and the register locations) of other sensors on the next power break.

The most useful properties (other than usual AI/DI/DO) have probably been the abilities to generate a precise single pulse or set periodic pulse output (PWM signal), via single modbus query.

Another nice thing is the ability to read all 8 AI channels as comparator outputs from one Modbus register. Sometimes the actual AI value is less important than the voltage range the input value falls in.

2 Likes

Maybe @tsangyoujun can help to post on our socials media.

A bit old commented picture of the IO board, with optional Lantronics Xport Ethernet module. Today there is a place for USR K7 instead of Xport, with built-in ModbusTCP/RTU conversion. This Ethernet module is not installed for usage inside the controller together with Khadas. But it helps to connect remote IO-extensions with the controller over the existing LAN. Polling ModbusTCP connected extensions can happen in parallel, being therefore faster. Every TCP node can be a TCP/RTU GW for other RTU extensions.

2 Likes

Isn’t modbus a bit old fashioned and becoming obsolete in the era of ultra fast serial buses like USB, a2b, gigabit HomePlug AV2, HDBaseT, etc…and not to say gigabit WiFi.
? And tornado/python could be replaced with more modern nodejs…

1 Like

It’s far too early to bury Modbus. In about 90% of my installations Modbus is needed (for energy meters or PV inverters mostly). My development has been targeting the everyday needs, not the edge of possible. As Modbus was a necessity anyway, it was chosen to be the communication protocol for the extensions as well.

Related to software preferences - everybody is free to use whatever software he likes, on top of Linux or Android thanks to Khadas usage. I can be the most productive in Python today.

1 Like

I just do not see any server nor sensor nor actuator of interest for my use case at home and which would only be available with a modbus interface. All my connected devices are on 2.4GHz ( ZigBee or BLE or WiFi) at the moment.

Well, use cases are different. WiFi and BT are built into Khadas. Other radios are available via USB dongles.
According to my experience, wired connectivity solutions are always more reliable than wireless though.

But I may be biased to industrial automation after all. The individual home owners often have very different views on what the home automation should offer and what it should cost… Less of these issues with industrial customers, where automation outcome can be more clearly converted to savings. Therefore most of our customers are infrastructure companies, like water treatment or apartment building maintenance related. Energy consumption control is also a fast growing business segment, where load shifting helps to lower energy costs and supports the healthy power balance in the grid.

@ravelo
Khadas vim3 should work perfectly fine as well as odroid. limited edition.N2BLUE2-e1606721631216
https://www.hardkernel.com/shop/odroid-n2-home-assistant-blue-bundle-limited-edition/

1 Like

Nice find, the question is now : is the piece of cake big enough and would Khadas want to compete for a par of it ?


seems to present a fully integrated solution including the board, the case and te whole software stack : from kernel up to app level