Announcement

Collapse
No announcement yet.

PED named key does not honor case when retried from Feature object

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    PED named key does not honor case when retried from Feature object

    A PED entry was made with:

    Code:
    Const PEDKEY As String = "PEDkey"
    PED.AddNamed(PEDKEY, Join(arrPED, ","))
    When observed with Debugger the PED object was as expected named entry with key ""PEDkey"

    The feature was updated to contain the PED with:

    Code:
    hs.UpdatePropertyByRef(iTopRef, HomeSeer.PluginSdk.Devices.EProperty.PlugExtraData, PED)
    Subsequently a new PED object was retrieved from the Feature:

    Code:
    Dim PED As HomeSeer.PluginSdk.Devices.PlugExtraData = hs.GetPropertyByRef(iTopRef, HomeSeer.PluginSdk.Devices.EProperty.PlugExtraData)
    The following confirms that the key was stored as lower case text so PED could not be retrieved using the named key unless converted to lower case

    Code:
    ?PED.NamedKeys
    Count = 1
        (0): "pedkey"
    
    ?PED.ContainsNamed(PEDKEY) 
    False
    
    ?PED.ContainsNamed("pedkey") 
    True

    #2
    I switched all my PED to lowercase based on this post. rjh didnt comment, so I assume that is the way it's going to be going forward.
    HS4Pro Running on a Raspberry Pi4
    68 Z-Wave Nodes, 175 Events, 359 Devices
    UPB modules via OMNI plugin/panel
    Plugins: Z-Wave, OMNI, HSTouch, weatherXML, EasyTrigger
    HSTouch Clients: 3 Android, 1 Joggler

    Comment


      #3
      I think it was always the case, even in HS3

      Comment


        #4
        I am porting a HS3 implementation so I do not think it was the case with HS3.

        Comment


          #5
          HS3 definitely allowed mixed case PED keys.
          HS4Pro Running on a Raspberry Pi4
          68 Z-Wave Nodes, 175 Events, 359 Devices
          UPB modules via OMNI plugin/panel
          Plugins: Z-Wave, OMNI, HSTouch, weatherXML, EasyTrigger
          HSTouch Clients: 3 Android, 1 Joggler

          Comment


            #6
            Can confirm that the HS3 SDK did not support mixed case keys. You can find the source code attached:

            Code:
                    Public Function AddNamed(ByVal Key As String, ByVal Obj As Object) As Boolean
                        Try
                            If Key Is Nothing Then Return False
                            If String.IsNullOrEmpty(Key.Trim) Then Return False
                            If Obj Is Nothing Then Return False
                            CheckNamed()
                            SyncLock Ncol.SyncRoot
                                Try
                                    If Ncol.ContainsKey(Key.Trim.ToLower) Then Return False
                                    SyncLock Ncol.SyncRoot
                                        Ncol.Add(Key.Trim.ToLower, Obj)
                                    End SyncLock
                                    Return True
                                Catch ex As Exception
                                    Return False
                                End Try
                            End SyncLock
                        Catch ex As Exception
                            Return False
                        End Try
                    End Function
            
                    Public Function AddUnNamed(ByVal Obj As Object) As Integer
                        Try
                            If Obj Is Nothing Then Return -1
                            CheckUnNamed()
                            SyncLock UNcol.SyncRoot
                                Return UNcol.Add(Obj)
                            End SyncLock
                        Catch ex As Exception
                            Return -1
                        End Try
                    End Function
            You can see it in this line here: Ncol.Add(Key.Trim.ToLower, Obj)

            Will look into ditching this limitation though. I'm updating the documentation to reflect this until we can implement a workaround.
            - JL West
            HomeSeer Software Engineer
            sigpic

            Comment


              #7
              Reviving a 5 month old thread? Just fix the issue plz ...

              Never seen a function with that many different return paths. This is an absolute drama when debugging an application.

              Verstuurd vanaf mijn SM-G965F met Tapatalk




              Comment


                #8
                Originally posted by kriz83 View Post
                Never seen a function with that many different return paths.
                I actually prefer the style above - if any condition not satisfied - return False. Then do the stuff and return True. Any exception - return False.

                Do you believe this looks better?

                Click image for larger version

Name:	returnpaths.jpg
Views:	45
Size:	44.6 KB
ID:	1384773

                Comment


                  #9
                  One note -
                  Code:
                  If String.IsNullOrEmpty(Key.Trim)
                  - will fail if Key is null. Should be

                  Code:
                  If String.IsNullOrEmpty(Key?.Trim)

                  Comment


                    #10
                    I would get rid of all the checks, since at the end we'are doing a catch all anyways :-(

                    Otherwise:
                    Code:
                    if ( (obj != null) && (!String.IsNullOrEmpty(key?.trim()) )
                    The point I was trying to make here is that the cyclomatic complexity of this little function is quite high, but that is irrelevant to the context of this issue :-)

                    Comment


                      #11
                      Originally posted by kriz83 View Post
                      I would get rid of all the checks, since at the end we'are doing a catch all anyways :-(

                      Otherwise:
                      Code:
                      if ( (obj != null) && (!String.IsNullOrEmpty(key?.trim()) )
                      Avoiding exceptions is always a good taste.
                      And if you have many checks - can you imagine how long the line would be? And debugging this will be a nightmare - how do you find which check fails?
                      Sorry for drugging this off-topic...
                      [EDIT] But what I don't get - why there's two try/catch blocks?

                      Comment


                        #12
                        I know nothing about coding in whatever language this is. My "programming" experience dates back to Fortran WAT V. However, I'm enjoying this conversation more than any other on this forum. Thanks for the lessons.

                        Comment


                          #13
                          Originally posted by racerfern View Post
                          I know nothing about coding in whatever language this is. My "programming" experience dates back to Fortran WAT V. However, I'm enjoying this conversation more than any other on this forum. Thanks for the lessons.
                          No problem The reason been - we just had similar discussion at work....

                          Comment


                            #14
                            Originally posted by racerfern View Post
                            I know nothing about coding in whatever language this is. My "programming" experience dates back to Fortran WAT V. However, I'm enjoying this conversation more than any other on this forum. Thanks for the lessons.
                            Personally (and in our entire organisation), we prefer functions that have 1 or 2 return paths. If you have a multitude of conditions to check, than probably the function could/should be splitted up.

                            We almost never use exceptions. If there is an exception, than we overlooked something and it is not safe anymore to use the application. Hence, we let the application crash and have it restarted automatically (I work in the medical industry). We do have a high code coverage and automated MTBF tests, so we know crashes take seldom place.

                            Comment


                              #15
                              Originally posted by kriz83 View Post
                              We almost never use exceptions. If there is an exception, than we overlooked something and it is not safe anymore to use the application. Hence, we let the application crash and have it restarted automatically (I work in the medical industry). We do have a high code coverage and automated MTBF tests, so we know crashes take seldom place.
                              We could have a discussion, but probably not in this thread. But quickly about exceptions - sometimes exceptions are normal, often in communication apps (i.e. TCP/IP) or database apps... And often you can't let app just crash - i.e. in real time control apps or multi-user apps. I work on CSIRO on many projects for Australian Synchrotron or solar thermal power stations.

                              Comment

                              Working...
                              X