Java/LCDProc/LIRC?

[pmeslin]

Now that I have the watchdog sorted out (thanks again for that), I'm slowly setting up my RasPi as the ideal centralized home automation / home cinema controller with OpenRemote and a side of LIRC for transmission.

Are the guidelines and instructions for creating TCZ extensions the same on the Pi as they are for the normal x86 version of TinyCore?

I'm unfortunately not familiar with the process but curious to give it a try to make LCDProc available for PiCore 6.0.

I also don't really see any info on how to package already compiled executables; namely Java 8 for ARM (TC uses hardfloat, right?). I'd be more than happy if someone did package it (with librxtx-java).

[bmarkus]

Are the guidelines and instructions for creating TCZ extensions the same on the Pi as they are for the normal x86 version of TinyCore?

Yes.

Did you try the Java ME (Micro Edition), is it OK for you application?

[pmeslin]

Did you try the Java ME (Micro Edition), is it OK for you application?

Haven't tried Java ME yet, I'm trying to compile lcdproc for the time being and it's being difficult with libraries.

I have libftdi-dev, libftdi, libusb-dev, libusb, libX11-dev and libX11.tcz loaded, the libraries are present and accounted for but the ./configure script can't find most of them.

libusb wasn't detected until I installed pkg-config.tcz

[pmeslin]

update (can't find how to edit existing posts)

sorted out the issue with libftdi-dev, it involved modifying a copy of libftdi1.pc

changing from

Code: (libftdi1.pc) [Select]

prefix=/usr/local
exec_prefix=/usr/local/bin
libdir=/usr/local/lib
includedir=/usr/local/include/libftdi1

Name: libftdi1
Description: Library to program and control the FTDI USB controller
Requires: libusb-1.0
Version: 1.1
Libs: -L${libdir} -lftdi1
Cflags: -I${includedir}

to

Code: (libftdi.pc) [Select]

prefix=/usr/local
exec_prefix=/usr/local/bin
libdir=/usr/local/lib
includedir=/usr/local/include/lftdi1

Name: libftdi
Description: Library to program and control the FTDI USB controller
Requires: libusb-1.0
Version: 1.1
Libs: -L${libdir} -libftdi1
Cflags: -I${includedir}

Still trying to sort out the issue with libx11. TCZ extensions for that were Xorg-7.7-lib and Xorg-7.7-dev

[pmeslin]

Libs: -L${libdir} -libftdi1

late correction; the last Libs: statement should read


Libs: -L${libdir} -lftdi1


not -libftdi1

The program now compiles without fault if the drivers requiring libhid and svgalib are excluded, along with those for the logitech g15 keyboards and a few unusual others with missing 3rd-party libraries. Testing it tomorrow.

[lykkedk]

Hey...

This is looking like an awasome idea 

Could you describe, how the rpi communicates through the outside ?(relays, irtransmitter-lirc, gpio)

I googles around for finding some schmatics for controlling light, ir remotes, etc... But i find it hard to find scratch exsamples.

Do you by any chance have some good links.

Looks like openremote "likes" the RPI

RG; Jesper

[pmeslin]

To start with, it'd be mostly with USB-RS232 adapters and possibly with a lirc blaster. The whole thing is actually built in two empty 3.5" drive bays of the HTPC I'm putting together and running off taps on the 5V Standby line of the PC power supply.

I'm using a MatrixOrbital VFD with RS232 backpack.

My TV has a plain RS232 control port on the back.

My A/V receiver could use CEC but has an unpleasant design issue where, if CEC control/poweron is enabled, its 'sleep' power consumption is nearly as high as its 'on' consumption. I'll likely be going with the IR blaster for that one since it unfortunately doesn't have RS232 control. (older Onkyo, TX-SR606)

I'm building a circuit around a large microcontroller to emulate the keypad matrix of a PS3 blu-ray remote and interfacing it to the proprietary bluetooth transmitter used in said remotes. That microcontroller will talk to the RasPi through RS232 as well.

The microcontroller will also monitor the power state of the PC and mimic the power button, to turn the pc on and off.

Communication with the PC itself? Haven't decided yet. Combination of RS232 and ethernet. RS232 for sending commands to the PC (to be interpreted by EventGhost or directly by XBMC/Kodi) and ethernet for the PC to talk to the lcdproc server on the RasPi.

For expansion to full home automation, depends on which protocol and hardware I'd use for the rest of the house. There are PC/USB adapters for most of said protocols and OpenRemote works with a number off them.

[pmeslin]

Well, first step is an apparent success. Got LCDProc 0.5.7 packaged as a tcz extension, successfully tested with the LCD module I have on hand. I just have to write the documentation and it'll be sent in for evaluation. 3-4 of the LCD drivers weren't included as the libraries their compilation depend on don't seem to be available for the RasPi.


It'll probably submit the new package some time this weekend, then start working on Java 8.

[lykkedk]

Nice... I will follow this thread.

I think, as using XMBC/Kodi it would be very nice to have the RS232 switch between inputs (HDMI / coax/tv).. On my tv-set, i have to press several times on the IR-remote to switch between my inputs, which is very annoying.

I have ordred a relayboard, and some IR-led's (I allready got some ir-recievers from another project), so that i can play with differents setup, sollutions.
Regarding the RS232 ( http://www.savagehomeautomation.com/projects/raspberry-pi-installing-a-rs232-serial-port.html ),
its doable also.

I have not explored the integration with openremote yet, but surely will in future.

My former project, was a squeezelite playbox, which i use allmost everyday at home, i allready have the chance to play with lirc, which is also working fine with piCore! (Picture here :: http://forum.tinycorelinux.net/index.php/topic,17529.msg105123.html#msg105123)

Nice to have you onboard here pmeslin... keep up good work.

Rgds; Jesper.

[pmeslin]

For RS232 control to switch inputs, it obviously depends on the capabilities of the TV itself. You'd need the user manual (or perhaps the service manual) to see which commands it takes and what capacities it has. I wouldn't be surprised if on some sets the serial port was for troubleshooting/debugging only (serial console to the internal OS) rather than wired control.

Quick and dirty way to test it would be to run a serial terminal and send the commands in by hand.

I'm keeping the built-in serial port free on my RasPi and depending entirely on USB-RS232 adapters, that way if some weird electrical .up happens it might limit what hardware needs replacement. I'm also keeping that built-in port available as serial console for troubleshooting. :p

[Alexey]

pmeslin hello there!

Glad to see the LCD driver is working for you.

I also have an LCD module (3.5″ Tontec TFT, model “MZ61581-PI-EXT 2014.12.28″), but have no idea of how to get it working on PiCore...

Is your LCD working at the boot screen? How about touch driver?..

[pmeslin]

Hi Alexey,

What I have working is a completely different beast, a 20x2 character LCD. No touchscreen or graphics or anything of the sort. Can't be used as a bootscreen to the best of my knowledge.

From what I can find around, your LCD module is a graphical TFT screen that connects over the SPI bus. Some work has been done on writing a custom framebuffer module (fbtft) to use it on the RasPi but it needs a custom kernel.

I don't know if said updated module is present in the current 3.16 used in piCore (or the 3.18.something that's being worked on) but it's not the kind of display LCDProc is meant for, sorry.

Here's what I could find:
http://cooljc.me.uk/?page_id=14
http://cooljc.me.uk/?p=64

[gavinmc42]

What about making a uart LCD.
Use a small micro with uart input, sending console serial port stuff to LCD.
Probably best to use graphical display 128x64?

4D systems make some displays that take uart input.
I have used their framebuffer/touch screen 3.5" version but only on Raspbian.

[pmeslin]

What about making a uart LCD.
Use a small micro with uart input, sending console serial port stuff to LCD.
Probably best to use graphical display 128x64?

4D systems make some displays that take uart input.
I have used their framebuffer/touch screen 3.5" version but only on Raspbian.

Possible, but still not in the scope of lcdproc. There IS a lcdproc plugin (lcdvc) allowing use of the LCD as a console screen, but obviously that wouldn't work for early console stuff (aka before lcdproc starts & gets loaded) and a largeish screen is recommended. Some of the graphic lcd drivers are missing from my compile of lcdproc since I didn't manage to hunt down an ARMv7 version of some of the required libraries and didn't have a need for said lcd drivers.

Here are the drivers that are included in my compile; use http://www.lcdproc.org/hardware.php3 for reference.
bayrad
CFontz
CFontzPacket
curses
CwLnx
ea65
EyeboxOne
glk
hd44780
i2500vfd
icp_a106
imon
imonlcd
IOWarrior
lb216
lcdm001
lcterm
lis
MD8800
ms6931
mtc_s16209x
MtxOrb
NoritakeVFD
picolcd
pyramid
rawserial
sdeclcd
sed1330
sed1520
serialPOS
serialVFD
shuttleVFD
sli
stv5730
SureElec
t6963
text
tyan
ula200
vlsys_m428

and the ones that are missing;
g15--------------- (no g15daemon & g15tools for piCore)
glcdlib------------ (no graphlcd library for piCore)
glcd
irman
irtrans------------ (needs IRTrans irserver package)
joy
lirc----------------- (needs lirc)
mdm166a-------- (needs libhid, couldn't find for piCore)
mx5000---------- (needs mx5000tools)
svga-------------- (needs libsvga)
xosd-------------- (needs libxosd)

[pmeslin]

Almost done packaging LCDProc after work-related delay.

I'm trying to sort out some mildly annoying scripting issues right now. (Bear in mind I'm more or less a novice as far as linux scripting goes)

As it stands, I am attempting in the tce.installed script for the package to copy/overwrite the user-customized LCDproc configurations files (LCDd.conf, lcdproc.conf, etc.) to the folder where LCDproc expects them to be or use the standard 'sample' files in their absence (and leave a note in the kernel message buffer indicating which version is used; that part works fine). For the time being, the script only ever sees the sample files when it runs during boot but works a-ok when run manually from the command line after booting has completed.

From what I understand and what I can observe, as far as the TinyCore boot sequence goes, the .tcz packages are loaded and their tce.installed scripts executed before the data backup (from /opt/.filetool.lst) is restored, correct?

Any recommendations or guidelines on how to delay execution of some of the tce.installed scripts until after the data backup is restored? I guess I could also stick the user-customized configuration files in a static folder but that seems pretty kludgy. The other option that comes to mind would be to use the 'sample' configuration files by default and use a backup of /usr/local/etc/(reqd. files) to overwrite them.