Elk Nodeserver

[William Olsen]

J, verify what you propose with Michel before beginning, there may be licensing issues with Pulseworx. That may be a rabbit hole that none of us wants to go down.

[Jimbo.Automates]

I don't see how it could be an issue, we are just controlling a light that is defined in the ELK, but I'll like @Michel Kohanim give his opinion.

 

[William Olsen]

I just don't want to create an issue for any entity or person potentially getting involved with Pulseworx. I believe that Michel and I know that I also have a bad taste in our respective mouths from dealing with the Owner, I don't think much has changed.

[William Olsen]

Jimbo, would you happen to have one of the older versions of the Elk NS before you removed the lighting option?

[Jimbo.Automates]

Jimbo, would you happen to have one of the older versions of the Elk NS before you removed the lighting option?

I don't. I could pull it out of git and release it but then you'd be stuck on an old version which would never get fixes or updates. I started looking at adding this back earlier today,.will try to work on it more this weekend if I have time.

Sent from my Pixel 6 Pro using Tapatalk

[Jimbo.Automates]

@William Olsen 3.8.0 Uploaded to the store with new light_method ELKALL which should work for what you want.

Edited August 13, 2023 by Jimbo.Automates

[William Olsen]

Got it loaded after a few hiccups mainly with PG3. The NS is still not properly differentiate between tasks, counters and lights. I'm attaching the "long form" log. Thank you for the quick turnaround Jim!

ELK_8-13-2023_30207_PM.zip

[Jimbo.Automates]

26 minutes ago, William Olsen said:

The NS is still not properly differentiate between tasks, counters and lights.

I'm not sure what you mean by this?

Did you change your light_method to ELKALL and Save it?

[William Olsen]

No, i didn't initially however when I saw your reply I changed it and re-booted the IoX. I had a couple of entries at the beginning of the log, I don't know if they would be of interest to you: And thanks for staying on this for me.

 

 

2023-08-13 15:03:46,473 Thread-53  pyisy.events       WARNING  events:_route_message: ISY Received Malformed XML:
<?xml version="1.0"?><Event seqnum="1647" sid="uuid:28"><control>_7</control><action>1</action><node></node><eventInfo>U7 Rest:  submitCmd([n006_d_off_discreet],[COMMAND],[BUTTON.25=1&CODE.25=1&CONNECTOR.25=1&REPEAT.56=1])</eventInfo></Event>
2023-08-13 15:04:23,762 Thread-53  pyisy.events       WARNING  events:_route_message: ISY Received Malformed XML:
<?xml version="1.0"?><Event seqnum="1651" sid="uuid:28"><control>_7</control><action>1</action><node></node><eventInfo>U7 Rest:  submitCmd([n006_ony_power_2btn],[COMMAND],[BUTTON.25=0&CODE.25=1&CONNECTOR.25=1&REPEAT.56=1])</eventInfo></Event>
2023-08-13 15:04:58,361 Thread-53  pyisy.events       WARNING  events:_route_message: ISY Received Malformed XML:
<?xml version="1.0"?><Event seqnum="1658" sid="uuid:28"><control>_7</control><action>1</action><node></node><eventInfo>U7 Rest:  submitCmd([n006_ony_power_2btn],[COMMAND],[BUTTON.25=0&CODE.25=1&CONNECTOR.25=1&REPEAT.56=1])</eventInfo></Event>
2023-08-13 15:46:07,620 Thread-620 udi_interface      WARNING  Controller:elk_restart: ELK Controller: Restarting ELK Connection

 

[William Olsen]

Looks like a wonderful job J, one short factlet that I thought you should know. In most lighting applications regardless of communications technique use a group of addresses that control one single point, the other that UPB and Elk refer to in context are scenes which control multiple devices within the lighting network with only one external command. I'd like to point that Elk treats points 1 thru 192 as individual points and 193 thru 256 as scenes which follow a slightly different command structure. I hope this helps.

[Jimbo.Automates]

19 minutes ago, William Olsen said:

Looks like a wonderful job J, one short factlet that I thought you should know. In most lighting applications regardless of communications technique use a group of addresses that control one single point, the other that UPB and Elk refer to in context are scenes which control multiple devices within the lighting network with only one external command. I'd like to point that Elk treats points 1 thru 192 as individual points and 193 thru 256 as scenes which follow a slightly different command structure. I hope this helps.

Great, glad it's working.  You can ignore those pyisy.events errors, I'll turn that off in a future release.  The node server API doesn't allow creating scenes, so I can't treat them any differently.  I'll see if @bmercier can add that to PG3.

 

[William Olsen]

Jimbo, I am absolutely unaware of how the PG3 interacts with the individual Node Servers, the IoX or the Eisy as I've really been out of coding since my back surgery in '16, I just can not sit for very long spells.

It might be just as easy within your Elk NS to label everything after 192 as ELK SCENE instead if LIGHT without getting into yet another Rabbit hole. The table method that Elk uses in the RP application to display lighting names and options remains the same regardless of the choice of lighting Vendor.

With respect to the lighting portion within your NS, the NS doesn't have to know how to create a scene, it is generally defined by the manufacturer's design and is commonly held within the lighting hardware itself, in my case Pulseworx.

I hope this information might be helpful to persons new to either product ( Eisy or Elk M1) and using any of the several lighting formats that the M1 can accommodate.