MQTT - Lights - Color State

[tamu20]

Describe the bug next branch. MQTT does not publish the color state of the lights. If the color is changed, the only information in MQTT is the light id and isOn state.

Expected behavior MQTT will publish color state

Screenshots NA

Packet Capture Follow the instructions to complete a packet capture and attach the resulting zip/log files.

Pool Equipment

• Controller: IntelliCenter
• Controller Model: IntelliCenter i5PS
• Controller Firmware Version: 1.047
• Light: Intellibrite
• Light: GloBrite

[tagyoureit]

The light theme information is published in the /lightGroup/ topics. Are you looking at the /circuit/ topic?

[tamu20]

I'm looking at everything when I change the color. intellicenter-i5p/#

The only topic that comes in when I change the light is the /state/circuits/{id} topic with id and isOn in the payload.

[tagyoureit]

Can you provide a packet capture? Also, do you see the same with both the Globrite and Intellibrite?

[tamu20]

Yes, same behavior on both.

Packet capture process:

1. Turned both lights on from panel
2. Started Capture
3. Changed poollights (Intellibrite id:3) to Green from panel
4. Changed fountainlight (Globrite id:4) to Green from panel
5. Stopped Capture

2020-11-28_22-09-51.zip

[tagyoureit]

Hi, can you please provide a packet capture with reset? It seems there are somethings missing from the configuration. EG there is a second schedule with "Unknown name", no heaters are configured, and neither of your lights are populated in the lightGroups section.

Without the lightGroup section populated correctly there isn't any way of getting the emits to properly work, but as mentioned above, there are other things that don't quite seem correct, either.

The capture with reset will start from a blank slate and capture all of the configuration requests back to the OCP (outdoor control panel).

[tamu20]

Thanks for the feedback. I only have two schedules programmed, both with names and related to the pump. I see the heater in the poolConfig.

I have no need for a lightGroup in my setup, so that is why they are not configured. Is there possibly a way to publish a MQTT message from a light and not a light group?

I can pull the lightingTheme from the API server:4200/state/circuit/{id}. {"id":4,"isOn":false,"name":"Fountain Light","showInFeatures":false,"type": {"val":6,"name":"globrite","desc":"GloBrite","isLight":true},"lightingTheme":{"val":1,"name":"green","desc":"Green"}}

2020-11-28_22-09-51-reset.zip

[rstrouse]

The lightingTheme should now be included for all circuit types that have them. GloBrite is one of them.

[tamu20]

Thank you both!

[tamu20]

I just noticed something, when I use MQTT to change circuit state it is toggling the other circuits.

In this example:

• id 3&4 are lights
• light 3 is on and light 4 is off
• I publish this topic and payload to turn light 4 on:
• This is the what happens. It toggles 3,5,6

[rstrouse]

Are those circuits physically changing or is MQTT just emitting a bogus state.

[tamu20]

I verified at the panel the circuits are not changing. MQTT is sending those state changes. It is the same behavior if I turn the circuit on/off at the panel, MQTT will show a bounce on all those circuits.

[tagyoureit]

Can you please submit another packet capture with the updated config files based on the new code that @rstrouse recently pushed?

[tamu20]

This capture is a lot smaller. If it is not correct, let me know and I will re-do. Thanks!

2020-11-30_21-46-03.zip

[tagyoureit]

I couldn't replicate your issue, but found one small other issue that the client (njsPC) could subscribe to the same inbound topic numerous times. However, I don't think this is the cause of your issue.

When I do trigger the inbound call I'm not seeing code run twice or any weird on/off sequence on my side on anything. Since I don't have an IntelliCenter I can't see any actual packets being sent back/forth.

Could you test again after you pull, just to make sure?

Do you have the same behavior if you try to turn on the circuit from a REST api or from the dashpanel UI?

[tamu20]

Thank you for investigating further. The behavior is somewhat still the same if you initiate an on/off action from any source. (IntelliCenter Panel, dashpanel UI, API, MQTT setState).

The only one that does not 'show' the bounce is the IntelliCenter panel. The dashpanel will show the on/off toggle.

Here is some interesting observations now across the light circuits 3&4. I did not toggle 6 since it is the pool pump.

I did these toggles from REST, dashpanel, and MQTT setState and got the same results from all:

• If I turn 3 on or off: only 4 and 6 bounce

• If I turn 4 on: 5 and 6 bounce

• If I turn 4 off: only 6 bounces

What is different now from the original post on circuit 4, it does not toggle circuit 3 like it did. This is from a turn on of circuit 4.

I was thinking I might be getting a loop in MQTT or something. The only thing that I have monitor/control MQTT is in home assistant and it only has circuits 3 & 4 at the moment. I don't have circuits 5 or 6 setup in it.

[tamu20]

And to add on. I do have features that I can toggle on and off and there is no extra bounces anywhere in the feature topic tree. intellicenter-i5p/state/features/#

[tagyoureit]

Interesting. There really shouldn't be any loop because the state/control topics are different.

Do you see the bounce anywhere besides MQTT? Can you try disabling MQTT in config.json and restart the njsPC app and see if you can replicate the bounce? That should help us isolate if it is an MQTT problem pretty quickly.

[tamu20]

Yes, in my previous testing I would see the bounce in the dashPanel as well. I agree on it not being a loop.

I stopped njsPC, disabled MQTT, and restarted njsPC. Using Postman to turn on/off circuit 3 (main pool lights), I still see the bounces in the dashPanel. The Pool on indication in dashPanel will go off and then back on.

I also monitored MQTT to make sure there was nothing rogue posting to intellicenter-i5p/state/circuits/# during this test. It was empty.

I have only been pulling njsPC next branch, my dashPanel config.json is showing "appVersion": "0.0.1". Would that cause an issue? I really don't have a use for the dashPanel, so I never look at updating it.

[tagyoureit]

@rstrouse can you take a look? I think this is outside MQTT and I can't replicate workout the OCP.

[rstrouse]

You should pull a new dashPanel. What is odd is that I cannot download your log files above. Chrome thinks that they are malicious.

[tamu20]

I tried with Chrome to download those captures and got the same warning. I tried in Firefox and it did not complain. When I take the captures, I extract and then remove PII (even though it is probably in the raw packets) from the json files and then re-zip.

Here is a screen grab after I pulled dashPanel from git. Same behavior:

Let me know if there is anything I can do to aid in tshooting

[tagyoureit]

Weird... I have Chrome and pulled the logs no problem.

When you are looking for PII, check the poolConfig.json. That's where the owner information is stored.

I'm seeing the Pool circuit toggle on/off in the logs so hopefully we can get to the bottom of this.

[rstrouse]

Ok so I haven't been following along close enough for the MQTT end of this. I assume this all boils down to IntelliCenterBoard.setCircuitStateAsync method. It isn't doing it there as every socket interface and/or webhook would experience similar problems. I just spent the last hour trying to get MQTT explorer to publish a topic and then realized you are calling the rest api.

So a couple of things. First change your payload to the following and see if we get similar results.

{
   "id": 3,
   "isOn": true
}

Notice the formatting for the Id is an integer and the state is boolean.

This is the exact same http call that is made when you click on circuit 3 in dashPanel. Do you get the same results? Also are you running fw1.047 or are you on one of the intermediate firmwares between 1.040 and 1.045?

[rstrouse]

Ok so I managed to get your files downloaded. However, they show me the system downloading all the info from the i5p. This is of no use for this situation. In most cases that is what we want to see but your config looks very good.

I thought perhaps there was a log showing the command being issued to njspc but alas I see it being issued from another controller.

This is a message that is setting the following. byte 2 = Circuit 3. byte 3 = Globrite byte 4 = Not on with freeze byte 5 = Show in lights not features byte 6 = Lighting theme (not SAm mode) = Green byte 7 = 12 Egg timer hours byte 8 = 0 Egg timer minutes byte 9 = Use the egg timer - Don't stop is off byte 10 - 25 = The name of the circuit (Fountain Light).

So what I need is njspc issuing this command. In the next couple of posts I will describe how to get this to me. In fact you have access to all of these tools through dashPanel if you like.

[rstrouse]

May sure you have the latest next build of njspc and the latest dashPanel.

1. Start both njspc and dashPanel Servers.
2. Let the configuration checks complete as njspc gets any changes that may have occurred on the OCP. dashPanel will show ready as a status in the upper right hand of the header.
3. Click the hamburger menu on the left and select the logging tab. Before we start make sure the Log to Console and File options are not selected. Then click on the little filter icon fon the broadcast include option. and select the following options.
4. After you have set all these options click back on the settings dialog and set only the highlighted options in the picture. If you give me more than that it will be like drinking through a fire hose.

[rstrouse]

Now we are all set. Get your application ready to issue the command to njspc through MQTT. When you are ready click the Log to File option on the packets section. Give it a second to begin capture then issue the command. Wait until the entire operation completes then uncheck the Log to File option on the packets.

This is very important do not leave the Log to File option checked it will fill up your Pi with log entries.

When you are done doing this njspc will have created a packetLog([date]).log file in the logs directory. Upload that here. This will tell me what and/or who is issuing the command.

[tamu20]

Just to recap... I see the bounce in MQTT state circuit messages and also in dashPanel and it does not matter if I turn the circuit on at the OCP, via MQTT setState publish, or API call via Postman. During testing, tagyoureit had me disable MQTT in config.json but I would still see the bounce in dashPanel when using the API call.

I tried the payload you suggested, but it was the same behavior as before. I'm running fw 1.047

I don't see any issues when I toggle a feature circuit from OCP, MQTT, or API with the payload I use for circuits.

Here is the capture you requested with MQTT publishing the topic to turn on circuit 3 and then to turn it off. I can also get you the same capture with the OCP turning 3 on and off.

I reformatted the file name to make scp easier for me. packetLog_2020-12-0616-30-12.log

[rstrouse]

Yeah the source really shouldn't matter. I am looking at the RS485 interchange. Here is what I see. Btw if you load this up with http://[dashpanel ip]/messageManager.html. You can look at what I am looking at. The action 2 messages are the current settings from the OCP. The byte of interest is byte 2 on this message. Here it is after you issued the 168 command to change the state for circuit 3.

All looks good and bits 3 and 6 are on because the pool was running at the same time. The 30 message that follows is just the configuration for the running circuits and the 204s are simply the state messages. These do not include circuit states only features and virtual circuits. Later on down the line on message number 5621 you issue the command to turn off 3 and the response is that it went off.

The long and short is that the behavior is what is expected so the good news is that the OCP isn't actually bouncing the circuits on and off. Now I need to narrow down what could possibly be flipping our temporary state. This is not happening on the OCP which is good because I can get my indoor controller and my wireless controller to argue with each other.

[tamu20]

Agreed, when at the OCP I did not notice any other changes at the panel and the main pump kept running and did not do its normal spin-up if just coming on.

I posted above, but the on state will bounce different circuits from the off state. If I turn 4 on: 5 and 6 bounce

If I turn 4 off: only 6 bounces

Thank you both for your assistance!

[rstrouse]

Yeah but I can issue commands in sequence to the OCP in rapid succession and never even notice a change. So we had to be sure.

[rstrouse]

This is al really weird. I tried every combination that I can think of and cannot get the results you are getting. What is odd is that the feature state code and the circuit state code are identical they just simply point at different state and message sections.

Hmmm.... I will go through the code and see every place where the state may be set on a relay circuit.

[rstrouse]

Just to be sure when you toggle the circuit from dashPanel does it bounce the pool circuit when initiated from there?

[tamu20]

Yes, I toggled Pool Lights (id 3) from dashPanel and pool circuit bounced. :-/

[rstrouse]

And if you toggle circuit 5 (Aux 4) do you have a similar experience?

[tamu20]

I'm not sure if I even have anything on it, but I did toggle it via MQTT

turning on circuit 5 bounce circuit 3 turning off circuit 5 bounced circuits 3 and 6

[rstrouse]

That rules out circuit types that are tied to the underlying IntelliBrite controller. The only real difference between your system and mine is that I have 2 bodies.

[rstrouse]

Just a dumb question but is there an Aux 1 on your system?

[tamu20]

Does AUX 1 map to id 3?

[tamu20]

Could this be a pool builder setup issue? They always go EasyTouch and I was their first to request an Intellicenter. Everything does work from the OCP though.

[tamu20]

I also have 2 intellivalves.

[rstrouse]

I don't think so but it could be a misunderstanding as to which circuits are which in the i5p realm. The first circuit in IntelliCenter is typically the spa circuit. I find it odd that the name on the circuit (this came from intellicenter) was aux 2 on the first position after the spa circuit. Remember the difference between an i5p and i10s is that the base board is an i5p and the i10s simply adds more relays and an intake/return valve.

[rstrouse]

Aux 2 was the third relay for me and Aux 1 was what you have for circuit id 3. Perhaps the pb renamed these because AUX 4 fits the model. When the default names are assigned by IntelliCenter they are all caps.

[rstrouse]

Ok, the Aux 2 threw me off that was originally named AUX 1 so it simply skips what would have been the spa circuit. So I would like you to do the same procedure we did above but in this case trip that circuit that is labeled Aux 2. Know it isn't hooked to anything but I want to make sure it flips the expected bit.

[tamu20]

packetLog_2020-12-0616-30-12.log

[rstrouse]

Just to be sure circuits 3, 4, and 6 were already on when you tripped it. Is that correct?

[tamu20]

sorry. id 2 is tied to a feature/ waterfall pump. i forgot, because I usually turn it on from the panel in the feature section. intellicenter.com and the OCP show it in the feature section as Waterfall

dashpanel has it as Aux2:

[tamu20]

yes, 3, 4, 6 were on and 3 and 6 showed a bounce when toggling id 2

[rstrouse]

I think it is not ignoring the first circuit somewhere. This means that every state is shifted by one. I just need to find where we are not starting with circuit id 2 when the board is a P. Everything on the state set and comms with the OCP is working as advertised. It is when we are reading it back out somewhere.

[rstrouse]

Ok. Thanks for bearing with me your help let me focus on what could potentially cause the issue. I think I found and fixed it so if you could bring down a new njspc it should be fixed. I found a case where the circuits were not lining up with the bits being returned from the OCP for the action 30 message. It was assuming the first circuit was circuit id 1 and not 2. What this meant was when circuits 3, 4, and 6 were on it would assume that was 4, 5 (and you don't have a 7) was on. When it got a 2 message shortly after that it fixed the incorrect previous assessment.

[tamu20]

Bingo. I have tested and everything is working as it should.
Thank you!