Connecting to stand alone kit. such as a TP-Link Wi-Fi bulb

[RichardC]

Hi All,

Running W10 on a Windows 10 LTSC (Long-Term Servicing Channel) version. (old LTSB)

For a house that has every ceiling light controlled automatically. We've still got a few lamps that are stand alone and the missus has put on timers to come on at dusk, these are needing to be changed every few months. So this got me thinking if I could bridge in a non-cloud way to this lighting from the Idratek PC. I see that there is some Philips hue lighting support, but seeing that they're just about to brick the old hub, not sure if Cortex will work with the new one so find this all rather bizarre.

But was possibly thinking of going a little bit more divergent. I already have several PLC's controlling fish pond and a couple of new ones soon for the cat flap (rfid reading) and water harvesting. So was thinking of using some software such as openHAB. This will run on a Pi, it knows xPL to talk with Cortex, modbus to talk to the PLC's and PV array also the TP-Link KL60 E27 Wi-Fi Bulb that I've got in mind. This can be added onto the network without having to get the cloud involved as there is a way to use the app without logging onto the central server to add the lamp to the local wi-fi.

additionally later on I can add amplifier control and other things.

Any ideas please?

Thanks

Richard

[Karam]

There are always potential problems with 3rd party stuff even if you have so called 'open' architectures. Unless you have a dedicated operation to address everyone else's changes (if doable) you end up losing functionality you had relied on at some point. Some past examples for us - Skype API, HomeEasy, Philips Hue (last change accomodated I believe), Gmail (now accomodated).

Devices which have an 'open' web API in principle you may have more luck with if they are acting as relatively dumb devices such as just controlling on/off state since you might then be able to implement crude integration purely using the Cortex Web API client and update any future syntax changes yourself. But if it involves more complex integration then likely we'd have to have a dedicated object (as per Hue) and then we would have to try and keep up with changes. As you might imagine not so attractive for us to do this for many devices.

There are a number of devices on the market with a WiFI interface which could probably be coaxed into communication via the Cortex Web API client/server functions - I'm thinking of the likes of Sonoff and similar ilk, but probably better done with your own reflashed code so maybe not for the average user.

Of course, as you suggest, you could also go via other pieces of software which might already have the necessary interfaces to a wider variety of hardware.

The main problem as ever with odd bod additions, aside from continuous maintenance effort, is proper integration vs just switching something on and off and having to write reams of logic yourself whilst trying not to tie yourself up in contradictory knots - especially once you start scaling up the number of devices and functions. It just gets messy and difficult to manage. This was the whole raison d'etre of the IDRATEK system from day 1... I.e it's not simply about being able to send and receive information to/from some arbitrary hardware but rather about what you do with the whole.

Another solution which might satisfy some of your requirements is of course for us to have further native hardware options.The good news, I might as well divulge, is that we have been working on some WiFi modules, or perhaps better described as WiFi platform, over the last few months. Presently embodied in two small module prototypes (SBR-W01 is a kind of mix between SRH, PLH and ADC (mains powered), and LTH-W01 is similar to the original namesake but also with an ADC channel (viable on battery power under some acceptable sampling constraints). Why these have not been released yet is that whilst it's easy to make the hardware and provide a basic Web or App interface it is quite a bit more work to integrate into our overall system in a way which requires least disruption to existing structures and methodologies.

[pbj]

Hi Richard,

I've cobbled a couple of sonoff type devices flashed with tasmota into our Idratek set up. I'm not a great fan of WiFi, it's never super reliable in our house despite my attempt to add access points, however for these devices I couldn't be bothered to run a cable.

Initial "integration" was using the cortex API function (as Karam says workable but clunky for more complex devices). I've just upgraded by writing a simple xAP to MQTT bridge which makes configuration on the cortex end much cleaner. Again as Karam notes still not ideal as there's no retry logic as it's harder for cortex to know whether the action has been successful. I guess I could achieve something similar using current sensing sonoff devices and the verifier object if I really want to (along with upping the QoS on the MQTT topic).

Peter

[cliffwright]

The good news, I might as well divulge, is that we have been working on some WiFi modules, or perhaps better described as WiFi platform, over the last few months. Presently embodied in two small module prototypes (SBR-W01 is a kind of mix between SRH, PLH and ADC (mains powered), and LTH-W01 is similar to the original namesake but also with an ADC channel (viable on battery power under some acceptable sampling constraints). Why these have not been released yet is that whilst it's easy to make the hardware and provide a basic Web or App interface it is quite a bit more work to integrate into our overall system in a way which requires least disruption to existing structures and methodologies.

Interested in seeing Wifi modules for sure. Retro fitting in some areas for me is impossible without such mess that it's just not worth it.

Just to add, Wifi / Battery powered TRV's would be a big plus for me .... wiring to all radiators in a retro fit world isn't possible for me.