vanackej
commented
2 years ago Hi @TJForc Thanks for the review.
Maybe I missed something about the SupportPirCam function, but given my comprehension, it's not used for now (as the computed result is always false). I also took care to keep the condtional tests and logs in order to keep the current behavior, even if not yet used. The function was necessary because instanciated before panel connection was initialized, but now that the PIR support is checked after panel connection, we have all the neccessary informations to check if PIR camera are supported (panel type, firmware versions, ...)
Why create 2 different functions?
Why not test if the result is a number and return the result as a string or a number depending on this test?
The command result is always a string, that have to be parsed as a number depending on the command. Sometimes a digits only number must be interpreted as a string (imagine a serial number with leading zeros for exemple). And it would also involve systematic number parsing attempt, even for basic string results. At last, I wanted the caller to be in charge of the expected command result type => The caller have knowledge of the expected result type and can perform results checks efficiently, not depending on how automatic conversation would be done.
This would avoid cascading function calls.
I can avoid function cascading by duplicating some code, as you prefer. I personnaly prefer avoiding duplication than a simple cascade, but I don't really mind both options
The comments of the functions also contain an error, you do not return Promise but either a string or a number.
Yes I can fix the comments
Otherwise in principle, the idea suits me.
pergolafabio
robertboccia
Implement Panel type and options discovery.
I also introduced some methods on TcpSocket in order to avoid code duplication for command results management