picoC dev env

[David Wallis]

I'm toying with the idea of going loxone, but I have a lot of custom code running currently within Homegenie and I would like to port portions of this to loxone. Some I would possibly look to do something similar to loxberry.

Does anyone know how to spin up a local dev env that I can test code in rather than buying a miniserver for testing?

Asked on gitlabs picoc repo but have had no response.

Thanks

David

[Andrew B]

When I started I spun up a simple test harness with stubs for the SPS functions I needed. It worked okay.

Frankly though, I recommend my current path: drop <$100 on an ARM SBC and use whatever dev env and Linux software you want to talk to the Loxone. I wrote a picoC comms module and corresponding Linux module to get and set the Loxone virtual inputs. Now I can move my compute back and forth as I like. And frankly I’m moving most compute off the Loxone — eventually it will be just for the GUI. Although I may use some of its I/O since it’s there and there is always more stuff to control!

[Tico]

"I wrote a picoC comms module ..... to get and set the Loxone virtual inputs."

I'm curious what the comms module does. You can change the Virtual Inputs?

[Andrew B]

I’m not sure what you’re asking. Virtual inputs exist to be set, as opposed to physical inputs which are a reflection of their physical input. PicoC has a set of getter/setter functions for operating on virtual inputs. My picoC module essentially turns there into remote procedure calls over Ethernet, and does so en mass so that the values are efficiently kept in sync with my Linux machine’s view of the system state. It works pretty well, although there is a bit of latency — my wall switches used to go across this protocol, and there was a perceptible improvement when I moved all the logic and lighting control to the Linux machine. All my I/O is Ethernet based now, so any control device can control anything and that gives me freedom to change things transparently to users of the system (and most other parts of the system).

[Tico]

I should clarify I meant 'Virtual HTTP Input'. I had a glimmer of hope you had somehow managed to intercept the polling cycle for the Virtual HTTP Input and get and set it 'on the fly'.

I find the fixed nature of the HTTP input polling cycle a bit frustrating.

I use the web-services function quite a bit to set VI's for various modes across the config.

[Andrew Brownsword]

Yeah, sorry... I don’t do anything with virtual http inputs.  For my purposes the virtual http input isn’t useful. Since I have a Linux host running my own c++ code, that’s a much more natural place to host such services.

--
You received this message because you are subscribed to a topic in the Google Groups "Loxone English" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/loxone-english/mReAvUn3QhE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to loxone-englis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/ce58f92d-3e99-4e89-ab52-67c077872ad8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Wallis]

What fixed nature of http intput polling?

Are you saying if I use a http input that its not immediate?

@Andrew What SBC are you using and would you share your lib? - I have a TM4C123G here I could use - but if this is the route and that you dont recommend pico C then I may as well keep the software running in c# and interface with the miniserver from that.. its just this polling bit that is now scaring me!

[Andrew B]

My software is currently running on a quad Wandboard because I had one sitting around on a shelf from years ago. I bought an ODROID HC-1 to switch to, and am currently running my database and Grafana on that (since it has a 256GB SATA SSD), plus doing testing of my app on it. My plan has been to switch to the HC-1 once I’ve got the HVAC logic moved over, but since new shiny things keep showing up in the SBC worlds, its always possible I will change my mind. :) Running on Linux and being Ethernet based means it doesn’t matter much which SBC I use. Could use a PC too, but those are usually a lot more money and electricity. These SBCs are usually <$100.

As for sharing my code, I am as-yet undecided. Not yet, anyhow, as I still have a fair bit of development I want to do on it. It’s also possible I’ll want to take it commercial in the future, so I’m hedging for now.

[Tico]

@David - "What fixed nature of http input polling?" - I'm referring to the Polling cycle you can set up for a Virtual HTTP Input. ie. Between 10 seconds and whatever timeframe, that can only be changed on a re-save of the Config.

So you need to decide whether you poll something very regularly (minimum 10 seconds) and consequently use a lot of resources; or poll less frequently with the likelihood of missing immediate changes.

I find it a limitation of the Miniserver design that you can't natively set up a query/response to an external HTTP resource on demand.

[Andrew B]

Could code your http queries in picoC.

[Tico]

That's interesting... Do you have a 'generic' picoC http query that a coding numpty like me could adapt to whatever?

[Andrew Brownsword]

Wasn’t there one in the Loxone picoC docs?  It’s been a long time since I looked.

--

You received this message because you are subscribed to a topic in the Google Groups "Loxone English" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/loxone-english/mReAvUn3QhE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to loxone-englis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/31b3a114-4ce4-4c5f-b46c-04586b577657%40googlegroups.com.

[Andrew B]

Example 2 here, perhaps?  https://www.loxone.com/enen/kb/custom-script-programming/#HTTP%20FUNCTIONS

On Saturday, September 1, 2018 at 7:41:15 PM UTC-7, Andrew B wrote:

Wasn’t there one in the Loxone picoC docs?  It’s been a long time since I looked.

On Sep 1, 2018, at 5:54 PM, Tico <timcah...@gmail.com> wrote:

That's interesting... Do you have a 'generic' picoC http query that a coding numpty like me could adapt to whatever?

On Sunday, September 2, 2018 at 6:24:07 AM UTC+8, Andrew B wrote:

Could code your http queries in picoC.

--
You received this message because you are subscribed to a topic in the Google Groups "Loxone English" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/loxone-english/mReAvUn3QhE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to loxone-english+unsubscribe@googlegroups.com.

[Tico]

Thanks Andrew. But I possibly feel like a passenger plonked in a pilot's seat and told to 'Fly yourself to XYZ...'  ;)

Appreciate the link though.

On Monday, September 3, 2018 at 3:41:59 AM UTC+8, Andrew B wrote:

Example 2 here, perhaps?  https://www.loxone.com/enen/kb/custom-script-programming/#HTTP%20FUNCTIONS

On Saturday, September 1, 2018 at 7:41:15 PM UTC-7, Andrew B wrote:

Wasn’t there one in the Loxone picoC docs?  It’s been a long time since I looked.

On Sep 1, 2018, at 5:54 PM, Tico <timcah...@gmail.com> wrote:

That's interesting... Do you have a 'generic' picoC http query that a coding numpty like me could adapt to whatever?

On Sunday, September 2, 2018 at 6:24:07 AM UTC+8, Andrew B wrote:

Could code your http queries in picoC.

--
You received this message because you are subscribed to a topic in the Google Groups "Loxone English" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/loxone-english/mReAvUn3QhE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to loxone-englis...@googlegroups.com.

[David Wallis]

this is why i was asking how people are running pico c on desktop computers to

emulate the mini server

---

From: loxone-...@googlegroups.com <loxone-...@googlegroups.com> on behalf of Tico <timcah...@gmail.com>
Sent: Sunday, September 2, 2018 11:11:00 PM
To: Loxone English
Subject: Re: picoC dev env

 

You received this message because you are subscribed to the Google Groups "Loxone English" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loxone-englis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/b958a7e0-74c9-4944-869a-8fcf1bab69bb%40googlegroups.com.

[Andrew B]

Yeah, and the complete lack of useful or useable dev tools is why I abandoned picoC as a tool. If you value your time at a reasonable hourly rate, the time a Linux sbc requires to pay for itself is virtually nil. And you end up with a system that is easy to have do whatever you want... and much easier to debug or replace in the future.

[David Wallis]

I'm actually trying to get away from coding for lights and debugging this sort of thing hence using loxone.. but then  some of the other integration i will continue to do in c#

---

From: loxone-...@googlegroups.com <loxone-...@googlegroups.com> on behalf of Andrew B <andrew.e....@gmail.com>
Sent: Monday, September 3, 2018 2:14:15 PM

To: Loxone English
Subject: Re: picoC dev env

Yeah, and the complete lack of useful or useable dev tools is why I abandoned picoC as a tool.  If you value your time at a reasonable hourly rate, the time a Linux sbc requires to pay for itself is virtually nil.  And you end up with a system that is easy to have do whatever you want... and much easier to debug or replace in the future.

--
You received this message because you are subscribed to the Google Groups "Loxone English" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loxone-englis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/df9855b2-adf9-472b-bebc-ab236d8e008a%40googlegroups.com.

[Andrew B]

I do appreciate the attraction of doing that -- the same sentiment applies to coding it yourself vs 'buying' off-the-shelf software.  Unfortunately while Loxone seems to promise this, its only true if you're willing to live within a fairly narrow set of functionality they provide.  Their buttons and lighting logic, their heating/cooling controllers, etc.  I very quickly found that none of their pre-coded function blocks were acceptable to me, and their graphical 'programming environment' (like most graphical programming environments) demos well but in reality is a nightmare if you try to go beyond the scale of simple demos.  At the scale of a whole house, it is a nightmare.

[David Wallis]

that is one of the bits that puts me off, but I'm going to wire without being constrained to tree, so that i can change out later should that be the case. i may also look at emulating devices on the link as it is can bus and the tm4c123g has two onboard can controllers.

---

From: loxone-...@googlegroups.com <loxone-...@googlegroups.com> on behalf of Andrew B <andrew.e....@gmail.com>

Sent: Monday, September 3, 2018 7:52:10 PM

To: Loxone English
Subject: Re: picoC dev env

I do appreciate the attraction of doing that -- the same sentiment applies to coding it yourself vs 'buying' off-the-shelf software.  Unfortunately while Loxone seems to promise this, its only true if you're willing to live within a fairly narrow set of functionality they provide.  Their buttons and lighting logic, their heating/cooling controllers, etc.  I very quickly found that none of their pre-coded function blocks were acceptable to me, and their graphical 'programming environment' (like most graphical programming environments) demos well but in reality is a nightmare if you try to go beyond the scale of simple demos.  At the scale of a whole house, it is a nightmare.

On Monday, September 3, 2018 at 11:42:00 AM UTC-7, David Wallis wrote:

I'm actually trying to get away from coding for lights and debugging this sort of thing hence using loxone.. but then  some of the other integration i will continue to do in c#

---

From: loxone-...@googlegroups.com <loxone-...@googlegroups.com> on behalf of Andrew B <andrew.e....@gmail.com>
Sent: Monday, September 3, 2018 2:14:15 PM
To: Loxone English
Subject: Re: picoC dev env

 

Yeah, and the complete lack of useful or useable dev tools is why I abandoned picoC as a tool.  If you value your time at a reasonable hourly rate, the time a Linux sbc requires to pay for itself is virtually nil.  And you end up with a system that is easy to have do whatever you want... and much easier to debug or replace in the future.

--
You received this message because you are subscribed to the Google Groups "Loxone English" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loxone-englis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/df9855b2-adf9-472b-bebc-ab236d8e008a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Loxone English" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loxone-englis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/59b81a54-6b20-432e-8d1f-55d11991934e%40googlegroups.com.

[Tico]

If you still wanted to explore options with PicoC, I found something that provides an interpreted environment for PicoC (with limitations).

(via Google Translate) -

https://translate.google.com.au/translate?sl=de&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fwww.loxwiki.eu%2Fdisplay%2FLOX%2FPicoC%2BInterpreter&edit-text=&act=url

[Andrew B]

Yes, wise to wire in a way that is independent of technology decisions. Home running everything can also provide topology independence at the cost of some wire... but wire is relatively cheap, so its a prudent move. I also used standard mains wire for the light circuits so that a more conventional system could be retrofitted.


PicoC env: the problem with just a picoC interpreter in isolation is that it doesn’t provide the SPS API, nor the execution harness. And in my experience, that it is 90% of the effort.

[Michael Smith]

Another option that works nicely is Node-RED (https://nodered.org) if you would prefer a node.js home for logic that's easier to maintain outside the miniserver.  You can either work directly with the API, or use virtual I/Os.  

[David Wallis]

Thanks, I recently noticed the sources are there so that I could build it for windows with Visual C++  however the lack of loxone extensions is some what annoying..

Is it possible to trigger virtual inputs and outputs without the poll interval using the loxone api?

[Andrew B]

By polling interval do you mean the base SPS iteration rate? Typically SPS seems to do an iteration every 20ms, iirc. From what I can tell, the picoC programs are separate threads that run continuously (unless they sleep or block). The get and set API seem to operate instantaneously, but SPS won’t react to changes until it’s next iteration. At least this is what I’ve inferred from observed behaviour.

[David Wallis]

just trying to get in clear in my head about how to integrate with it from my external software... awaiting the mini server arriving

---

From: loxone-...@googlegroups.com <loxone-...@googlegroups.com> on behalf of Andrew B <andrew.e....@gmail.com>

Sent: Tuesday, September 4, 2018 6:31:12 PM

To: Loxone English
Subject: Re: picoC dev env

By polling interval do you mean the base SPS iteration rate?  Typically SPS seems to do an iteration every 20ms, iirc.  From what I can tell, the picoC programs are separate threads that run continuously (unless they sleep or block).  The get and set API seem to operate instantaneously, but SPS won’t react to changes until it’s next iteration.  At least this is what I’ve inferred from observed behaviour.

--
You received this message because you are subscribed to the Google Groups "Loxone English" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loxone-englis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/3d3fde93-7848-43fa-bc09-82b2a0135239%40googlegroups.com.