Pure Java library for Telldus

[jstrom]

Hello!

I've just implemented a pure java library for talking to telldusd. It is available at https://github.com/stromnet/jtelldus. The README describes what it can and cannot do.

The background of implementing it was that I don't really like the idea of having native-libraries (which the current binding is, a wrapper around the native C lib), if I can get away with writing it in pure code. Since the only thing it does is talking over the network in a non-speed-sensitive way, I cannot really see any reason to NOT write it in pure code. The only thing would be maintenance overhead, but the wrapper would still need updates if the librarie gets more functions etc.

The only quirk right now is that telldusd uses UNIX sockets... Would there be any chance of changing this/complementing with TCP sockets in the future? As java doesn't do UNIX sockets natively (not portable), I have to rely on socat for 'bridging' the sockets (more on that in github README). Not the perfect solution but..

Any input is welcome, (but please read the README first;))!

Johan

[gein]

Kul! openHAB ser spännande ut också. Jobbade ett par år med OSGi så jag har ganska stor erfarenhet därifrån faktiskt.

[micke.prag]

http://developer.telldus.com/blog/2012/ ... developers

[jstrom]

Micke, trevligt!

Ang socket-dilemmat, hur ser ni på att göra sockets konfigurerbara istället? Default kör dom som nu (för dom som inte orkar pilla), men i configfil skulle man kunna speca host/port att lyssna på om man vill köra med vanliga TCP-sockets istället.

Edit: forkade repot och gjorde precis en commit som tillåter socket-config:

https://github.com/stromnet/telldus/com ... d32f49d2d4

Funkar på UNIX. Windows, nej, då jag inte har någon socket-kod där. OS X däremot är jag osäker på, då getSetting() där verkar returnera "" om jag tolkar koden rätt. Dvs, finns ej heller stöd för defaults, vilket leder till att sockets ej kommer funka öht.

Ej heller stöd i Socket::connect (som används av tdtool) ännu, finns ju ingen naturlig väg för att speca host/port där så får klura på den.

Några tankar kring det?

Mvh
Johan

[micke.prag]

Vi är helt ok med att göra sockets konfigurerbara. Tyvärr är det inget vi har möjlighet att prioritera någon tid på för närvarande. Så det får implementeras av "communityt".

Om vi ska acceptera koden behöver följande kriterier var uppfyllda:
- Fungera på Windows, Linux & Mac OS X
- Inte dra in ytterligare dependencies, d.v.s. det ska enkelt gå att köra även i embedded Linux
- Inte bryta bakåtkompabilitet eller "binary compability". D.v.s. telldus-core måste även anpassas att automatiskt använda dom nya socketarna.

[jstrom]

Okey, låter bra!

Skulle nått sånt här vara OK?
- Om setting finns, används det enl så som jag gjorde i min commit (fil eller TCP om den börjar med tcp://)
- Om setting saknas, fallbackar det på dom gamla UNIX-socketarna
- För telldus-core (client) skapar jag en tdInit2(char *event, char *client) eller likn som ansluter till angivna sockets ist för en blank klient.
- tdtool får extra commandline-option för att ange socket

Med ovan ändringar bör ingen bakåtkompabilitet förstöras.
Hur ser det ut med OSX-settings, är dom fullt implementerade? Blev lite fundersam då tex getSetting() returnerar "". Hur hanteras defaults tex?

Ang Windows, har ingen miljö för att utveckla i windows, och mina socket-kunskaper i windows är väldans föråldrade.. Så där får ev nån annan pitcha in isf.

[micke.prag]

Vore det inte bättre om tdtool automatiskt väljer rätt sockets beroende på vad som står i tellstick-conf?
D.v.s. att alla tredjepartsapplikationer automatiskt fortsätter fungera.

Hur ser det ut med OSX-settings, är dom fullt implementerade? Blev lite fundersam då tex getSetting() returnerar "". Hur hanteras defaults tex?

Detta är nog inte implementerat då vi inte haft någon inställning att hämta på den plattformen.

Ang Windows, har ingen miljö för att utveckla i windows, och mina socket-kunskaper i windows är väldans föråldrade.. Så där får ev nån annan pitcha in isf.

Viss socket-hantering kommer vi bygga in iom ticket 114 avslutas. När vet jag inte ännu.

[jstrom]

Vore det inte bättre om tdtool automatiskt väljer rätt sockets beroende på vad som står i tellstick-conf?
D.v.s. att alla tredjepartsapplikationer automatiskt fortsätter fungera.

Jo, absolut, det kan man ju lägga in också, tror dock inte tdtool tittar alls på config idag? Och settings-bitarna ligger ju i server, inte i client, så blir ett rätt stort ingrepp att flytta till common/åter-implementera för client. Men absolut rätt väg.

Hur ser det ut med OSX-settings, är dom fullt implementerade? Blev lite fundersam då tex getSetting() returnerar "". Hur hanteras defaults tex?

Detta är nog inte implementerat då vi inte haft någon inställning att hämta på den plattformen.

Okey.

Viss socket-hantering kommer vi bygga in iom ticket 114 avslutas. När vet jag inte ännu.

Hmhm, okey. Tolkar dock det där som att det är mer ett interface mellan .Net och telldusd ("it will be possible to use the device as a TellStick Duo")? Kanske missförstår dock, har inte lusläst hela tråden.
Ang UDP, hur skulle man göra med events? Skicka ut på en broadcast-socket, eller skall klienten ansluta sig och "registrera" sig för mottagning av events på nått vänster (så den vet var den skall skicka udp-events)?

[micke.prag]

Eventsen gör nog bäst som broadcast. TellStick Net broadcastar events och sen kan en eller flera datorer lyssna på nätverket.

[jstrom]

Eventsen gör nog bäst som broadcast. TellStick Net broadcastar events och sen kan en eller flera datorer lyssna på nätverket.

Enda nackdelen är ju att man låser sig till ett broadcast-domän då.. För de flesta hemnäten är väl det dock helt OK!

Nu har jag ingen koll på .Net alls, men.. av ren nyfikenhet: finns det planer på att kunna koppla ihop en .Net till sin centrala telldusd? Så man tex kan sprida ut flera .Net om man har en större yta att täcka, och styra allt ifrån en och samma centrala telldusd?

[micke.prag]

Det är precis vad ticket 114 handlar om. Att göra TellStick Net (pettetesser, men ingen punkt innnan Net) kompatibel med TellStick och TellStick Duo. D.v.s. att du ska kunna blanda som du vill.
Ticket 108 har redan implementationen för att kunna knyta en viss device till rätt "controller" (TellStick).

[micke.prag]

Enda nackdelen är ju att man låser sig till ett broadcast-domän då.. För de flesta hemnäten är väl det dock helt OK!

Har man mer krav finns numera källkoden till firmwaren öppen så det går att själv implementera det på annat sätt om någon är intresserad.
http://developer.telldus.com/blog/2012/ ... n-firmware

[jstrom]

Sådära, nu har jag fått lite mer tid över..

Nu är TCP-stöd i klientlibbet commitat (https://github.com/stromnet/telldus/com ... a254f5a1a4).
Det krävde lite förändringar i koden (läs commitmsg), men för användare av libbet så finns det en ny funktion, tdInitWithSocketSpec(char* clientSocket, char* eventSocket), som kan användas för att initiera libbet för att köra mot en specifik socket ist. tdInit() finns fortfarande och sätter då upp libbet mot default-sockets.
Inget stöd för att läsa settings dock, nuvarande koden är ju så tied till service-biten så vill inte börja copypasta in dublett-kod på klientsidan, isf bör det nog refactoras till common först.
Notera att tdInitWithSocketSpec endast exponeras i UNIX-varianten, i Windows-libbet har jag dolt den då bakomliggande kod saknas f.n.

tdtool har en ny parameter --socket, som kan användas för att speca Client-socket. Då event-socket ej används av tdtool saknas en sådan parameter.

Även stöd för att ladda defaults i CF-settings (https://github.com/stromnet/telldus/com ... 6d30c7c76f), så nu funkar koden på OSX igen, iaf med default-sockets. Har däremot inte hittat något sätt att skriva till CF-preferences i kCFPreferencesAnyUser-domänet. Inställningarna sparas ju i /Library/Preferences/com.telldus.core.plist, men lyckas inte få 'defaults'-verktyget att skriva/läsa därifrån.. Men en fuling funkar:

Code: Select all

defaults write com.telldus.core clientSocket tcp://0.0.0.0:9998
defaults write com.telldus.core eventSocket tcp://0.0.0.0:9999
sudo cp ~/Library/Preferences/com.telldus.core.plist /Library/Preferences/

Alltså, skriver värdena till lokala userns pref, och sen kopierar dom till globala. Med detta funkar TCP-sockets fint på OSX också, ex nedan med nya tdtool-parametern socket:

Code: Select all

$ ./tdtool/tdtool --socket tcp://0.0.0.0:9998 --list 
Number of devices: 1
1	TELLDUSTEST	OFF

4 funderingar:
* Hur gör man snyggast för att client-lib skall kunna läsa ut settings?
* Hur gör man snyggast för att man skall kunna göra extern config på OS X?
* Vad tyckts om interna förändringarna i Client?
* Någon som är sugen på att ta sig an Windows-bitarna? Jag har tyvärr ingen Windows-miljö att utveckla i, så det är nog inte så troligt att jag kan ordna det.


Glad påsk!

[micke.prag]

* Hur gör man snyggast för att client-lib skall kunna läsa ut settings?

Lägga klassen Settings i Common? Då delas den av både service och klient.

[jstrom]

* Hur gör man snyggast för att client-lib skall kunna läsa ut settings?

Lägga klassen Settings i Common? Då delas den av både service och klient.

Jao precis, som jag nämnde. Dock känns det som det är mycket service-specifika saker i settings-libbet.. Iofs inget som exponeras i APIet ändå, så kanske inte gör nånting?