开云体育

So i have a client that currently owns a Tesla Model S. Hes a tech junky and loves his iPhone app that controls his car. I thought it would be pretty cool if I could incorporate some of those controls into his touch panel. Anyone ever tried this?

I opened MasterInstaller today to update a few things. I was shocked at how fast the downloads occurred. I had a D3 template file that was 285meg, Crestron Database 152meg, and Toolbox 67meg. All 3 were done downloading within 90 seconds. This is a significant departure from anything I've seen in the last 9 years of downloading from there.

I thought this sounded like a fun exercise, so I worked something up using Robbie's method mentioned above.

I broke it down into x and y coordinates for each button, tracking the value with analog signals. Pressing right/left will increment/decrement the x coordinate, and pressing down/up will increment/decrement the y coordinate. Using the Numeric Keypad symbol allows the analogs to wrap around in either direction.

Then, I took the x,y coordinates and converted them back to digitals for feedback of the grid of buttons on the panel using a pair of EQUs feeding into 3 buffers.

This is scalable to practically any uniform grid size consisting of x columns and y rows.

Here's a link to a .smw file along with a screen shot of the logic flow.





--- In Crestron@..., "rlf79cm" <rlf79cm@> wrote:

That sounds great! A little beyond my Simpl abilities at the moment but I'm going to start trawling through the Help files straight away!

Cheers


--- In Crestron@..., Davis Whitehurst <whitehurstd@> wrote:

How about an analog inc for left/right that increments by 1 and analog inc for up/down that increments by 3. Run them into a sum. Add conditional logic for a wrap around effect. Obviously there would be a lot of buffers, ors and nors, but I think it could be done.

If value = 1.
Left sets it 9 for full wrap, or 3 if you just want to horizontal wrap
Right goes to increment
Down goes to increment
Up sets it 9 for full wrap, or 7 if you just want to vertical wrap
If value = 2.
Left goes to inrement
Right goes to increment
Down goes to increment
Up sets it 9 for full wrap, or 8 if you just want to vertical wrap

ETC...


Davis


________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately destroy the original transmission and its attachments without reading them or saving them to disk. Thank you.


[Non-text portions of this message have been removed]

That sounds great! A little beyond my Simpl abilities at the moment but I'm going to start trawling through the Help files straight away!

Cheers


--- In Crestron@..., Davis Whitehurst <whitehurstd@> wrote:

How about an analog inc for left/right that increments by 1 and analog inc for up/down that increments by 3. Run them into a sum. Add conditional logic for a wrap around effect. Obviously there would be a lot of buffers, ors and nors, but I think it could be done.

If value = 1.
Left sets it 9 for full wrap, or 3 if you just want to horizontal wrap
Right goes to increment
Down goes to increment
Up sets it 9 for full wrap, or 7 if you just want to vertical wrap
If value = 2.
Left goes to inrement
Right goes to increment
Down goes to increment
Up sets it 9 for full wrap, or 8 if you just want to vertical wrap

ETC...


Davis


________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately destroy the original transmission and its attachments without reading them or saving them to disk. Thank you.


[Non-text portions of this message have been removed]

I've got a system with 4 zones of garden lighting which are controlled via Crestron primarily on Mobile & Mobile Pro G.

However, we need to fit a wall station of some description in a location where cabling is impossible to control them as well.

Something like a cameo keypad would be ideal, but they all need cabling of one sort or another (I know there's a battery powered infinet keypad on the cards, but it's not been released yet to my knowledge)

There is a Pro2 nearby, so I'm thinking of a battery powered wireless solution somehow connected to the versiport inputs of the Pro2 and go programatically from there.

Has anyone got any idea of any elegant hardware I could use?

Cheers.
Mark

You could treat it like a 2D table.

Use AINC symbols with min/max parameters set to the size of your item grid. One for Up/Down and one for Left/Right.

Then use EQU symbols and ANDs to get digital FB of which one is currently selected.

You could easily wrap this in a module with parameters for the number of horizontal and vertical icons.

-Neil Dorin

Sent from my iPhone

On 2013-03-21, at 3:16 PM, "jrw_96" <jrw_96@...> wrote:

Off the top of my head you could use a ring counter to cycle through the icons and use the analog mode joins to show which icon is selected. The rest would be pretty easy logic wise.

JRW

--- In Crestron@..., "rlf79cm" <rlf79cm@> wrote:

I have a touchpanel menu with 9 icons - 3 rows of 3. I'd like to use the up/down/left/right buttons on the panel to scroll/navigate through the icons, with 'ok' selecting the desired item.

Obviously I can use up/down to control things like volume/channels etc, but I'm unsure how to use them to scroll through items/icons on the actual touchpanel - any ideas?

(Hope that makes sense)

Thank you!

Hi Matt,

That looks like a classic candidate for a state machine.

I.e. rather that attempt to parse a complete message in one mouthful, implement a routine that eats numbers, delimited by white space or the lf/cr.

Lf/cr resets the state machine and spits out your interesting data, and for each "number" you maintain a couple of state variables (data chunk, sub element).

And Atoi won't work on negative numbers will it?

Sorry this is a bit brief/vague, but I hate typing on my phone :)
All the best,
Ol

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Yeah, right, the string is not always the same, like I said, the attenuation value can be from 1 to 4 bytes long, for each channel. I was thinking of getting the LEN of the attenuation data, then MID the string based on that but seems more work than the removes anyway.

--- In Crestron@..., "jrw_96" <jrw_96@> wrote:

Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always &#92;x0d&#92;x0a...

If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...

JRW

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Here's the string

0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0&#92;x0d&#92;x0a

The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0

the first set of chars before the first space can be 0...-100, all the other data is a single byte.

My method is using REMOVE statements like below
status1 = ATOI(REMOVE("&#92;x20", rx$);
status2 = ATOI(REMOVE("&#92;x20", rx$);
status3 = ATOI(REMOVE("&#92;x20", rx$);

Attenuation[1] = REMOVE("&#92;x20", rx$);
ch1Clip[1] = ATOI(REMOVE("&#92;x20", rx$);
etc.,

all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?

Yeah, right, the string is not always the same, like I said, the attenuation value can be from 1 to 4 bytes long, for each channel. I was thinking of getting the LEN of the attenuation data, then MID the string based on that but seems more work than the removes anyway.

--- In Crestron@..., "jrw_96" <jrw_96@> wrote:

Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always &#92;x0d&#92;x0a...

If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...

JRW

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Here's the string

0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0&#92;x0d&#92;x0a

The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0

the first set of chars before the first space can be 0...-100, all the other data is a single byte.

My method is using REMOVE statements like below
status1 = ATOI(REMOVE("&#92;x20", rx$);
status2 = ATOI(REMOVE("&#92;x20", rx$);
status3 = ATOI(REMOVE("&#92;x20", rx$);

Attenuation[1] = REMOVE("&#92;x20", rx$);
ch1Clip[1] = ATOI(REMOVE("&#92;x20", rx$);
etc.,

all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?

Yeah, right, the string is not always the same, like I said, the attenuation value can be from 1 to 4 bytes long, for each channel. I was thinking of getting the LEN of the attenuation data, then MID the string based on that but seems more work than the removes anyway.

--- In Crestron@..., "jrw_96" <jrw_96@> wrote:

Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always &#92;x0d&#92;x0a...

If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...

JRW

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Here's the string

0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0&#92;x0d&#92;x0a

The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0

the first set of chars before the first space can be 0...-100, all the other data is a single byte.

My method is using REMOVE statements like below
status1 = ATOI(REMOVE("&#92;x20", rx$);
status2 = ATOI(REMOVE("&#92;x20", rx$);
status3 = ATOI(REMOVE("&#92;x20", rx$);

Attenuation[1] = REMOVE("&#92;x20", rx$);
ch1Clip[1] = ATOI(REMOVE("&#92;x20", rx$);
etc.,

all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?

Unfortunately not - it's a solid wood orangery with no way to get supply or network cabling..

--- In Crestron@..., "ChrisK" <chris@> wrote:

No 110v electric near by? a wireless cameo KPD would work...


--- In Crestron@..., "Mark" <access@> wrote:

I've got a system with 4 zones of garden lighting which are controlled via Crestron primarily on Mobile & Mobile Pro G.

However, we need to fit a wall station of some description in a location where cabling is impossible to control them as well.

Something like a cameo keypad would be ideal, but they all need cabling of one sort or another (I know there's a battery powered infinet keypad on the cards, but it's not been released yet to my knowledge)

There is a Pro2 nearby, so I'm thinking of a battery powered wireless solution somehow connected to the versiport inputs of the Pro2 and go programatically from there.

Has anyone got any idea of any elegant hardware I could use?

Cheers.
Mark

Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always &#92;x0d&#92;x0a...

If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...

JRW

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Here's the string

0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0&#92;x0d&#92;x0a

The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0

the first set of chars before the first space can be 0...-100, all the other data is a single byte.

My method is using REMOVE statements like below
status1 = ATOI(REMOVE("&#92;x20", rx$);
status2 = ATOI(REMOVE("&#92;x20", rx$);
status3 = ATOI(REMOVE("&#92;x20", rx$);

Attenuation[1] = REMOVE("&#92;x20", rx$);
ch1Clip[1] = ATOI(REMOVE("&#92;x20", rx$);
etc.,

all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?