Bug report and feature request

[Michael McSharry]

I believe everything in your wishlist has been incorporated in 3.6.0.0. See https://forums.homeseer.com/forum/li...tt-version-3-6

[Michael McSharry]

The decision for Express vs. Full is made at the Topic level and not the Payload level. Once any items from the Topic is assigned as Express then all items for that Topic also need to be treated as Express. While it may have appeared differently in 3.5.5.0 this has always been the case.

I have Obsolete on a item basis implemented. I am also moving toward some form of Parent/Child considerations on the Association tab

I will look at #11 and address it if I find something wrong.

I like the feedback. This gives me perspectives/expectations that I would not have otherwise known.

[tfoutfou]

F....... i am so stupid ..... the problem was between the chair and the screen ....

i forgot to check "Decode JSON into separate HS Devices " in "Express Mode Features"

i am soooo sorry to have wasted your time on 10# , just tried 3.5.5.0 again , the "bug" didn't exist if i check "Decode JSON into separate HS Devices"

and honestly now that i have had the opportunity to check how it was working , i would say that i prefer the previous behavior , i am so sorry again


i like the fact that :
-the parent is not being deleted when any of the child is selected as a Express Mode
(obviously to save CPU you seem to have already disabled value and payload update in HS when any child is in Express mode )

- the ability to NOT select every child as Express mode (can be useful in my use-case where i want to store only Watt-hour in database and display the rest as string)






BUG #11
Since the Last update , a new bug is introduced , i am not 100% sure tho
The RegEx Match/Replace pattern is not working on any device that is in Normal mode , however it is perfectly working in express mode
exemple Payload {"V1":230.2,"V2":230.2,"Hz1":50.0,"Hz2":50.0} RegEx Match \. RegEx Replace ,

i tried to send payload with coma instead of dot , but not sur how to format it correctly tho

this {"V1":230,2,"V2":230,2,"Hz1":50,0,"Hz2":50,0} --> plugin payload column is only showing the integer and discarding the decimal , regardless of "text" or "number"

this {"V1":"230,2","V2":"230,2","Hz1":"50,0","Hz2":"50,0"} --> plugin is not recognizing topic name anymore , it detect a coma in front of the topic after the first one
--> Topic V1 ,V2 ,Hz1 ,Hz2 showing only the integer




Thanks again dude , hope to not bothering you too much

[Michael McSharry]

Correct about version number.
Express mode does not support Parent/Child grouping. It is intentional that no grouping is available for express. If you remove express checkbox the grouping will be restored.
Can you give me screen shots and step by step description of what is not working. I don't see issue at my end so I must not be doing the same thing as you.

[tfoutfou]

10# Express mode still not working with JSON , strangest behavior is happening
when i check any child device , i get the same message as before
but this time all the other child are being checked expect the one i actually checked (if i check again i get the message again)

the same thing is happening with the JSON full payload being applied in DeviceString for the device i checked (but device appear not checked)
the same thing is happening with the childs (but this time they appear checked) , no update anymore of Value Or String
NEW bug : the parent device is deleted when i enable express for a JSON topic

[tfoutfou]

thank you for the reactivity

edit : typo in your link , replaced 4 with 5 , now i got the last version

[Michael McSharry]

I believe everything on your bug and feature list that we agreed to is at It is at http://mcsSprinklers.com/mcsMQTT_3_5_7_0.zip except for the Obsolete checkbox on the Association tab. I will do that next.

Let me know if I missed something or something should work differently to make it better. You should be able to do JSON in Express mode. I let the plugin handle the dependencies between the two features.

[tfoutfou]

same as explained in post 4

#10 NEW BUG / QUESTION

Express mode on JSON devices dont work , if i enable "express" on one device , the full JSON payload is putted as a string in the said device , and the associated parent and remaining child device stop updating at all.
If any child device is set to Express mode , we can NOT set any other one to express mode , we get this error message

"Topic PZEM04:A has already been accepted for Express mode. PZEM04:A must not be selected for Express mode to be able to accept PZEM04:Pf"

[Michael McSharry]

What is your specific issue with JSON/Express?

[tfoutfou]

#7 one can trigger and event with the condition "mqtt topic received" and inputing the name of the parent if needed , i have a feeling this approach is more efficient

#10 ok about the table , i already have seen it , but since i have an issue with express mode and JSON at the moment , i cant use it

[Michael McSharry]

#10 From Table 2 of the manual you can see that a JSON payload and a non-JSON payload take just about the same to process. Compare row 3 with rows 1 and two of the table. What takes the time is updating the HS device. Compare rows 3 and 4.

#8 I will be able to replicate now that I know your sequence.

#7 I agree there is an incrementing counter for DeviceValue. This was done so one could trigger an event on the receipt of a new payload. It was done before benchmarking so I will remove it now that we know the CPU penalty.

[tfoutfou]

#7 ok for the first part of the response , i understand the downsides

for the second part , i am talking only about JSON parent HS devices
if you go in the HS Device config , in the advanced tab you can see the Value , this value is growing by +1 every time a JSON payload
is received (not realtime you have to refresh the page) , this mean somewhere in the plugin there is a command to update this value .
the question is all about CPU , if updating HS devices is CPU intensive , why updating the parent device Value ?
maybe if will stay away from parent for Json devices to keep it simple

#8 by doing this your way it is working , i was using the "Ref" button in association tab , then clicking "Delete Sub and Ref" button
tested this right now i can confirm with the "delete sub and red" it is not working

#9 perfectly agreed on this

F3 nice

F5 ok but i still see some VSP in the list , even when "text" is selected , maybe created at the creation of the device ??

Q3 so the payload must be something like that for RGB ? : AABBCC
where AA = 170 for Red BB = 187 for Green CC = 204 for blue ?

#10 ok , but while waiting can you tell me if Express mode on JSON devices is supposed to have the same CPU saving effect than on normal topic devices ?
supposedly yes , because i imagine the JSON devices as virtual topics created by the plugin but then afterward it have to be processed the same way as a normal topic right ? or is it using other internal plugin logic ?

Thanks

[Michael McSharry]

#1 fixed in http://mcsSprinklers.com/mcsMQTT_3_4_6_1.zip

#3 fixed. Note syntax needs to be MQTT-compliant for wildcard.

#7/#5 The Association tab does not show any topics that are associated with a HS parent device. It only shows the individual JSON items or non-JSON item.
I could add a row for parent and update the full parent payload on this tab, but It has downsides beyond just the CPU use.
If I added checkbox controls for parent then it could be confusing to know if a parent is unassociated from HS then will all children devices be deleted.
If the checkbox action was to only remove the parent then the children would no longer be associated to any parent.
If a user selects only a parent association checkbox then does this mean that only the full JSON payload goes into a HS device or does it mean that all children also get associated with HS device and then need to uncheck the children not desired.
if no checkbox controls were shown for parent then one needs to deal with how to sort when both parent and children rows are present. For example, sort by payload would result in parent and child no longer being in contiguous rows.
My thinking is the way to deal with these things is to make the Association row represent only potential child HS devices so the operation of every row is consistent
Can you explain the following. I do not understand. "i was more concerned about the DeviceValue growing by 1 at every payload". When a payload is received mcsMQTT updates its internal dictionary. If HS device is associated then the deviceValue or deviceString is updated. At shutdown the internal dictionary is copied to the mcsMQTT database. The raw (full) topic/payload goes into the History database on every message reception if the topic satisfies the history collection criteria. This is the database from which charts are generated.

#6 my benchmarking showed that decoding JSON was very small CPU use so your assumption is likley correct that one message with JSON encoding will be overall more efficient that multiple without JSON. This is especially true when considering the broker's involvement too.

#8 I have a Topic x/RESULT with JSON POWER1 and POWER2. Two rows exist on Association tab. I Associate POWER2 to HS. On HS page device 1068 and 1069 were created. 1068 is the parent. I unchecked the Association on Association tab for POWER2/1069. HS devices 1068 and 1069 removed from Device Management page. Can you explain your steps where the parent device remains in HS?

#9 I believe what you are seeing is the differences in regional use of the period and comma. Your OS, running in France, sees 1.234 as either number 1234 or text "1.234". You MQTT node is publishing "1.234" with intent of it being a number. Since this node is not compliant with France regional use of the period/comma you should use a regular expression in mcsMQTT to change the period to a comma for this device. There is example in the manual.

F3 my benchmarking discovered that doing anything with the HS devices is very expensive with CPU vs other activities within mcsMQTT. I will look into providing on/off control in the Statistics parent HS device.

F5 The background collection of VSP information occurs for Unspecified, Button and List types. If you define it for Text then no overhead and you can publish your HTML-formated text that will go directly into DeviceString

Q3 The RGB fromat is HEX RRGGBB.

Q3 Subscription to ColorXY type expects JSON that includes "color":{"x":<value>,"y":<value>},"brightness":<value>. mcsMQTT translates this into RRGGBB which is what the HS device expects for the Color Picker control.

Q3 Publish of ColorXY type will send JSON {"color":{"r":<decimal value>,"g":<decimal value>, "b":<decimal value>}}
I have not yet investigated #10

[tfoutfou]

#3 retrying this right now on an random topic created for testing last night

JSON payload with 4 child , topic name "PZEM000" , subtopic name"V1" "V2" "Hz1" "Hz2" , only 2 associated child's
going in general , inputting "PZEM000#"

topic update has been disabled from the other side of the chain

result : associated child's are deleted , unused child's remain in the association tab

enabling topic update , deleted child's appear again in Association tab

rebooting plugin via HS management tab

disabling topic update

exactly the same steps

Result : all child's deleted

enabling topic update again , child's appear again in Association tab

result : impossible to delete those child's or any other topic again

if i associate a child to an HS device , then try to delete the topic , it work again only for the associated child

[tfoutfou]

#1 ok waiting feedback (if Default mode is Express , the checkbox will also check itself when accessing Edit tab or clicking "Ref")

#3 simply by going to the General tab and inputting the Topic name , then clicking on submit or enter , the topic isnt deleted from the Associations tab (topic not associated with any device) , some kind of database lock maybe ?? but not really possible since the plugin dont throw any errors ... ? Not a big issue since a simple plugin reboot fix the issue (will try more and find a way to reproduce the bug)
(trying this right now on non associated devices and it dont work)

#5 it is my OCD kicking back , the parent topic was shown in the list , but is not updated anymore because the plugin is doing its magic in the background when JSON is enabled .
i didnt know until a few moments ago that when JSON processing is enabled the parent topic is discarded from the list
but if you dont remove it manually or check "r" it stay there forever

#6 still my OCD lol . i wanted to know if the plugin is "optimized" for JSON processing
to be more precise , is it better to have a longer payload then divide it with JSON or is it better to have more small individual topic ?
I would say JSON because processing a single Mqtt packet seem more efficient , but hey just my felling !

#7 as in #5 the parent Topic is discarded from the list , so no "true" parent anymore.
i was more concerned about the DeviceValue growing by 1 at every payload ?!
is it ONLY updating the value with a function like hs.SetDeviceValueEx , or is it doing something else in the background (like updating a database with the full payload ) ?

#8 ok waiting feedback

#9 ok , dont waste your time on this , maybe we can fix this with "payload RegEx match/replace pattern" on our own

F1 ok nice

F2 agree with you pretty useless to have topic by topic for decoding , but parenting may be an issue
EDIT : or a Non-issue , since we can break auto-parenting afterward , or set to "Json into individual" before selecting devices

F3 let me explain better , i would like to be able to keep my Statistic devices in HS , but to save CPU i would like a checkbox to disable update of said devices . (if you disable and re-enable Statistic device it keep deleting and recreating them , pretty annoying)
Maybe CPU time is ridiculous to do such a task ? do you know ? if so this request is USELESS

F4 ok

F5 ok i see your point there , but if "text" is selected , to save ressources i really dont want some kind of magic in the background creating VSP and filling database

i have 20+ power sensors sending Mqtt every 3 to 5 seconds , it would be nice if i can send the fully formatted string to put directly in a HS DeviceString without being forced to run a script on HS side , because currently i use "number" then run a script to fill DeviceString.

Q1 answered in Q4

Q2 Q3 ok nice , i can implement that with my arduinos already controlling RGB but each color is a different channel on its own actually.
can you tell me more ?
what is the formatting of #RGB ? #128,212,3 ? for values going from 0 to 255 ?
what is the formatting of XY ?

Q4 ok nice





#10 NEW BUG / QUESTION

Express mode on JSON devices dont work , if i enable "express" on one device , the full JSON payload is putted as a string in the said device , and the associated parent and remaining child device stop updating at all.
If any child device is set to Express mode , we can NOT set any other one to express mode , we get this error message

"Topic PZEM04:A has already been accepted for Express mode. PZEM04:A must not be selected for Express mode to be able to accept PZEM04:Pf"

however are there any benefit at all to use express mode on JSON devices ? are they processed differently than direct Topic devices or is it all the same after they are created as "fake" Topic ?